Bitcoin may soon gain Zcash-like shielded privacy without altering its protocol rules

A Thursday paper has proposed Shielded Bitcoin, a privacy design that would keep encrypted transfer data on Bitcoin while leaving the route for ordinary BTC into and out of the system unresolved. The proposal describes how accepted payments could be reconstructed from the public record using wallet keys, but the 56-page specification does not explain how users would enter or release BTC. That gap has drawn criticism from developers and Zcash supporters, who say the missing mechanisms are material because deposits and withdrawals are reserved for a separate paper.

The Zcash connection predates the proposal

The connection to Zcash goes back further than Thursday's paper. Zerocoin was proposed as a privacy extension to Bitcoin in 2013, and the subsequent Zerocash research developed into Zcash, which launched as a separate cryptocurrency in 2016. That history frames the new proposal as part of a long privacy research line rather than a stand-alone product announcement.

For readers, the lineage matters because it shows where the design ideas have been tested before. The proposal does not start from zero: it sits on earlier privacy extensions to Bitcoin and on the research path that became Zcash. At the same time, the paper itself is evaluated by what it specifies now and what it leaves for later.

What Shielded Bitcoin would keep on Bitcoin

Shielded Bitcoin would keep the encrypted transfer data on Bitcoin so users could reconstruct accepted payments from the public record using their wallet keys. Separate viewing keys would allow them to disclose transactions to an accountant or auditor without handing over permission to spend their funds.

The design therefore splits access into different types of keys. A wallet key can reconstruct accepted payments from encrypted transfer data on the public record. A separate viewing key can reveal transaction information to a selected recipient, such as an accountant or auditor, without giving that recipient the ability to spend the funds. This distinction is the proposal's clearest answer to one privacy-and-compliance problem: how to show transaction history while keeping spending control with the user.

The unanswered BTC entry and exit question

The 56-page specification does not explain how ordinary BTC would enter that system or be released when someone wanted to withdraw. The authors reserve those mechanisms for a separate paper using PIPEs, a technique designed to lock a Bitcoin signing key until specified conditions are met.

Their claim that users retain control of their funds covers transfers inside the system and explicitly excludes deposits and withdrawals. That wording creates a boundary between what the proposal can support now and what it promises later. Inside the system, users could hold or move shielded value and use viewing keys to disclose activity. But the path from actual BTC into the system and back out remains outside the 56-page paper.

Critics call it a synthetic ledger with tradeoffs

The omissions have drawn criticism from developers and Zcash supporters. Mert Mumtaz, cofounder of Helius, which provides infrastructure for Solana developers, and a Zcash proponent, described the proposal on X as "a synthetic ledger with significant tradeoffs."

He pointed to "a trusted setup" and "no fee anonymization," meaning the Bitcoin wallet paying to publish a private transfer could still be visible. He also criticized the absence of a deposit and withdrawal mechanism, writing that there was "no in-protocol mechanism for getting actual BTC in or out (which means you are holding synthetics)."

The criticism focuses on three practical gaps. First, a trusted setup introduces a condition that the paper does not resolve. Second, no fee anonymization means the publishing wallet can remain visible even if the transfer data is encrypted. Third, without an in-protocol route for actual BTC in and out, the proposal may be described as a synthetic system rather than a complete BTC privacy layer.

What readers should watch next

The next step is the separate paper using PIPEs. That paper would need to show how ordinary BTC enters the Shielded Bitcoin system and how value is released when someone wants to withdraw. Readers should also watch whether the deposit and withdrawal design changes the claim about user control, because the current 56-page specification limits that claim to transfers inside the system.

For now, the proposal gives readers two distinct layers of information. It specifies a way to keep encrypted transfer data on Bitcoin, reconstruct accepted payments with wallet keys, and share selected transaction history with viewing keys. It also leaves the BTC entry and exit path unanswered, which is why developers and Zcash supporters are treating the gaps as significant rather than cosmetic.