Shielded Bitcoin Spec Borrows Zcash's Privacy Design Without Touching Bitcoin's Rules

Three Cryptographers Publish a 56-Page Privacy Blueprint

Clara Shikhelman, Mikhail Komarov, and Aleksei Moskvin, all researchers at [alloc] init, published a 56-page specification on September 24, 2026, describing what they call Shielded Bitcoin — a metaprotocol that borrows the core architecture Zcash uses for private payments. The design takes Zcash's encrypted notes, nullifiers, and zero-knowledge proofs and adapts them to record shielded transfers on Bitcoin's mainnet without changing a single Bitcoin protocol rule.

Zcash introduced shielded transactions years ago. Every shielded Zcash transfer is represented as an encrypted note, and a mathematical proof attached to the transaction confirms the sender holds the funds — without revealing the sender, receiver, or amount to any observer. Bitcoin has never offered this natively. The [alloc] init team argues their metaprotocol gives Bitcoin users the same privacy tool while leaving Bitcoin's base-layer rules completely intact.

Coverage of the paper appeared in CoinDesk, Decrypt, CryptoSlate, Crowdfund Insider, and Bitcoin Magazine within days of publication, with all five outlets independently confirming the researcher names, institution, publication date, and page count. For readers who want background on how Bitcoin creates and tracks ownership of funds, the basics of how Bitcoin works explain the unspent-output model that the shielded layer builds on top of.

Encrypted Notes Hidden in Bitcoin's Own Transaction Fields

When a user sends shielded bitcoin, the protocol creates an encrypted note recording the amount and destination. A zero-knowledge proof bundled with the note proves the sender controls the funds and is not creating new coins from nothing — without revealing any of those details to any observer on the Bitcoin network. Bitcoin nodes record the data on the chain; they do not check or enforce the shielded rules.

The shielded data rides inside Bitcoin transactions as OP_RETURN outputs — small fields that Bitcoin's protocol has allowed in transactions for years, used for purposes like document timestamping and metadata. Bitcoin Core version 30 expanded the default size limit for these fields, and the [alloc] init specification depends on node operators running that version or newer. Bitcoin nodes pass the data through without interpreting it.

Separate software called an indexer reads the Bitcoin blockchain, locates every shielded-transfer record buried in OP_RETURN outputs, and constructs a private ledger from scratch. Any two correct indexers scanning the same Bitcoin history will reach the same private ledger, because Bitcoin's proof-of-work consensus fixes the order of every transaction permanently. All the shielded-layer rules live inside the indexer, not inside Bitcoin Core.

Each Private Transfer Weighs About Four Times More Than a Typical One

The Shielded Bitcoin specification, as reported by Decrypt citing the paper directly, states that a two-input, two-output shielded transfer weighs 625 virtual bytes. A standard Bitcoin transaction of comparable complexity typically weighs between 150 and 200 virtual bytes. That roughly four-to-one size ratio translates directly into higher fees, because Bitcoin's fee market charges per virtual byte of block space consumed.

The size premium matters most when current bitcoin network fees are elevated. During periods of heavy on-chain activity, a shielded transfer could cost four or five times more than an equivalent transparent transaction. The specification does not detail batching optimizations that might reduce per-transfer cost, so users who need privacy would pay a meaningful fee premium compared to ordinary transparent sends at current block-space prices.

The proof system driving the shielded transfers is Groth16. It generates compact proofs quickly, which is part of why the 625-vbyte transaction size is manageable. Groth16 requires a one-time trusted-setup ceremony before any shielded transactions can be processed. This is not an ordinary software bug that can be patched — it is a fundamental property of the proof system, and the [alloc] init paper names it as a known limitation with these conditions:

• The ceremony happens once before launch and cannot be repeated afterward
• Each participant generates secret randomness and must destroy their copy after contributing
• Security holds only if at least one participant honestly destroys their share
• If every participant colludes or is compromised, fake proofs become possible

Moving Real BTC In and Out Remains an Unsolved Problem

The 56-page specification covers one operation: transferring value between two addresses inside the shielded system. It says nothing about how a user first converts ordinary, spendable bitcoin into shielded value, nor how to convert shielded value back into ordinary mainchain BTC. Those two operations — peg-in and peg-out — are the hardest engineering challenge in any Bitcoin privacy layer, and the current specification defers them entirely.

The authors point to a companion paper for the peg solution: PIPEs v2, published on the IACR ePrint archive as paper 2026/186, another [alloc] init work dealing with witness encryption. PIPEs v2 is a real published cryptographic construction, but the specification does not detail how it integrates with the shielded-transfer layer. The two papers exist side by side, and the bridge connecting them is a future engineering task, not a finished design.

Without a working peg mechanism, the shielded pool starts empty. Users can transfer shielded value among themselves, but no verified process exists for locking real bitcoin already in circulation — the bitcoin supply page shows how much BTC currently exists — and receiving shielded value in return. Until the peg problem is solved, the shielded system has no connection to actual BTC held in existing wallets.

Building Privacy Without Asking Bitcoin to Change Anything

The defining feature of the [alloc] init proposal is also its most important constraint: nothing about Bitcoin's consensus rules changes. No soft fork is required. No miners need to vote on anything. No new opcode is added. Bitcoin nodes record and order the shielded data, but they never verify shielded-layer rules. Two correct indexers reading identical Bitcoin block histories will always agree on the private ledger state.

That design choice carries a real tradeoff. Bitcoin nodes will never natively enforce shielded rules, so the integrity of the private ledger rests entirely on users running honest, bug-free indexer software. An indexer that misbehaves could show an incorrect private balance with no Bitcoin-level recourse available. Understanding how software manages keys and verifies balances — covered in the guide to bitcoin wallets — helps frame how much trust indexer-based systems require.

The [alloc] init specification is a detailed public blueprint — 56 pages — for a Zcash-style privacy layer designed to sit on Bitcoin without asking it to change. The trusted setup still needs to be organized, the indexer ecosystem does not yet exist, and the peg mechanism remains an open research question. But the foundation for building privacy without asking Bitcoin to change anything has now been published.