From Paycodes to On‑Chain ZK: The Phase Ladder Toward Cash‑Like Privacy on Bitcoin Cash

Bitcoin Cash already nails fast, low-fee payments. The harder problem is privacy that still plays by L1 rules: observers shouldn’t learn who paid whom or how much, while the network still enforces authorization, no inflation, and no double-spend.

Here’s the simple “phase ladder” we’re building and why each rung matters.

Phase 1: prove the basic flow (notes + RPA delivery)

Phase 1 proves the basic flow: use paycodes/RPA-derived one-time addresses plus a covenant-locked CashTokens NFT “note” so Alice and Bob can pass a note through a covenant and return it using mostly standard-looking transactions, without requiring trusted parties.

In the current demo, there are still optional “leaky” conveniences (e.g., an explorer-friendly dust marker output, and a conventional fee input that can link to a base wallet via common heuristics). Those are demo choices, not protocol requirements.

The main value of Phase 1 is that it makes the shape real: normal transaction types, no trusted parties, and a concrete end-to-end demo you can run.

Note: routing change via self-RPA (to avoid linking back to a static wallet address) is a planned improvement, but not required for Phase 1.

Phase 1.5: make the note carry a hidden amount (commitment + envelope)

Phase 1.5 builds directly on Phase 1 by making the note carry a Pedersen commitment C to a hidden amount and introducing an envelope (range proof + binding fields) whose hash is bound into the on-chain context. That lets a wallet (or any off-chain verifier) deterministically verify that the claimed amount matches the on-chain commitment and the transaction context, without relying on any trusted indexer or third party.

This is the “amount claim becomes cryptographic” milestone: the note carries a committed amount and a deterministically verifiable envelope bound to the on-chain context.

In this phase the BCH output values are still visible on-chain.

The important piece is we are now proving the commitment/binding and verification machinery that enables future confidentiality.

Phase 2: make it ZK-ready (interfaces + binding + budgets)

Phase 2 turns what we already have (notes + commitments + off-chain verifiability) into a ZK-ready system by adding the missing infrastructure: stable public-input encoding, canonical hashing/transcript rules, bounded proof-blob parsing, cost/size budget gates, and binding primitives like beaconless output binding so proofs are tied to the transaction’s real outputs without extra metadata.

If Phase 1.5 proved “we can carry commitments and verify off-chain,” Phase 2 proves “we can safely host proof plumbing on-chain and swap proof systems later without redesign.”

Phase 3: enforce confidential rules on-chain (verifier kernel)

Phase 3 is where we pick a concrete proof system and implement the on-chain verifier kernel so the chain itself can enforce the confidential rules (identity authorization and/or amount conservation + range constraints).

This is the point where the network can validate confidential behavior directly, instead of relying on “off-chain verification + on-chain binding primitives.”

Feature matrix: what changes in each phase

Paycodes / RPA one-time addresses

Phase 1 — Used to return the note to a derived one-time address so recipients can recognize/spend without exposing a static address.

Phase 1.5 — Same flow, but now off-chain verification ties what you received to a committed amount and context.

Phase 2 — Same flow, plus hardened binding rules so proofs/claims can’t be replayed against different outputs.

Phase 3 — Same flow, now paired with on-chain verification so the chain can enforce confidential rules directly.

Covenant-locked note (CashTokens NFT)

Phase 1 — The note is an NFT that can be passed through a covenant and returned, acting as a portable state object.

Phase 1.5 — The note’s NFT commitment carries a Pedersen commitment C to a hidden amount.

Phase 2 — The note/state model stays, but interfaces and parsing rules are stabilized so ZK systems can plug in safely.

Phase 3 — The state transition is enforced by the verifier kernel (the proof must validate for the update).

Amount envelope (proof + binding fields)

Phase 1 — Not present. Amount is just BCH value on outputs.

Phase 1.5 — Introduced: envelope carries a range proof plus binding fields; its hash is bound on-chain so wallets can verify deterministically off-chain.

Phase 2 — Formalizes how proofs/envelopes are encoded, hashed, and budgeted so they’re safe to process and compatible with future kernels.

Phase 3 — Becomes part of the on-chain proof system enforcing range constraints and conservation (and possibly identity).

On-chain binding to context

Phase 1 — Covenant logic binds spends/returns of the note; privacy mostly comes from address derivation (RPA). (Optional demo conveniences may still leak heuristics.)

Phase 1.5 — Adds cryptographic binding: C in the NFT commitment and proofHash(envelope) bound into the covenant context.

Phase 2 — Adds beaconless output binding so proof context is tied to real outputs without OP_RETURN markers.

Phase 3 — Output binding becomes a hard requirement for valid on-chain proof verification.

Stable public inputs / ABI

Phase 1 — Not a focus.

Phase 1.5 — Emerging pattern (proof-as-bytes + hashes), but not standardized.

Phase 2 — Delivered: versioned public input encoding, proof-blob ABI, canonical transcript hashing rules.

Phase 3 — Used by the chosen proof system’s verifier kernel.

Bounded parsing + budget gates

Phase 1 — Not a focus.

Phase 1.5 — Not a focus.

Phase 2 — Delivered: bounded parsing rules plus CI budget gates for bytes/ops/loops/stack.

Phase 3 — Required to keep the verifier kernel feasible and safe under VM constraints.

What the chain enforces vs what wallets verify

Phase 1 — Chain enforces covenant rules; privacy mostly comes from address derivation (RPA).

Phase 1.5 — Chain enforces hash/commitment bindings; wallets can verify the hidden amount claim off-chain.

Phase 2 — Chain enforces binding and structure; wallets can produce proofs under stable interfaces.

Phase 3 — Chain verifies proofs and enforces confidential rules (identity and/or amount conservation + range constraints).

Primary done outcome

Phase 1 — End-to-end note flow via covenant plus RPA return on chipnet.
Phase 1.5 — Deterministic off-chain amount verification tied to on-chain commitment and context.
Phase 2 — ZK-ready infrastructure plus beaconless binding and a runnable harness (and the demo UI, per the funding plan).
Phase 3 — Full on-chain verifier kernel for the selected proof system.

Quick mental model

Phase 1 answers “can we pass a note privately using standard transaction shapes, without trusted parties?”
Phase 1.5 answers “can that note commit to a hidden amount that wallets can verify deterministically?”
Phase 2 answers “can we standardize, bind, and budget the proof plumbing so ZK can plug in safely?”
Phase 3 answers “can the chain verify the proof and enforce confidential rules directly?”

Donate

If you want a single headline: Phase 2 is the bridge that turns a working demo into a system that can graduate into real on-chain ZK verification.

If you’d like to support more of this kind of research and engineering, you can send a tip in Bitcoin Cash.

Every bit helps carve out time for the unglamorous parts of this work: writing specs, tightening scripts, building reference implementations, and iterating toward a privacy stack that’s actually deployable in wallets instead of just living in whitepapers.