Since its publication last week, [[alloc] init]’s Shielded Bitcoin proposal, along with PIPEs v2 published earlier this year, has generated plenty of excitement, along with a fair share of skepticism. Not surprising. The proposals use relatively novel cryptography to pursue something ambitious: private Bitcoin transfers, programmable vaults, and more expressive spending conditions without a Bitcoin soft fork, separate blockchain, or trusted operator set.
The problem is that the public discourse has started to blur together very different kinds of criticism. Some objections misunderstand how the architecture works. Some are frustrated that the vault mechanism wasn’t detailed in the paper. Spoiler: it’s being published in its own paper for good reason – as a separate contribution to Bitcoin research. Others point to genuine trust assumptions, engineering tradeoffs, or cryptographic risks. And others are flustered that it’s just not ready for production yet.
We sat down with Clara Shikhelman, the protocol lead for Shielded Bitcoin at [[alloc] init], to answer the most important questions about Shielded Bitcoin and PIPEs — clarifying what the proposals claim, where the research stands today, and what still needs to be demonstrated.
#1: Isn’t this just Zcash bolted onto Bitcoin?
There’s some truth there — and an important difference. Shielded Bitcoin deliberately draws from the body of privacy research pioneered by systems like Zcash: encrypted notes, nullifiers, and zero-knowledge proofs. Unlike Zcash, Shielded Bitcoin proposes BTC-denominated shielded notes, with Bitcoin providing publication, ordering, and settlement, and the underlying BTC secured through PIPEs-based L1 vaults. The shielded transfer rules do not become part of Bitcoin consensus, but there is no separate blockchain, consensus mechanism, or token either.
There’s an interesting parallel between Zcash, Shielded Bitcoin, and the underlying cryptography for each. In 2013, Pinocchio demonstrated that zero-knowledge proofs could be made practical for the first time. Three years later, Zcash became one of their first major production applications, using zk-SNARKs for shielded transactions. But the research lineage behind Zcash had actually begun with an ambition to bring stronger privacy to Bitcoin. As Zcash co-founder Eli Ben-Sasson put it when responding to Shielded Bitcoin last week (Tweet), “our original intent with Zerocash paper … was to bring privacy to Bitcoin.” But Bitcoin could not verify the required proofs (and Witness Encryption barely existed at the time), so that research ultimately found its expression in a new blockchain where the cryptography could be incorporated into the consensus rules.
Zcash took ZKPs from theory to deployment. Shielded Bitcoin could provide that path for Witness Encryption on Bitcoin. If Witness Encryption can be made secure and practical, we don’t need to build a new blockchain to bring this kind of cryptographic privacy to Bitcoin. Instead of adding new opcodes to Bitcoin to verify new conditions (along with the security and consensus risks it introduces), PIPEs can put those conditions behind a Bitcoin signature — potentially enabling privacy and other new capabilities while leaving Bitcoin itself unchanged.
So yes, Shielded Bitcoin owes an intellectual debt to Zcash and the privacy research that came before it. The interesting part is that Witness Encryption may give us a path to bring that original vision back to Bitcoin.
#2: What is Shielded Bitcoin if it’s not L1, an L2, or a sidechain?
This question comes down to being precise about semantics.
Let’s first clarify that Shielded Bitcoin is not part of Bitcoin consensus: Bitcoin nodes validate the underlying Bitcoin transactions, not Shielded Bitcoin’s private transfer rules. But Shielded Bitcoin also does not introduce another blockchain, consensus mechanism, sequencer, or validator set.
A more accurate description is a Bitcoin metaprotocol. Protocol data is published to and canonically ordered by Bitcoin, while a separate indexer/explorer parses that data to derive the protocol state deterministically. Shielded Bitcoin’s state can be reconstructed from Bitcoin L1 history rather than being reliant on client-side state storage (i.e., in Shielded Bitcoin if you lose your state, you still keep your Bitcoin), while the underlying native BTC remains on Bitcoin L1. The protocol’s rules are not part of Bitcoin consensus itself, but describing the architecture as a conventional sidechain is misleading for essentially the opposite reason: there is no second chain or separate consensus system.
#3: Even if the transfers are private, isn’t privacy compromised by transaction metadata and fees?
Shielded transfers provide strong cryptographic privacy, but — as with any privacy protocol — the system’s boundaries require separate consideration. Peg-ins, peg-outs, carrier transactions, timing, network activity, and fee payments can expose metadata if handled naively.
These are known design problems with practical mitigation paths. Shielded Bitcoin is being designed to minimize these linkages through mechanisms including privacy-preserving peg-outs, atomic swaps, fresh addresses, and improved fee payment flows.
The important distinction is between privacy within the shielded system, which is enforced cryptographically, and privacy at its boundaries, which depends on how users enter, exit, and interact with Bitcoin. Our focus now is hardening those boundary mechanisms so the privacy properties of shielded transfers extend as far as practical into the surrounding Bitcoin workflow.
#4: Isn’t it a trusted bridge? Who controls it?
No. The proposed architecture is fully non-custodial: there is no company, committee, operator, federation, or other party that takes custody of users’ Bitcoin or has ongoing control over whether it can be spent. There is no intermediary sitting between Alice and Bob deciding whether a transaction or withdrawal is permitted. At its simplest: it’s Alice, Bob, and cryptography in between.
This objection tends to conflate two very different concepts: trusted setup and trusted operation. PIPEs does have trusted setup assumptions. Constructing a PIPE ciphertext involves a one-time 1-of-n multiparty computation (MPC) ceremony, and the ZK proof system may introduce its own setup assumptions. But those participants do not become custodians or operators. They aren’t required to remain online, process transactions, approve withdrawals, or exercise ongoing control over users’ funds.
Instead, PIPEs is designed so that satisfying a specified cryptographic condition enables recovery of the signing key needed to spend the Bitcoin. Cryptography replaces the role that a trusted operator, committee, or multi-sig would otherwise play. Once the setup is complete, no setup participant is supposed to control the funds or participate in the user flow.
The current Shielded Bitcoin paper does not include vault architecture and details for entry and exit (i.e., “peg” in and out). This separation is deliberate because the vault architecture is a substantial protocol design contribution in its own right, with applications beyond Shielded Bitcoin. We believe it warrants dedicated treatment as a separate contribution to Bitcoin research rather than being compressed into the privacy protocol paper. A forthcoming vault design paper is largely complete and will specify and analyze that architecture in detail. We look forward to putting it forward for community review and feedback.
#5: Don’t users still have to trust an indexer or maintain client-side state?
No. Indexers are a synchronization convenience, not a trusted part of the protocol. Shielded Bitcoin transfer data is published to Bitcoin, allowing the protocol state — including the note tree, spent-nullifier set, and relevant roots — to be reconstructed by replaying that data in Bitcoin order.
An indexer therefore acts more like a block explorer than an operator. It never has access to a user’s private keys, cannot spend their notes, and has no authority over protocol state. A malicious indexer can omit data, return stale information, or refuse service, but its responses can be independently verified against Bitcoin history. Efficient verified light-client synchronization remains an area of ongoing engineering.
Users also do not need to preserve client-side state to recover their funds. The protocol state is reconstructible from Bitcoin L1 history; losing a wallet’s synchronized state does not mean losing the underlying protocol state.
This creates an important distinction from systems where users must preserve private state that cannot be recovered from Bitcoin. The relevant question isn’t whether an indexer or local state exists at all — it’s whether either must be trusted or preserved for correctness and recovery. In Shielded Bitcoin, neither needs to be.
#6: Without its own consensus, how can Shielded Bitcoin prevent double-spends or handle reorgs?
Shielded Bitcoin does not have separate consensus, but it does have agreed-upon protocol rules defining what constitutes a valid Shielded Bitcoin transaction. Bitcoin provides the canonical publication and ordering of protocol data; Shielded Bitcoin deterministically applies its own validity rules to that ordered history.
Double-spends are prevented using nullifiers. When a note is spent, its corresponding nullifier is published, and the transfer proof demonstrates that the spend is valid. If the same nullifier appears again, the second spend is invalid under the Shielded Bitcoin protocol rules. Because everyone applies the same rules to the same Bitcoin-ordered data, they can independently reconstruct the same valid shielded state.
These are Shielded Bitcoin validity rules, not Bitcoin consensus rules. Bitcoin does not determine whether a shielded transfer is valid; it determines the canonical history over which Shielded Bitcoin’s rules are applied.
Bitcoin reorgs therefore naturally propagate into Shielded Bitcoin. If Bitcoin’s canonical history changes, the corresponding shielded state is rolled back and replayed against the new history. A proof referencing a root removed by the reorg may need to be reconstructed and republished. As with Bitcoin transactions generally, users can wait for additional Bitcoin confirmations when greater settlement confidence is required.
#7: Isn’t Witness Encryption novel and therefore risky?
Witness Encryption has been studied in cryptography since 2013, but unlike ZKPs, it has not yet crossed the gap from theoretical research to practical, production-grade cryptography. PIPEs should therefore not be treated as though it were a mature primitive with decades of battle testing behind it. The more useful question is whether a Witness Encryption construction can eventually be made secure and practical enough for this particular application. If proven so, it may become known as one of the most significant breakthroughs in applied cryptography since zero-knowledge proofs first became practical with Pinocchio in 2013 and later became widespread in blockchain tech in the 2020s.
Our research is making steady progress toward a Witness Encryption construction that is both secure and practical. It’s not there yet, and we’re not claiming otherwise. We have been deliberately attacking our own cryptographic constructions through cryptanalysis, open challenges, security auditing with external researchers, and open collaboration with outside researchers. That process has already yielded successful attacks that we’ve since resolved. So the conclusion at this stage isn’t that witness encryption has been proven secure. It’s that its security remains important to harden, and we are focused on doing that systematically. Keep an eye on our X for updates – and especially to get a chance at Bitcoin bounties we will offer as part of on-chain challenges; crack the scheme, and it’s yours!
#8: Isn’t the AADP Witness Encryption scheme broken?
The original construction was successfully attacked, and we have since fixed the scheme to address every identified attack. The AADP Witness Encryption construction published in February 2026 (link) was successfully attacked both through our own cryptanalysis and by researchers participating in [[alloc] init]’s Open Challenges (link). These attacks demonstrated a method to make a parametric rank drop within AADP matrices larger than we expected earlier, which reduced the complexity of brute-forcing a correct key through an incorrect witness (https://www.allocinit.xyz/posts/commutator-attack). We have since revised the construction to address the identified attacks and plan to formalize those changes in upcoming publications.
The distinction between “broken and subsequently fixed” and “still broken” matters. Finding and fixing attacks is a normal and valuable part of cryptographic research (e.g., MuSig2, Signal’s PQXDH), particularly at this stage of a new construction. But it would also be premature to treat an unpublished revision as though it had already received the scrutiny of the original proposal. The successful attacks are therefore neither evidence that the research has failed nor something to gloss over: they identified concrete weaknesses (the complexity of a parametric rank drop was reduced for sparse circuits), those specific attack vectors have been addressed, and the process of breaking, improving, and scrutinizing the construction continues.
#9: Don’t PIPEs require 338 TB? How could this possibly be practical?
Subsequent research has reduced the ciphertext size from approximately 338 TB to roughly 10 TB under current parameters — a more than 30x reduction since the original construction. The 338 TB figure reflects the AADP construction published in February 2026 (here), not the current state of the research. The ciphertext also does not need to be stored by each user. Because it can be public, storage can be outsourced or distributed across inexpensive, high-latency storage infrastructure without introducing an additional trust assumption.
While a substantial improvement, 10 TB is obviously still large. We do not present it as a production benchmark or promise, and reducing both ciphertext size and computational requirements even further remains an active area of research efforts. The claim that PIPEs “still requires 338 TB” is outdated. The broader question — whether PIPEs can ultimately become practical enough to deploy — remains open.
“Practical” also depends on the use case. PIPEs are not intended to be decrypted for every transaction. Moving and managing Bitcoin inside a shielded system does not require decrypting a PIPE at all; decryption is primarily needed to exercise the unilateral L1 vault exit mechanism. Users requiring frequent entry or exit could also use cheaper mechanisms, such as atomic swaps. The relevant question, then, is not whether PIPE decryption is cheap enough for every Bitcoin transaction, but whether its cost and latency are practical for the specific operations that actually require it.
#10: Can’t a circuit bug secretly inflate the supply?
First, Shielded Bitcoin cannot alter Bitcoin’s total supply.
The relevant risk is whether an implementation bug could create unbacked shielded claims against the BTC held in the system’s Bitcoin vaults.
That risk should be taken seriously. A sufficiently severe bug in the ZK circuit or protocol implementation could cause an invalid state transition to be accepted. Mitigating this requires formal verification where possible, audit-friendly tooling, independent audits, adversarial testing, and extensive cryptographic review.
The protocol constantly enforces two critical invariants to ensure supply integrity:
Transfers within the shielded system cannot create value (and the supply is being checked using ZK proofs within the circuit during each encrypted note formation).
Shielded issuance cannot exceed the amount of BTC committed to the system. Because PIPEs require cryptographic proof during peg-out, Witness Encryption will not decrypt a key to allow a user to retrieve BTC on the L1 if the notes do not pass validity checks.
These invariants are designed to prevent inflation at both the shielded transfer and L1 settlement boundaries, significantly reducing the underlying risk. The most critical remaining risk lies in implementation: bugs that could undermine these guarantees. Preventing them requires rigorous testing, independent audits, formal verification where possible, and adversarial review. Zcash’s historical inflation vulnerability is a useful reminder of why these invariants deserve particularly aggressive scrutiny.
#11: Can Shielded Bitcoin and PIPEs become quantum-safe?
Yes, the architecture is designed to be cryptographically adaptable, although post-quantum security ultimately also depends on Bitcoin itself becoming quantum-safe.
For signatures, the key encrypted within PIPEs could move from Schnorr to a post-quantum signature scheme such as SHRINCS. For ZK proofs, the underlying proof system could similarly be replaced with one based on post-quantum-friendly assumptions, including hash-based constructions using functions such as Poseidon (created by our colleague Markus Schofnegger and others), while much of the circuit logic remains unchanged.
We’re also designing around “harvest now, decrypt later” risks, where ciphertext collected today could potentially be attacked by future quantum computers. There are meaningful efficiency and security tradeoffs to work through, but PIPEs and Shielded Bitcoin are not fundamentally locked into today’s cryptographic primitives. The primary external dependency is Bitcoin L1’s own path toward post-quantum signatures.
#12: Does Bitcoin need a soft fork for any of this?
No. Bitcoin continues to process ordinary Bitcoin transactions under its existing consensus rules, while Shielded Bitcoin applies its own metaprotocol rules to data published and ordered by Bitcoin. No new opcodes, consensus changes, or soft forks are required.
But “no change to Bitcoin” shouldn’t be confused with “nothing else needs to be built.” There is a lot that needs to be formalized at the security level and built at the engineering level.
That is probably the most useful way to understand Shielded Bitcoin and PIPEs today. They are research proposals rather than finished products, and some of the hardest questions — particularly around Witness Encryption security, performance, and the vault boundary — remain open. At the same time, several common criticisms assume architectural properties the proposals don’t actually have, such as a separate blockchain, an independent consensus mechanism, or a federation that controls the underlying Bitcoin.
So the interesting debate isn’t whether the cryptography has been solved or whether Shielded Bitcoin is production-ready.
The more consequential question is: what becomes possible if the underlying cryptography can be made secure and practical? If PIPEs and Witness Encryption work, the implications extend far beyond Shielded Bitcoin. They could open an entirely new design space for Bitcoin: privacy, covenants, programmable vaults, non-interactive ZK verification, and new metaprotocols — without requiring Bitcoin itself to change.
That’s why we think our work is worth attacking, breaking, improving, and scrutinizing. There are hard problems left to solve, and the work should be judged by whether it survives that process. So attack it. Find the weaknesses. Suggest improvements. Build on it.
We believe that PIPEs and Shielded Bitcoin are not only possible, but just the beginning of what we can build on Bitcoin. We still have a long way to go, and we plan to move forward carefully and steadily, one step at a time.
Thanks to Clara Shikhelman and the rest of the [[alloc] init] team for making themselves available for this FAQ. Clara has served as the Head of Research at Chaincode Labs since 2022, and now leads protocol research at [[alloc] init] on Shielded Bitcoin, a proposal for private Bitcoin transactions.