A privacy switch for the world's oldest public ledger

Bitcoin has been a public ledger for seventeen years. Every payment you have ever received has a sender, a receiver, and an amount attached to it, and anyone with a block explorer can read them. That property is a feature when the goal is replacing trust in banks with trust in cryptography. It is also a problem when the goal is using Bitcoin as money, because a fully transparent ledger is a surveillance system for anyone with a browser tab open.

On May 12, 2026, Starknet flipped that default on for a sliver of the Bitcoin supply. strkBTC went live as the first wrapped Bitcoin asset built on a new Starknet token standard called STRK20. The headline feature is a user-controlled switch. A strkBTC holder can broadcast a payment in transparent mode, where the wallet addresses and amounts are public, or they can flip into shielded mode, where a zero-knowledge proof attests to the transaction's validity without revealing the sender, the receiver, or the amount. Same asset. Same total supply. Two visibility regimes, picked per transaction.

This explainer walks through how the framework is designed, what the proof machinery underneath actually does, and where the trust assumptions move when you turn the privacy switch on.

​Briefing registry

• Topic: STRK20, Starknet's new asset standard for privacy-toggleable wrapped Bitcoin, and strkBTC as its first deployment
• Anchor source: GetBlock node report, "STRK20 privacy framework: how Starknet gave Bitcoin a privacy switch with strkBTC" (May 2026)
• Adjacent context: r/ethereum practical breakdown of zk proofs in the rollup stack (June 3, 2026); zkSecurity explainer of Groth16 as the dominant verifier-cost baseline (May 30, 2026, Hacker News)
• Type: live production framework with an audited spec, not a research preprint
• Go-live date: May 12, 2026

​Why a transparent ledger is a feature and a bug

Bitcoin's accounting model is simple. Every coin lives at one or more unspent transaction outputs, and every output names its owner with a public key hash. To send a coin, you sign a new transaction that consumes the old output and creates a new one assigned to the recipient. The full history is replayable by anyone holding a copy of the chain.

The transparency is a security property, not an accident. Auditors can prove reserves by pointing to a public address. Exchanges can demonstrate solvency without a trusted third party. Regulators can follow funds. The same property makes Bitcoin unsuited to a long list of legitimate use cases: payroll for a small team where competitor salaries leak by accident, donations to politically sensitive causes, treasury management for a public company that does not want to telegraph its cash position, and ordinary consumer privacy.

Privacy coins like Monero and Zcash have tried to solve this since 2014. Both succeed at hiding transaction details, and both remain niche, partly because they require a separate chain, a separate set of liquidity providers, and a separate mental model. STRK20 takes a different bet. It keeps Bitcoin's public chain as the source of truth and adds a privacy layer on a rollup that already has zero-knowledge proof machinery, so users can hold wrapped BTC and toggle the visibility of each transaction individually. Public when you want auditability. Shielded when you do not.

​One asset standard, two visibility modes

The core idea is unglamorous, which is the point. A privacy coin forks the chain and forces everyone onto a different ledger. STRK20 keeps the chain, defines a token standard with a privacy mode bit, and lets each wallet pick its exposure per transaction. There is no second asset, no second chain, no second peg.

In public mode, strkBTC behaves like a familiar wrapped BTC token on a rollup. A transfer is a normal Starknet transaction: sender, receiver, amount, and a STARK proof that the rollup applied the transfer correctly. Anyone with a Starknet block explorer can read the transaction. Indexers, custody dashboards, and on-chain analytics all keep working.

In shielded mode, the same wallet generates a zero-knowledge proof that says, in cryptographic form, the following: "I know a note commitment in the shielded Merkle tree that has not been spent, I am authorized to spend it, the value I am sending equals the value I am receiving plus the fee, and the nullifier I am publishing is correctly derived from the note I am consuming." The L1 verifier contract checks the proof and appends the nullifier to its set of spent notes. Sender, receiver, and amount are never published.

The user toggles between the two modes at the wallet level, and the underlying asset standard treats both flows as first-class. There is no penalty for using public mode, no requirement to shield, and no social pressure toward either default. Earlier shielded-pool designs usually require users to opt into a private pool at deposit time and accept reduced composability as the cost. STRK20 refuses that trade.

​How a shielded strkBTC transfer actually works

The diagram above walks the full loop. The Bitcoin mainnet anchors the collateral. The Starknet rollup enforces the rules. The shielded note set is a Merkle tree of commitments that the rollup keeps updated. Each shielded transaction moves the wallet through four roles: a note holder, a prover, a transaction submitter, and a recipient.

The shielded flow runs in four steps.

The first is lock. Native BTC gets locked into a bridge contract on Bitcoin. The bridge mints an equivalent amount of strkBTC on Starknet in a transparent note controlled by the recipient's wallet. The first hop from L1 to L2 is always public, on purpose, because anyone verifying reserves needs to see the bridge inflow.

The second is shield. The wallet takes a transparent strkBTC note and consumes it in a shielded transaction. The transaction publishes a new commitment to the shielded Merkle tree and reveals nothing about which transparent note was consumed. After this step, the value lives behind a Pedersen commitment, and only the wallet that knows the spending key can later produce a proof of ownership.

The third is spend. To send shielded strkBTC, the wallet constructs a zk-SNARK that proves three things in zero knowledge. The wallet knows a secret key whose corresponding public key hashes to a leaf in the current shielded Merkle tree. The note at that leaf has not been spent, which the wallet demonstrates by revealing a nullifier derived from the note and showing that the on-chain nullifier set does not contain it. The transaction balances, with input value equaling output value plus fee. The proof is small (a few hundred bytes for a Groth16-style circuit, larger for a PLONK), and it commits to a binding signature that ties the proof to the transaction's public fields.

The fourth is verify and update. The Starknet verifier contract checks the proof, appends the nullifier to the spent-note set, and updates the Merkle root. The new shielded note, or notes, joins the tree. The recipient's wallet scans the chain for commitments whose spending key it owns, picks them up, and can later spend them in turn. No one observing the chain learns who paid whom.

The proof machinery is the part most readers want a primer on, and a recent zkSecurity writeup of Groth16 that circulated on Hacker News at the end of May is the cleanest accessible treatment of the verifier side. The shielded circuit does not have to be Groth16 specifically. STRK20 is proof-system agnostic in principle, and production deployments can swap between Groth16, PLONK, and STARKs depending on the trust model and gas budget. What stays constant is the shape: a small proof, a constant-size public input, a verifier that runs in milliseconds.

​What the framework actually claims

STRK20 is a Starknet Improvement Proposal-grade token standard, not a research paper. The claims worth tracking are behavioral, not theoretical.

A strkBTC holder can submit a transaction in either public or shielded mode without the wallet having to move funds to a different contract or a different address. The same balance covers both flows.

Shielded notes are fungible within a denomination pool. Two notes of the same denomination look identical to an observer, since the only public information is the commitment and the nullifier.

The shielded Merkle root updates through Starknet's own state transition function, which means it inherits the rollup's full security. A rollup-level soundness failure could mint or burn shielded notes, but that is the same trust assumption a user already accepts by holding transparent strkBTC.

The proof system is hot-swappable. The first production deployment uses a Groth16 backend for low per-transaction gas, with a planned PLONK migration to remove the per-circuit trusted setup.

The privacy guarantee is honest. Shielded transactions hide the link between sender and receiver, but they do not hide the fact that a shielded transaction occurred. An observer sees a proof land on-chain, a nullifier get appended, and a new commitment join the tree. They learn that someone, somewhere, moved value. If the user needs to hide that a transaction happened at all, they need a different tool, like a coinjoin or a privacy chain.

​Why this is a moment for the L2 stack

The interesting thing about STRK20 is what it implies for every other token on every other rollup. Token standards on Ethereum and its L2s have been essentially public since ERC-20 shipped in 2017. The assumption baked into the DeFi stack, the wallet stack, the indexer stack, and the regulator stack is that transfers are public. STRK20 breaks that assumption, in a deliberate and minimal way, on a live rollup with real BTC collateral.

The implications cascade. A DEX that lists strkBTC in shielded mode has to think about front-running differently, because the mempool cannot see what is being swapped. A custodian that holds strkBTC on behalf of clients has to maintain viewing keys for auditors while keeping spending keys separate. A regulator that wants to follow funds has to negotiate for a viewing key at the wallet level rather than subpoenaing an explorer. None of these are unsolved problems, but all of them are unsolved at production scale on a rollup.

The larger claim, which the framework does not make explicitly but which the design implies, is that privacy and auditability can coexist if the architecture is built for both. A token standard with a privacy bit is more useful than a privacy chain, because the same wallets, the same bridges, the same DEX liquidity, and the same on-ramps keep working. Adoption becomes a wallet UX choice, not a chain migration.

​What is unsolved, and what to watch

Five things remain genuinely open.

Viewing key standards are not yet defined canonically. STRK20 lets wallets attach viewing keys, but a standard format would matter more than most people expect, since auditors and custodians are currently rolling their own.

Compliance tooling is also unsettled. The shielded flow does not produce a public transaction graph, so a regulator who wants to follow funds needs cooperation from the wallet provider. The legal and technical norms for that cooperation are still being negotiated.

Proof portability is a multi-year migration story. The first deployment is Groth16, but a multi-proof future means wallets, indexers, and verifiers need to handle multiple backends. The framework says it is proof-system agnostic, but the on-chain verifiers are still backend-specific.

Operator risk lives in the bridge. The bridge that mints strkBTC holds the underlying BTC. If the bridge is compromised, the wrapped token becomes undercollateralized regardless of how the privacy layer works. This is the same risk every wrapped BTC carries, but it deserves to be repeated.

Anonymity set economics matter at launch. Shielded privacy is only as strong as the active set of users. A small anonymity set makes shielded transactions correlatable by timing and amount, even if the cryptography is sound. The early days of any shielded pool are the most vulnerable.

The honest summary is that STRK20 is the first live, production-grade token standard to offer per-transaction privacy on a rollup with real BTC collateral, and the design choices are sound. The harder problems are not in the cryptography. They live in the wallets, the indexers, the compliance layer, and the legal norms that the framework does not, and cannot, specify on its own.

​Sources

• GetBlock, "STRK20 privacy framework: how Starknet gave Bitcoin a privacy switch with strkBTC" (May 2026). Reddit thread
• zkSecurity, "Explainer of the most widely used zero-knowledge proof system" (May 30, 2026). Hacker News discussion
• r/ethereum, "zk proofs explained for people who've heard the term 500 times and still don't fully get it" (June 3, 2026). Reddit thread