[[alloc] init] Proposes Shielded Bitcoin for Private Payments Without a Soft Fork

Researchers propose a private transaction layer for Bitcoin

Researchers Clara Shikhelman, Misha Komarov, and Aleksei Moskvin, working with [[alloc] init], have released a proposal called Shielded Bitcoin. Bitcoin Magazine reported on the proposal on September 24, 2026.

The proposal describes itself as a privacy metaprotocol on Bitcoin's base layer. A metaprotocol is a set of rules that uses Bitcoin's data without changing Bitcoin's own rules. The aim is to allow shielded, meaning private, Bitcoin transactions.

The authors say the design would not need operators, a soft fork, or any other change to how Bitcoin reaches agreement on its rules. A soft fork is a change to Bitcoin's rules that older software still accepts. The proposal was published as a whitepaper, with a separate blog announcement.

Key points from the proposal

• The proposal is named Shielded Bitcoin and comes from [[alloc] init].
• The listed researchers are Clara Shikhelman, Misha Komarov, and Aleksei Moskvin.
• The authors say it would not require operators, a soft fork, or other changes to Bitcoin consensus.
• The proposal says funds would be moved into and out of the system using Bitcoin PIPEs.
• It says a user would need only a Bitcoin node, a Shielded Bitcoin indexer, and their own keys.

How a shielded transaction would be carried on Bitcoin

According to the report, a Shielded Bitcoin transaction is a blob of data with a prefix such as "shbtc:". That data would be placed inside a Bitcoin transaction using OP_RETURN, the witness field, or another method for carrying data.

Bitcoin itself would give this data no meaning. The Bitcoin network would not verify it or enforce any rules about it. Because of this, invalid Shielded Bitcoin transactions could still end up on the blockchain. A Shielded Bitcoin indexer, which watches the blockchain passively, would ignore those transactions when they fail validation and would not apply them to its record of balances.

The design mirrors Bitcoin's own structure in several ways. A note works like a UTXO, an unspent transaction output, which is a chunk of coins that has not been spent yet. Shielded transactions consume notes as inputs, just as Bitcoin transactions consume UTXOs. A witness proves that the inputs being consumed are properly authorized. Indexers read the transaction history and build the current state of which coins are spent and unspent.

Nullifiers instead of deleting spent notes

The report says an indexer does not delete notes from an unspent set the way Bitcoin deletes UTXOs. Instead, it uses a nullifier set.

With this method, a user posts an encrypted proof and a nullifier in public. This shows that a note has been spent without revealing which note it was. To check whether a note is still available, the system checks whether its nullifier has already been used rather than checking whether the note sits in an unspent set.

Indexers build a merkle tree of every note output ever created. A merkle tree is a way of organizing data so a large set of records can be checked efficiently. According to the report, this tree only grows and can only be added to. The nullifier set is built alongside it.

Keys, addresses, and the proof needed to spend

The report explains that each wallet derives a master secret key, and every other key comes from it. These include sk_spend, the private key; sk_nf, used to nullify note outputs; vk_in, used to decrypt and view incoming notes; vk_out, used to view outgoing transactions; and sk_view, used to generate a receiving address.

To give someone an address, a user creates a diversifier value called d and multiplies it against the sk_view key. The resulting public key, pk_d, together with d, is the address.

The sender then creates a random value called r_seed, which is needed to encrypt the note output and for nullifying. An output carries only three encrypted items: the value of the output, the d value from the receiver, and the sender's r_seed. The sender uses a secret, short-lived key pair together with the receiver's public key to create a shared secret that both sides can produce. The note output is encrypted with that shared secret, and the ephemeral key sk_eph is included unencrypted so the receiver can build the same secret.

On the input side, the report says a valid transaction needs two things: a public nullifier for the note outputs being consumed, and a zero-knowledge proof. A zero-knowledge proof lets someone show that a statement is true without revealing the details behind it. According to the report, the proof shows that the note output is included in the merkle tree of notes, that the transaction is authorized by the correct sk_spend key, that the nullifier is correctly derived, and that no inflation has occurred.

What the report confirms

• Shielded Bitcoin is a proposal from [[alloc] init] researchers Clara Shikhelman, Misha Komarov, and Aleksei Moskvin.
• It was published as a whitepaper with a separate blog announcement, and Bitcoin Magazine reported on it on September 24, 2026.
• The authors describe it as a privacy metaprotocol for Bitcoin's base layer that would not require operators, a soft fork, or other consensus changes.
• The design relies on Bitcoin PIPEs to move funds into and out of the system, and on indexers that watch the blockchain and maintain a note tree and a nullifier set.

The privacy and design details above are the proposal's own claims as described in the report. They are not independent test results or proof that the system works as intended.

What is still unclear

The source material does not give a timeline for the proposal, say whether any software has been built or tested, or describe any review by other Bitcoin developers. It also does not say whether the design has been submitted anywhere for formal consideration.

The report says more detail on the PIPEs mechanism would appear at the end of the article, but the supplied text ends before that explanation, so the full workings of PIPEs are not available here.

Why the design avoids changing Bitcoin's rules

The proposal is presented as a way to add private transactions without altering Bitcoin's consensus rules or depending on an operator or coordinator. According to the report, users would not need a service provider or any off-chain state to recover funds, and the system would work much like on-chain Bitcoin, with a node or indexer plus the user's keys.

Sources

• Bitcoin Magazine
• Shielded Bitcoin whitepaper
• Shielded Bitcoin blog announcement

Read also: Researchers propose Shielded Bitcoin for private transfers without a soft fork

Read also: Decrypt reports 'Zcash-style' design for private Bitcoin transfers