BRC-20, but shielded.

Why SBRC-20

BRC-20 proved people want tokens on Bitcoin. But every BRC-20 balance and transfer is public. Anyone can look up an address and see exactly what it holds, what it bought, and who it paid.

That makes BRC-20 wallets easy to track, front-run and target. SBRC-20 keeps what works about BRC-20 (simple inscriptions, fair mints, Bitcoin security) and removes the public ledger of who owns what.

How it works

SBRC-20 has two sides: a public side that works like BRC-20, and a shielded pool where tokens are private. You move tokens between them with shield and unshield.

Notes

Inside the pool, tokens exist as notes. A note says "this key owns this amount of this token", but it's only ever published as a commitment: a hash that reveals nothing about what's inside.

Commitments

The indexer adds every new commitment to a Merkle tree. The tree's root is a fingerprint of every note that has ever existed in the pool.

Nullifiers

When you spend a note, you publish its nullifier, a unique tag only the owner can compute. The indexer records every nullifier, so a note can never be spent twice. Nobody can tell which note a nullifier belongs to.

Proofs

Each private transfer carries a zk proof showing that the notes being spent exist in the tree, that the sender owns them, that they haven't been spent before, and that inputs equal outputs, so no tokens are created from nothing.

Private indexer

Bitcoin doesn't validate SBRC-20 rules itself, and it can't verify zk proofs. Like every BRC-20 indexer, the SBRC-20 indexer reads inscriptions in block order and applies the rules. What makes it private is what it tracks: it holds commitments and nullifiers, not balances. It can verify every private transfer while knowing nothing about it.

What it tracks

• Public balances per address, exactly like BRC-20.
• The commitment Merkle tree and its recent roots.
• The nullifier set: every note that's already been spent.
• Token deployments and total shielded supply per ticker.

How it validates a private transfer

1. Check the root is a known recent root of the commitment tree.
2. Check none of the nullifiers are already in the nullifier set.
3. Verify the zk proof against the root, nullifiers and new commitments.
4. If everything passes, add the nullifiers to the set and the commitments to the tree. If anything fails, the inscription is ignored.

Because every rule is deterministic, anyone running the indexer software on the same Bitcoin history arrives at the same state.

ZK proofs

A single circuit covers xfer and unshield. It proves, without revealing anything else:

• Each spent note is in the commitment tree under the given root.
• The sender knows the spending key for each spent note.
• Each nullifier is correctly derived from its note.
• Every note in the transfer is the same token, and total input equals total output.
• New commitments are well-formed.

The draft design uses the Poseidon hash for commitments and the Merkle tree. The proof system is still being chosen between Halo2 and PLONK-family systems, which avoid a trusted setup, and Groth16, which gives smaller proofs but needs a setup ceremony. Proofs are generated in your wallet, so your keys never leave your device.

All tokens share one pool, so an observer can't even tell which token moved. The more people use any SBRC-20 token, the more private every SBRC-20 token becomes.

Keys and wallets

Your wallet scans new SBRC-20 inscriptions and tries to open each encrypted note with your viewing key. Notes that open are yours. This is how you receive tokens without your address ever appearing onchain.

Viewing keys also make selective disclosure possible. You can show an auditor, exchange or accountant your history without making it public.

Fees and relayers

Inscriptions need BTC for miner fees. If you paid fees for private transfers from your own wallet, the fee input would link your transfers together and weaken your privacy.

Relayers solve this. You hand a finished proof to a relayer, the relayer inscribes it and pays the BTC fee, and you pay the relayer back with a small shielded note inside the same transfer. Anyone can run a relayer, and relayers can't steal or change your transfer, because the proof fixes every output.

Security model

SBRC-20 is a metaprotocol, like BRC-20. Here is what you're trusting and what you're not.

Bitcoin

Bitcoin orders and stores every operation. SBRC-20 needs no bridge, sidechain or new chain.

The indexer

Indexers must all apply the same rules. A buggy indexer could show a wrong state, so the indexer and circuit will be open to review, and exchanges and wallets should cross-check more than one instance.

The circuit

A flaw in the circuit could let someone create tokens from nothing. The circuit will be audited before mainnet, and the indexer publishes total shielded supply per token so anyone can check that the pool never holds more than went in.

Privacy limits

Shielding and unshielding are public, so moving the same amount in and out quickly can be matched. Privacy grows with the number of people in the pool and the time your tokens stay shielded.

Roadmap

1. Spec. Publish the full SBRC-20 specification for review.
2. Testnet. Indexer and circuit running on Bitcoin signet and testnet.
3. Wallet. Shield, send, receive and unshield from a browser wallet.
4. Relayers. A public relayer network for private fee payment.
5. Audit. Independent audit of the circuit and indexer.
6. Mainnet. Launch on Bitcoin mainnet.

FAQ