Stacks Co-Founder Maps Confidential Transactions Above Bitcoin

By Nathan Brooks

Stacks co-founder Muneeb Ali proposed running confidential transactions on an execution layer above Bitcoin while keeping Bitcoin’s total supply open to public audit, according to his description of Stacks’ development plans.

Ali said: “confidential transactions could run on an execution layer while BTC’s total supply remains open to public audit.” He said: “privacy should not be built directly into Bitcoin’s base layer because its supply needs to remain auditable.”

Stacks is a Bitcoin-based network intended to add programmability to BTC and make it faster and less costly to use. The proposal does not put privacy rules into Bitcoin’s consensus process. Instead, it places confidential transaction handling in a layer above the base network, where transaction details could be hidden.

What does this change for Bitcoin users?

The practical change is the separation of transaction confidentiality from public supply verification. Users could receive confidentiality through an upper layer without giving up the ability to check the total supply. At minimum, that is the benefit Ali described; he did not present the system as a replacement for Bitcoin’s base-layer audit.

For developers and service operators, the design moves the privacy burden away from consensus rules and toward execution infrastructure. The unresolved work lies in determining how an execution layer proves that hidden transactions do not create or destroy supply. Ali’s description did not specify that mechanism, an implementation date or a deployment schedule.

This matters because an execution-layer approach can preserve Bitcoin’s existing rules even if the transaction data processed above it differs from ordinary visible transfers. The statement describes a possible development path, not a live feature with a disclosed launch window.

Where Stacks’ roadmap fits

Ali identified privacy as one of three named development areas for Stacks. The other two were:

• Quantum resistance, presented as an area for Stacks development.
• Applications that generate yield from BTC, extending the network’s development focus beyond transaction execution.

Taken together, the priorities place transaction privacy, quantum resistance and BTC-based yield applications within one development program. Ali presented them as separate workstreams and did not provide technical milestones, dependencies or a shared release schedule.

Stacks’ stated purpose is to add programmability to BTC and make it faster and less costly to use. Ali’s privacy idea adds confidentiality to that execution-focused remit rather than changing what Bitcoin’s base layer must reveal. The execution layer would handle private transaction details while the underlying network retained its public supply audit.

That division reduces the operational burden on Bitcoin’s consensus rules, but it does not remove implementation work from the privacy layer. Application developers and infrastructure providers would still need to support confidential transactions and reconcile their activity with the public supply constraint. The proposal as described does not establish fees, adoption, wallet support or an implementation timetable.

A second privacy design

A separate proposal for a shielded Bitcoin privacy layer would use its own transaction format and indexing process while leaving Bitcoin’s consensus rules unchanged.

That route differs operationally from the execution-layer model. The latter places confidential activity above Bitcoin. The shielded proposal, as described, introduces a dedicated transaction format and indexing process. The execution-layer model explicitly preserves public supply audits, while both approaches leave Bitcoin’s consensus rules intact.

For builders, this places integration work in transaction interpretation and indexing rather than in a change to Bitcoin’s consensus process. It also makes the shielded proposal additive: privacy services could use specialized records and indexing infrastructure without requiring Bitcoin itself to adopt those rules.

For service providers, however, separate transaction formats create a compatibility burden. Any wallet, block explorer or transaction service supporting shielded transactions would need to recognize and index the dedicated format. The proposal did not identify its technical specifications or responsible implementation parties.

The next test for builders is whether the execution-layer design can deliver hidden transaction details while preserving public supply checks, and whether the shielded proposal can introduce its own format and indexing process without altering consensus; neither has a disclosed deployment deadline.