Phase 2 funding is now live: Beaconless Binding + Sharded Pool Plumbing for Cash‑Like Payments on Bitcoin Cash
Make cash-like payments on BCH legible, repeatable, and upgradeable — without OP_RETURN beacons.
Bitcoin Cash is great at fast, low-fee payments — but like most cryptocurrencies, typical transactions still broadcast a lot of information: who paid whom and how much. Physical cash doesn’t do that.
Phase 2 is the step where this project stops being “just research” and becomes something the community can run, inspect, and verify end-to-end on Chipnet — Bitcoin Cash’s test network for upcoming upgrades and CHIP testing.
If you want BCH to lead on usable privacy without adding new trust assumptions, this is the phase to back.
Campaign link: https://fundme.cash/campaign/94
Jihan’s reminder: borrow the best ideas, then make BCH better
During the blocksize wars, Jihan Wu posted a reminder that still applies:
That’s the posture of this work: take what’s proven elsewhere, strip the complexity and trust layers, and implement it directly on BCH’s UTXO rails.
What Phase 2 is (and why it matters)
Phase 2 is the scaffolding phase: it’s not the flashy “privacy reveal,” but it’s what turns an idea into something you can run, inspect, and verify — on-chain, in code, and in a real UI.
It funds three things, intentionally in this order:
- A community-verifiable on-chain demo on Chipnet
- Reusable packages that other wallets and builders can audit and re-use
- A desktop demo UI so non-experts can reproduce the full flow without living in a CLI
The goal is to make Phase 3 feel like plug in the verifier kernel, not redesign the wallet and protocol boundaries.
What we learned from other chains (and how it shapes Phase 2)
This project is intentionally cross-chain informed: we adopt what works, learn from what didn’t, and innovate where the existing patterns fall short.
Zcash: let users move into privacy over time
Zcash supports both transparent and shielded address types/pools. That split teaches a key lesson: upgrades work when users can migrate into a stronger lane over time, not when we pretend every transaction flips to the strongest mode overnight.
Phase 2 applies the “lane” idea on BCH by building an upgradeable policy lane using covenants and tokenized state cells — so later phases can add stronger verification without rewriting the wallet UX.
Monero: hide the recipient by default
Monero’s stealth addresses require the sender to create a random one-time address per payment on behalf of the recipient, preventing address reuse from becoming a permanent identifier.
Phase 2 uses a stealth-style receiving approach (RPA) as the usability layer: it makes “cash-like receiving” practical on L1 while the deeper proof kernel arrives later.
Aztec and modern ZK systems: private balances as “notes” your wallet tracks
Aztec describes private state using UTXO-like “notes” where the chain stores note commitments, users prove knowledge of the note preimage when updating private state, and nullifiers prevent double-spends.
Phase 2 borrows the same design shape — wallet-local private state + proof-bound updates — while aiming to implement enforcement directly on BCH’s native UTXO model rather than introducing a separate L2 consensus domain.
eUTXO reality (Cardano lesson): shared state becomes a bottleneck
Cardano’s eUTXO docs highlight a simple UTXO truth: concurrency is limited by contention for shared UTXOs.
Phase 2 embraces this by starting with wallet-local sharded pools: each wallet maintains multiple shard state cells so the design scales without forcing everyone through one global choke point.
State cells (CKB-style thinking): upgrade state by spending and recreating it
Nervos CKB describes “cells” as primary state units that must follow validation rules specified by scripts.
Phase 2 mirrors this pattern on BCH by using CashTokens NFTs as portable state cells: compact commitments are carried in token commitments and advanced only by spending the old cell and creating the new one.
The Phase 2 unlock: beaconless output binding
If you want privacy and on-chain enforceability, the chain must be able to check:
“The private context/proof I’m presenting corresponds to these exact transaction outputs.”
Many systems solve binding with obvious metadata beacons (like OP_RETURN tags). That’s easy — and also easy to fingerprint forever.
Phase 2’s answer is beaconless output binding:
- the covenant recomputes a canonical fingerprint from the real outputs
- it checks
computed_fingerprint == claimed_fingerprint - if anyone mutates any output (value, token fields, locking script/template, ordering), the spend fails
No beacons. No marker outputs. Just enforcement by recomputation.
Why now: Chipnet + the 2026 upgrade path
Chipnet exists specifically to test CHIPs ahead of mainnet upgrades.
The May 2026 upgrade direction aims to make CashVM substantially more expressive and ergonomic for high-level contract design, improving wallet safety and reducing transaction sizes for many covenant and DeFi patterns.
Phase 2 is structured so that when the ecosystem is ready for on-chain proof verification, we already have the hard parts nailed down: transaction shapes, binding rules, bounded interfaces, and demo-level reproducibility.
What backing Phase 2 delivers
Phase 2 is designed to be community-verifiable:
- a runnable Chipnet demo with explorer-linked transactions
- a desktop UI that makes the flow auditable without CLI expertise
- published interfaces and test vectors that prevent “efficient leaks” later
If you’ve wanted to support BCH privacy engineering that is:
- non-custodial
- enforceable under normal node validation
- and honest about what is “done” vs “placeholder”
…this is the right campaign to back.
Campaign link: https://fundme.cash/campaign/94
