Why I Think Privacy Doesn’t Just “Drop Into” BCH Wallets
BCH-CT has reached an important design checkpoint.
The early framing was:
How do we add confidential transactions to BCH wallets?
That is still the eventual integration question, but it skips over the deeper architecture question:
How do we build a BCH-native private payment mode when BCH does not have native shielded-pool consensus like Zcash or default privacy rules like Monero?
That distinction matters a lot.
It changes the work from “add a new address type” into a larger protocol/app-layer design problem: private notes, encrypted note delivery, proof-based authorization, wallet accounting, aggregation, and BCH settlement.
Why this is harder than “add a new address type”
A normal BCH wallet is built around:
keys -> addresses -> UTXOs -> signatures -> broadcast
That model works well for transparent payments.
But confidential payments move the problem into a different model:
private notes -> commitments -> nullifiers/spend markers -> proofs -> encrypted note delivery
In other words, the important shift is from key-based authorization to proof-based authorization.
On transparent BCH, the chain asks:
Did the spender satisfy this visible script/address condition?
In BCH-CT, the chain should eventually ask:
Does this proof show that a valid private note was spent, value was conserved, and new private notes were created correctly?
That is why trying to make an ML-KEM key, Nostr key, or Quantumroot vault behave like a normal BCH address does not really solve the core problem.
ML-KEM is useful for encrypted note delivery.
Nostr may be useful for message transport.
Quantumroot is useful for post-quantum custody.
But none of those are the same thing as a private-note authorization model.
What other privacy chains have that BCH does not
Zcash privacy is not just a wallet feature. Zcash made shielded transactions a first-class part of the protocol: shielded notes, note commitments, nullifiers, encrypted note data, and proof verification are all part of the native shielded transaction model.
Monero also does not bolt privacy onto ordinary visible addresses. Its privacy model combines stealth addresses, RingCT, and spend/view key separation so recipient identity and amounts are not represented like ordinary public UTXO payments.
Dash PrivateSend is closer to BCH’s existing CashFusion pattern: it uses non-custodial CoinJoin-style coordination to make transaction history harder to trace, but it is not a private-note protocol like Zcash or Monero.
That is the key difference:
Zcash:
native shielded-pool consensus
Monero:
native privacy transaction model
Dash / CashFusion:
non-custodial mixing of transparent coins
BCH-CT:
currently being explored as a BCH contract/app-layer protocol
So BCH-CT cannot just “copy Zcash” without consensus changes. It has to use BCH-native primitives: UTXOs, covenants, CashTokens, proof-bearing scripts, and optional coordination.
The SLP / CashTokens analogy
The closest BCH historical analogy may be SLP before CashTokens.
SLP filled the token gap before BCH had consensus-native tokens: wallets, indexers, and applications interpreted token rules on top of normal BCH transactions. Later, CashTokens made token functionality first-class at the BCH consensus/VM layer.
BCH-CT may be doing something similar for privacy. BCH does not currently have native shielded-pool consensus, so this work explores what can be done at the contract/app layer first. If the model proves useful, it may help clarify what a future native BCH privacy proposal would actually need.
The analogy is not perfect: privacy is harder than tokens. BCH-CT has to deal with private notes, nullifiers, proofs, encrypted note delivery, wallet recovery, metadata leakage, and post-quantum assumptions. But the pattern is familiar: explore at the application layer first, learn the real requirements, then decide whether any part belongs in consensus later.
Why not make privacy more chain-native?
The obvious question is:
If Zcash made privacy native, why not do the same thing on BCH?
That may be a valid long-term direction. BCH could eventually consider a consensus-level privacy proposal with native note commitments, nullifier sets, proof verification, encrypted note fields, and pool accounting.
That would be the closest BCH equivalent to Zcash.
But it is also the largest path. It would require a serious CHIP process, broad ecosystem review, wallet changes, node implementation work, long-term maintenance, and agreement that private notes should become a first-class BCH consensus feature.
That is not the smallest next step.
The more immediate question is:
What can BCH do with the primitives it already has or is already gaining?
That led to direct state cells first.
A direct state cell is very BCH-native:
state cell UTXO exists
wallet spends it with valid covenant/proof data
new state cell UTXO is created
BCH consensus enforces single-spend
That path is decentralized, self-sovereign, and fits the UTXO model.
The problem is privacy.
If Alice’s private activity visibly advances like this:
Alice state cell -> Alice next state cell -> Alice next state cell
then the state-cell lineage can become Alice’s activity graph.
So the current design keeps direct state cells as the base/fallback primitive, but no longer treats visible one-user state-cell advancement as the final privacy boundary.
Where Quantumroot fits
Quantumroot is extremely important, but it solves a different layer.
Quantumroot is a post-quantum vault/custody design for BCH. It protects visible BCH UTXOs with hash-based post-quantum authorization paths and aggregation techniques.
That is not the same thing as confidential transactions.
Quantumroot answers:
How do I hold and later spend BCH safely in a quantum-threat model?
BCH-CT is trying to answer:
How does Alice privately pay Bob without the chain showing Bob’s normal recipient output,
the private amount, or Alice’s ordinary transparent change?
So the practical stack may become:
CashFusion:
improve transparent input provenance
Quantumroot:
PQ-safe custody before/after private mode
BCH-CT:
private note transfers inside private mode
Why CashFusion + Quantumroot may be enough for some users
This is worth saying plainly.
For many users, CashFusion + Quantumroot may be the right near-term privacy/security stack.
It gives:
better transparent coin history
+
post-quantum custody
That is valuable.
But it does not give:
hidden payment amounts
hidden sender residue/change
private note transfer
proof-based private spends
the ability to stay inside a private payment mode across multiple hops
That is the reason BCH-CT still exists as a separate research path.
If BCH-CT cannot deliver private notes, hidden amounts, hidden residue, and proof-based private transfer, then it is probably not worth the complexity.
Why this MVP design was chosen
The current MVP direction is:
direct state cells as the base/fallback path
+
CashFusion-like aggregation as the privacy boundary
+
private notes as the internal payment object
Instead of Alice directly advancing her own visible state cell, Alice creates a spend intent.
That intent says:
I authorize my current BCH-CT state cell to be consumed
only if this batch creates the private note commitments I committed to.
Alice submits that intent to one or more aggregators.
The aggregator is not a validator.
It is not a shard manager.
It is not a sequencer.
It does not custody funds.
It does not decide protocol truth.
It is just a batch assembler, similar in spirit to CashFusion coordination.
The aggregator collects many intents:
Alice intent
Bob intent
Carol intent
Dave intent
...
Then builds one BCH transaction:
many BCH-CT state cells in
many unordered private note commitments out
no ordinary transparent change
no public recipient marker
no obvious input -> output mapping
BCH validates the transaction. If the aggregator lies, redirects value, omits required commitments, or builds an invalid transition, the transaction fails.
That is why this design was chosen: it is more BCH-native than a managed pool or sequencer, avoids the single-UTXO bottleneck, avoids visible per-user lineage, and does not require immediate native shielded-pool consensus changes.
It is not “privacy off-chain.”
It is:
BCH validates settlement.
Users own their state.
Aggregators assemble batches.
Encrypted note delivery happens off-chain.
Recipients verify notes against BCH commitments.
Direct spend remains the fallback.
Where Nostr fits
Nostr should not be the protocol trust base.
But it can be useful as a message transport.
In the MVP, Nostr can carry:
aggregation intents
encrypted note envelopes
batch status messages
contact/discovery messages
It should not carry protocol truth.
The chain remains the settlement and validation layer.
The important line is:
Nostr routes encrypted note material.
BCH anchors settlement.
Proofs authorize private state transitions.
Alice to Bob in the updated model
1. Alice has BCH-CT private state from a prior import.
2. Alice wants to pay Bob.
3. Alice obtains Bob-compatible receive material off-chain.
This might use Nostr, QR, direct contact exchange, or another transport.
4. Alice creates Bob’s private note:
- private amount
- note randomness/opening
- commitment
- recovery material
5. Alice encrypts Bob’s note envelope, likely using ML-KEM-derived shared secret material.
6. Alice creates a spend intent:
- consume Alice’s current BCH-CT state cell
- create Bob note commitment
- create Alice residue note commitment
- pay fee/postage
- expire after height H
- no transparent change
7. Alice submits the intent to one or more aggregators.
8. Aggregator combines many intents into one BCH batch transaction.
9. BCH validates the batch.
10. Bob receives the encrypted note envelope.
11. Bob decrypts it, verifies that the note commitment appears in the accepted BCH batch, and imports the private note.
12. Bob later spends by submitting his own direct spend or aggregation intent.
What this borrows from other systems
From Zcash, BCH-CT borrows the note/nullifier/proof model.
From Monero, BCH-CT borrows the lesson that recipient identity should not become a public chain object.
From Dash/CashFusion, BCH-CT borrows the coordination pattern: non-custodial batch construction where the coordinator cannot steal funds.
From Quantumroot, BCH-CT can borrow BCH-native continuation, token authority, and post-quantum custody lessons.
From Cardano/eUTXO lessons, BCH-CT should avoid one global mutable UTXO or managed sharded state.
From SLP/CashTokens, BCH-CT borrows the historical pattern of exploring a missing feature at the application layer first, before deciding whether any part belongs in consensus later.
What BCH-CT is not claiming yet
This is not production Zcash-level privacy.
This is not a native shielded pool.
This is not complete post-quantum private money.
This is not solved wallet UX.
This is not a replacement for CashFusion or Quantumroot.
The honest current target is narrower:
Can BCH support an aggregated, proof-bearing private note transfer flow where users retain direct fallback, aggregators cannot steal or validate by authority, and visible state-cell lineage is broken by batch construction?
That is the MVP I think is worth building next.
Why this path may work on BCH
The reason I still think BCH is a good place to explore this is that BCH can validate rich covenant/script behavior directly on L1, while still preserving the UTXO model.
That means the design does not need to become an Ethereum-style rollup with a sequencer as the trust base.
The architecture I now see is:
BCH L1:
settlement, covenant/proof validation, fees, finality
BCH-CT app:
private notes, encrypted note delivery, wallet accounting, proof witnesses
Aggregation:
optional CashFusion-like batch assembly
Quantumroot:
PQ-safe custody at the transparent edges
Nostr:
optional message transport, not protocol truth
The goal is not to make privacy magically “drop into” existing BCH wallets.
The goal is to define a BCH-native private payment mode that wallets can eventually integrate once the protocol boundary is clear.
That is the next milestone.
References
@bitjson is also exploring zk prover. 
