What happened
On 24 September 2026, cryptography research firm [alloc] init published a 56-page specification for Shielded Bitcoin, a proposed private-transfer system that uses Bitcoin for publication and ordering without changing Bitcoin consensus.
The proposal is not a soft fork. It adds a separate private-transfer system above Bitcoin, while leaving Bitcoin’s consensus rules unchanged.
How it would work, step by step
Think of three separate jobs: Bitcoin records the data, an indexer reconstructs the shielded ledger, and a wallet finds and spends the notes belonging to its user. Sections 4, 15 and 16 of the specification describe this division.
1. Publish a transfer inside a Bitcoin transaction
A sender packages encrypted output notes, spend markers and a proof into a transfer envelope carried by a Bitcoin transaction. A note is a private record of value addressed to a recipient.
Bitcoin does not approve just any transaction. Its usual checks still apply, including signatures and whether the Bitcoin inputs can be spent. But Bitcoin consensus does not interpret the shielded payload or decide whether its private transfer is valid. A valid Bitcoin transaction can therefore carry an invalid shielded transfer.
2. Rebuild the shielded ledger outside Bitcoin
An indexer scans Bitcoin's history for payloads matching the protocol's format and processes them in block order. It checks the proof, the referenced ledger state and whether any spend marker has already been used. Invalid envelopes leave the shielded ledger unchanged, even though their bytes remain on Bitcoin.
The design allows users to run this replay locally instead of trusting someone else's index. Correct implementations starting from the same deployment state and chain history should reach the same result. The indexer does not need everyone's decryption keys and cannot spend their notes.
3. Let the recipient's wallet find its notes
The wallet scans accepted encrypted outputs using its incoming viewing key. It attempts to decrypt notes addressed to it, then checks that their contents match the accepted ledger data. Successful decryption alone is not enough.
This happens locally: the wallet can discover a payment without publishing the recipient's identity. Viewing a note and spending it are separate capabilities; spending still requires the corresponding spending authority.
4. Spend an old note and create new ones
To pay someone else, the wallet creates new encrypted output notes, including change when needed. It builds a zero-knowledge proof showing that it controls valid input notes and conserves their value, without exposing those notes publicly. It also publishes a nullifier, a unique spend marker for each input note.
The wallet puts this new envelope into another Bitcoin transaction. Once an indexer accepts it, it adds the new note records and the nullifiers to its ledger. A later transfer presenting an already recorded nullifier is rejected.
The old note is not erased or publicly labelled with its identity. The nullifier prevents spending it twice without directly revealing which earlier encrypted note was consumed. Bitcoin records the transactions; the shielded replay rules enforce this separate accounting.
Independent reports from Bitcoin Magazine, Decrypt, Cointelegraph and CoinDesk agree on that basic architecture and on the fact that no Bitcoin consensus change is required.
What stays private, and what still leaks
For an accepted transfer, the paper's target is to conceal the amount, sender, receiver and direct position in the transfer graph. Wallet holders can retain separate capabilities for incoming viewing, outgoing recovery and selective disclosure without handing over spending authority.
That is not the same as making the transaction invisible. The authors explicitly list transfer timing, the number of inputs and outputs, output grouping, fees and carrier-transaction metadata as public. Those surfaces can still help an observer correlate activity.
Cointelegraph also reports criticism about a new system beginning with a small anonymity set. That concern is compatible with the paper's own leakage model: cryptography can hide fields, but privacy also depends on how many users behave in ways that are difficult to distinguish.
The missing boundary: getting BTC in and out
The biggest unresolved piece is outside the paper's scope.
The specification covers transfers after value is already inside the shielded system. It does not specify peg-in and peg-out, the mechanisms that would move ordinary BTC into the shielded layer and release BTC back out. The authors point to PIPEs v2 as part of the broader design, but reserve those boundary mechanisms for separate work.
That limitation narrows the paper's non-custodial claim. The authors say spending authority remains with user-controlled keys at the metaprotocol transfer layer, while explicitly excluding deposits and withdrawals from that claim.
CoinDesk and Decrypt both highlight the same gap. There is also no announced launch date. The result is a protocol specification and research direction, not a wallet feature that Bitcoin users can deploy today.
Why it matters
The proposal separates publication from private accounting. Bitcoin records and orders the data; independently run software decides which shielded transfers count. If Bitcoin reorganizes its chain, that software must rebuild the affected state, and wallets may need to rebuild pending proofs.
The result is a design that can be reviewed and implemented without changing Bitcoin consensus. Its practical value still depends on the unfinished BTC entry and exit mechanism, interoperable implementations, privacy in use and the cost of publishing the data.