A plain-language companion to our paper "Shielded Bitcoin: Private Transfers on the Bitcoin L1" (Clara Shikhelman, Mikhail Komarov, Aleksei Moskvin).
Bitcoin provides strong ownership guarantees without trusted intermediaries, but its transaction history is public by design: amounts, timing, and transaction links are visible on-chain, and known wallets can often be associated with real people or institutions. This is a problem. It’s a serious limitation for individuals and institutions alike, including treasuries, trading desks, and businesses using bitcoin for transfer.
Our paper asks a narrow question: can bitcoin move without publicly revealing transfer amounts and counterparties using Bitcoin as it is today, with no soft fork, no new blockchain, and without relying on trusted bridge operators?
Shielded Bitcoin is our proposed metaprotocol for doing so. It is our effort to introduce the first Bitcoin privacy architecture designed to eliminate trusted operators, interactivity, liveness dependencies, and liquidity/exit-collateral requirements.
Moving bitcoin into and out of the shielded metaprotocol using security vaults on the L1 via PIPEs will be detailed in a companion paper coming for release soon.
Value inside the metaprotocol lives in notes: small encrypted records, each holding an amount and a way to reach its owner. Notes are never visible on Bitcoin in readable form. When someone initiates a transaction, they publish an encrypted transfer to Bitcoin, along with a zero-knowledge proof that the transfer is valid. Bitcoin just stores and orders these bytes. It doesn't understand them, and it doesn't need to. Separate software reads the transfers in Bitcoin's order, checks the proofs, and keeps the shared list of notes. Think of Bitcoin as a public bulletin board: Bitcoin publishes and orders the data, while anyone can independently apply the Shielded Bitcoin rules to determine the resulting state.
Say Alice wants to pay Bob.
1. Alice seals a note for Bob. She creates a new note with an amount and Bob's receiving details, then encrypts it so only Bob can open it.
2. She publishes a transfer. It goes out as ordinary Bitcoin transaction data and contains three things: the encrypted notes, a unique serial number (called a nullifier) for each note she is spending, and a compact proof. The proof says three things at once: the notes she's spending exist, she's authorized to spend them, and the amounts going out equal the amounts coming in. It says this without revealing which notes they are or how much they hold.
3. Anyone can check it. Programs called indexers watch Bitcoin for these transfers. For each one, they verify the proof and confirm that none of the serial numbers have been used before. If everything passes, they add the new notes to a list and record the serial numbers as used. Because a serial number can only appear once, a note can't be spent twice. No indexer has special authority here: anyone can rerun the same checks from the published history.
4. Bob finds his money. His wallet tries to open each new encrypted note with his private viewing key. Most attempts fail, since they belong to other people. When one succeeds and passes a few consistency checks, it's his. When he spends it later, the same cycle repeats.
Only your spending key grants spend authority inside the transfer protocol. Every transfer carries a proof that the spender is authorized to spend the notes being consumed, and indexers reject anything without a valid proof. No indexer, miner, or outside observer can spend your notes, and the read-only keys described below cannot either. We never hold users’ funds. There is no operator holding bitcoin on users’ behalf.
A dishonest indexer can delay, omit, or serve stale data to a wallet that relies on it. That can disrupt the wallet, but it does not give the indexer the ability to spend the wallet’s funds. A user can switch indexers or independently replay the published transfer history by themselves.