zkCoins

Private Bitcoin transactions on L1.

First implementation of the Shielded CSV protocol — zero-knowledge proofs hide amount, sender and receiver, while a 64-byte nullifier settles on Bitcoin.

No altcoin. No soft fork. No coordinator. Open source ⚡

Public Key

npub126ap5uuyez2puq363jp8ntveyhy35p4xts2xgu8k70s727spzeash2e85m

NIP-05 Address

[email protected]

Profile Code

nprofile1qqs9dws6wwzv39q7qgageqne4kvjtjg6q6n9c9rywrm08c090gq3v7cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds5calug

Publishing to

nostr.land

relay.damus.io

nos.lol

Author Public Key

npub126ap5uuyez2puq363jp8ntveyhy35p4xts2xgu8k70s727spzeash2e85m

Show more details

Last Notes

2026-08-12 14:00:27 GMT

A BTC-backed token whose exit needs nobody's permission
The zkBTC specification is public. It defines token standard 3 on zkCoins: lock Bitcoin, hold a private token meant to be backed one-for-one by it, and redeem back into on-chain BTC without asking a central party.
An optional gatekeeper can screen the source of new deposits at mint time. It can never freeze, seize, block or reverse anyone's coins, transfers or exit.
This is a design specification. There is no implementation code, the design is unaudited, and it is not production-ready.
https://image.nostr.build/a0b7bf010a50e4e9aa9f7c8c986f989cf8ec13471b1dcee32871f59c03494c40.jpg

2026-08-09 14:00:32 GMT

Validity, publication and proving are separate protections
The proof relation rejects an invalid state transition. A publisher still chooses whether and when to inscribe a valid nullifier, so publication liveness comes from permissionless choice and self-publication.
The selected prover is a different boundary. A thin wallet cannot independently confirm that the proven output root matches the outputs it requested, so a foreign prover is trusted for send-intent correctness.
Self-hosting does more than improve privacy. It removes that foreign-prover trust trade-off.
https://image.nostr.build/dd5d6cc0e31e439ff0aca995efd7dc5474cc1a78b3ef6ec50950e2368e112d46.jpg

2026-08-07 14:01:32 GMT

Anchored to Bitcoin has a concrete verification path
The receiver decrypts the CoinProof and checks recursive validity and coin inclusion. It then verifies that the on-chain nonce commits to that proof, and that the corresponding rotating key is the first accepted occurrence in the Bitcoin-derived log.
Its own coin history also rejects the coin if it was already credited or spent, so a courier or node can never force a double-credit.
Finally, every transition the coin depends on must be completed with at least six confirmations.
A node may gather the data. The receiver's own node verifies the result against Bitcoin.
https://image.nostr.build/09840be735f84c262bc8f4825216de84b5f1757ee88ce0260bd3cad2cd443cc7.jpg

2026-08-05 15:29:48 GMT

Completed is a verified state
A zkCoins transition is completed only when the verifier's own Bitcoin scan finds a valid signature, confirms that the rotating key is the first occurrence and counts at least six confirmations.
Fewer than six confirmations is pending. A malformed inscription, an invalid signature or a losing repeat occurrence is failed. Those are the three transition states.
A mint follows the same state machine as a send or receive. There is no separate mint-only state.
https://image.nostr.build/7bf37fc6eea7e2acae0ab38b6dfb61be2f48e8f4d0c53c460a6cb63ce644e8fe.jpg

2026-08-02 14:01:52 GMT

Protocol claims and deployment evidence stay separate
The specification defines a target design and is intentionally independent of any current implementation. That supports precise claims about bytes, proofs, custody boundaries, finality and issuance.
It does not by itself prove that a wallet, public network, proving stack or end-to-end flow exists. Those are separate claims that need current, reproducible evidence.
Keeping the layers separate is not caution for its own sake. It makes every statement inspectable.
https://image.nostr.build/727a8803b2e175e46c76f6a48a09c04468f65071af58cad969527aaa39110718.jpg

2026-07-31 14:00:57 GMT

A foreign node is a correctness boundary
The spend key stays in the wallet, so a node cannot sign or move a coin unilaterally. But the thin wallet does not independently recompute the proof's output root from the outputs it requested.
A dishonest single foreign node can propose redirected outputs or omit change, then obtain the wallet's cooperative signature. That is not key theft, but the effect on the sender can be the same as theft. The selected prover can also stall the account and sees plaintext intent.
The specification's mitigation is direct: self-host the prover or vet it for correctness, not only availability.
https://image.nostr.build/d44d4ebf1cc7b767f3ee3f1b3f751b5c0d340d0ca5d463118642773eb3c8e0ed.jpg

2026-07-29 14:52:37 GMT

A publisher is replaceable, not magical
A publisher collects signed transition nullifiers, half-aggregates them and pays to inscribe them. It never needs customer spend keys or customer CoinProof bundles. The value-bearing data goes sender to receiver off-chain.
The publisher can delay or refuse publication. It cannot forge the wallet's signature, and its aggregate is checked by every scanner. Another publisher — or the user's own node — can publish the same nullifier.
Its fee is a flat fee per transition in an asset it chooses. There is no native fee token.
https://image.nostr.build/4db48176cc309e5ba0f6172c45642a745918421f141a2be09fcc5008eb03acc7.jpg

2026-07-27 14:00:45 GMT

Client-side validation runs through the user's own node
The receiver's node decrypts the CoinProof bundle and re-verifies the recursive proof. It binds that proof to the creating transition's on-chain nullifier, then checks first occurrence against the nullifier log derived from its own Bitcoin view.
The coin is not creditable while any dependency is pending. Every required transition must be completed with at least six confirmations.
A thin wallet delegates this work. Trustless correctness therefore comes from self-hosting the validating node.
https://image.nostr.build/7e9f35a07e0a540f70698f93667e3f6df4c35d7fcd3ae57257eb4ce18519022a.jpg

2026-07-25 14:00:55 GMT

Bitcoin orders opaque nullifiers
The target design writes one object to Bitcoin: a rotating nullifier for each state-advancing transition. The proof, coin data and per-coin nullifiers stay off-chain.
A half-aggregated inscription exposes its format and count, a recent block anchor, each `(Pkᵢ, Rᵢ)` pair and one shared signature scalar. It exposes no amount, asset, sender, receiver or proof bytes.
Bitcoin does not need a new opcode or consensus rule. Nodes scan ordinary Bitcoin data and rebuild the same first-occurrence log.
https://image.nostr.build/2c97553ca26b4b7de97a0fbb5b1d6159bf59e3ef712c2601610ee570d241df0c.jpg

2026-07-23 14:00:49 GMT

Four facts that define the target design
Every send, receive and mint publishes one 64-byte nullifier pair. Under half aggregation, the specification estimates about 16 vBytes marginal per transition, plus header and commit/reveal overhead.
A transition becomes completed only after valid first occurrence and at least six confirmations. From Bitcoin data alone, payment details and account links remain hidden.
No separate chain, native protocol token or Bitcoin consensus change. These are specification claims, not proof of a deployment.
https://image.nostr.build/6866178deb5a64f86b2e7aa6f95f879d539c9becef95b3349b7ff30e293c7557.jpg

2026-07-21 14:00:44 GMT

What the specification actually establishes
The specification defines normative protocol rules and wire formats for private client-side-validated assets anchored to Bitcoin. For v1, it fixes one concrete reference parameter set pending cryptographic review.
Its stated conformance path is the node↔SDK primitive-parity suite plus external audit. That makes protocol parity and implementation assurance independently checkable.
The current scope is protocol assets, with Bitcoin supplying ordering and finality for admitted spend batches. A native-BTC entry, exit or redemption rail would require its own defined mechanism. The result is a precise claim Bitcoiners can evaluate without relying on a bridge promise.
https://image.nostr.build/63b4ff2a8fd0559ce24acaa7077ab0ff8240f9ba1206a1cf84a25e871fc46c30.jpg

2026-07-21 08:14:38 GMT

Serious privacy starts with claims that anyone can inspect and challenge
Shielded CSV: Private and Efficient Client-Side Validation was published as Cryptology ePrint 2025/068 by Jonas Nick, Liam Eagen and Robin Linus. It describes private client-side-validated token transfers secured by Bitcoin's ordering and proof of work.
The zkCoins specification develops one concrete target design from that research, with explicit wire formats, custody boundaries, delivery, recovery and operating roles. It remains independent of any current implementation, so protocol claims and implementation evidence can be tested separately.
For Bitcoiners, that separation is useful: inspect the construction, reproduce the vectors and evaluate real proofs and inscriptions on their own evidence.
https://image.nostr.build/115dd81329c597abe6ca7407560e8f63a76c461aede390c96eaa6d204bb76796.jpg

2026-07-17 14:00:43 GMT

2026-07-15 14:01:33 GMT

If a project promises Bitcoin privacy, ask exactly what is private — and whom you must trust
The zkCoins target design keeps Bitcoin as the ordering and settlement layer. It needs no separate chain, native protocol token or Bitcoin consensus change. It supports creator-issued protocol assets.
Spend authority stays in the wallet. Publishers aggregate and anchor batches without receiving spend keys, and proof verification prevents an accepted forged transition. Because publishers are permissionless and replaceable, users can choose another if one delays or omits a record.
That gives Bitcoiners a familiar model: verify correctness cryptographically, preserve self-custody and choose the infrastructure that supplies liveness.
https://image.nostr.build/726abbce718b4c2777948d9f2a7bd4239e78f179be0ef2cc539f7a769905687d.jpg

2026-07-13 17:26:00 GMT

Bitcoin blockspace is public and scarce
The zkCoins target design amortises one publisher batch across many private, client-validated spends. The current specification defines a constant 231-byte inscription payload per batch. Including the funding commit and reveal transaction, it estimates about 318 vBytes per batch — about 3.2 vBytes per spend when a batch contains 100 spends.
Hidden from chain-only observers: individual amounts, assets, senders, receivers, the transaction graph and even the batch record count. Still visible: the protocol marker and version, publisher key, accumulator roots, bundle locator, block anchor and signature.
Privacy through zero-knowledge proofs and client-side validation, anchored to Bitcoin without a consensus change.
https://image.nostr.build/0b8d2977d4797c09e6292dd477454d08cd3773a353cd3cc9534e464014efc6ca.png

2026-07-11 14:30:20 GMT

Bitcoin payments are public by default.
zkCoins is designed as a private client-side-validation payment layer anchored to Bitcoin — without changing Bitcoin consensus.
Amounts, assets, sender, receiver and the transaction graph stay off-chain. Zero-knowledge proofs establish validity, while a permissionless publisher anchors a whole batch of spends with a constant 231-byte inscription payload.
Bitcoin still sees protocol commitments and publisher metadata, but no individual payment amount or parties.
No separate chain. No native protocol token. No soft fork.
The specification describes the target design. We are building and testing the implementation in public: https://zkcoins.com
https://image.nostr.build/698aa1d8db1e3c31448dbc19d0a0f2a65c529c6707e6f7a782cbcab13879e3fc.png

2026-07-11 14:00:44 GMT

Your Bitcoin has no privacy.
Every Bitcoin payment you have ever made is still sitting on a public ledger, readable by anyone, forever. Your salary, your savings, the rent you paid last month. All of it, in the open...
Today we are showing what we built to fix that, in public.
zkCoins makes Bitcoin private
Value on Bitcoin, sent and received privately, while amounts, sender, receiver and history all stay off-chain — proven with zero-knowledge and anchored to Bitcoin as one constant 231-byte inscription per batch. Nothing legible ever touches the chain.
The full loop — create, mint, send, receive — already runs end to end on a public signet.
No new coin. No sidechain. No soft fork. Just Bitcoin, finally private.
https://image.nostr.build/636a382aa1886c8686a236317ce0e8c89ba03b2f6de8a51a4ac60f280f527530.jpg

2026-07-10 13:30:24 GMT

Your Bitcoin is now private!
Every Bitcoin payment you have ever made is still sitting on a public ledger, readable by anyone, forever. Your salary, your savings, the rent you paid last month. All of it, in the open...
Today we are showing what we built to fix that, in public.
zkCoins makes Bitcoin private
Real BTC, sent and received, while amounts, sender, receiver and history all stay off-chain, proven with zero-knowledge and anchored to Bitcoin as one constant 231-byte inscription per batch. Nothing legible ever touches the chain.
No new coin! No sidechain! No soft fork! Just Bitcoin, finally private!
https://image.nostr.build/76e626ad552ed7affd2cee5e2aac5c733d1c0280d9b2f39c4776dd37ab540f81.jpg

2026-07-09 13:29:58 GMT

Bitcoin is the most transparent money ever made!
Every payment you have ever sent still sits on a public ledger, readable by anyone, forever. Your salary. Your savings.
That was never the promise!
zkCoins fixes it!
Real Bitcoin, sent and received, while the chain shows nothing legible. Amounts, sender, receiver and history stay off-chain, proven with zero-knowledge and anchored to Bitcoin as one constant 231-byte inscription per batch.
Let us be blunt about what this is not
- Not a sidechain
- Not a soft fork waiting on consensus
- Not a mixer
It is stronger cryptography applied to the Bitcoin you already hold. It works on Bitcoin as it exists today — no consensus change, no new opcodes.
Your keys never leave your device!
https://image.nostr.build/70f7efc324c82a574af0084dbd1af52117b7819bb0c64fe20c088721c45b04da.jpg

2026-07-09 13:29:38 GMT

2026-07-09 13:21:44 GMT

2026-07-09 13:00:56 GMT

Bitcoin is the most transparent money ever made!
Every payment you have ever sent still sits on a public ledger — the amount, the sender, the receiver, the entire history — readable by anyone, forever. Your salary. Your savings. The coffee you bought this morning.
That was never the promise!
zkCoins fixes it!
Real Bitcoin, sent and received, while the chain shows nothing legible. Amounts, sender, receiver and history stay off-chain, proven with zero-knowledge and anchored to Bitcoin as one constant 231-byte inscription per batch — roughly 3.2 vBytes per spend, and none of it reveals a thing.
Let us be blunt about what this is not
- Not a new coin
- Not a sidechain
- Not a soft fork waiting on consensus that may never come
- Not a mixer with an anonymity set to pick apart
- Not a rollup with a sequencer to trust
It is stronger cryptography applied to the Bitcoin you already hold. It works on Bitcoin as it exists today — no consensus change, no new opcodes. Your keys never leave your device!
https://image.nostr.build/70f7efc324c82a574af0084dbd1af52117b7819bb0c64fe20c088721c45b04da.jpg

2026-07-07 20:33:09 GMT

🚀 [TEST] zkCoins — private Bitcoin on L1
No altcoin. No soft fork. No coordinator. Just Bitcoin, made private. ⚡
Wallet: https://zkcoins.app
https://image.nostr.build/7c536d00929899116512f7af9af3b73d419a7ae8d80936dc5ba1a476d3d6f7a1.jpg

2026-07-07 18:44:34 GMT

🚀 [TEST] zkCoins is live on Bitcoin mainnet
Private Bitcoin payments — no altcoin, no soft fork, no coordinator. Your amounts, sender and receiver stay completely private. ⚡
560 bytes per transaction → just 64 bytes on-chain.
Read the paper: https://eprint.iacr.org/2025/068
Open the wallet: https://zkcoins.app
https://image.nostr.build/17a6d01c424926a8ecb490aa49a21052fe087269e97c58c79e08ca7ea6178e74.png