Phase 2 technical notes: how the plumbing works (and what comes next)

This post is the “implementation-oriented” companion to the Phase 2 fundraising announcement. It’s still Phase 2 level — the goal is clarity, not a full spec dump.

The short version: Phase 2 builds auditability, beaconless binding, state cells, and versioned interfaces so Phase 3 can add real on-chain proof verification without redesigning everything.

The phase ladder (where Phase 2 fits)

• Phase 1.x: prototype confidential asset components off-chain + early covenant patterns
• Phase 2: enforceable plumbing + demo UX on Chipnet (this campaign)
• Phase 3: on-chain verifier kernel for a selected proof system (planned next)

Phase 2 is structured to make Phase 3 feel like “plug in the engine.”

Why ZK? (privacy without giving up auditability)

Beaconless binding and state NFTs give us an auditable state machine on L1: the covenant can recompute what happened on-chain, and any output mutation causes the spend to fail.

ZK is the missing piece that lets us keep that auditability without forcing private details into public data.

Instead of publishing everything the chain would normally need to validate a transition (which notes were used, amounts, linkage, recipient context), a ZK proof lets the spender prove:

• “this state transition is valid under the rules”
• “conservation holds”
• “authorization checks out”

…while keeping the witness private.

It’s not “ZK instead of signatures” so much as “ZK instead of public disclosure.” We still enforce policy, but we don’t have to expose a static signing identity or leak a social graph just to prove correctness.

And the reason Phase 2’s binding work matters is simple: a proof only means something if it’s bound to the real transaction outputs. With output fingerprints, any change to outputs breaks the binding and the spend fails — so the proof can’t be replayed against a different on-chain result.

Core building block 1: Auditability by recomputation (make tampering fail)

The goal

Before I ask anyone to trust a ZK claim, I want the system to be legible and mechanically checkable: if the on-chain transaction data changes, the proof context should stop matching.

The Phase 2 approach

Phase 2 makes auditability a first-class property by binding private context to real on-chain outputs:

• the wallet constructs proof context using a fingerprint of the actual outputs
• the covenant recomputes that fingerprint from what’s on chain
• if anything about the outputs changes, the fingerprint changes and the spend fails

That same “what the chain actually did” commitment is carried forward in a state NFT as a compact 32-byte commitment, and it can only evolve by spending the current state cell under covenant rules.

Core building block 2: Beaconless output binding

The problem

If private context (or a proof transcript) can be replayed against different outputs, you get silent linkability and tampering risk.

The Phase 2 solution

Compute a fingerprint from the transaction’s real outputs inside the covenant, then require it matches a claimed digest.

Conceptually, the fingerprint commits to chain-visible fields like:

• output values (as applicable)
• CashTokens fields (when present)
• a commitment to each output’s locking script/template

No OP_RETURN. No metadata beacon. If any output changes, the fingerprint changes and the spend fails.

Why it matters

This is the bridge between:

• privacy logic off-chain (wallets and proof systems), and
• enforcement on-chain (covenants that reject tampering)

…without making privacy transactions easy to fingerprint.

Core building block 3: “State NFTs” as portable state cells

On a UTXO chain, there isn’t a single global contract storage slot. State must live inside spendable objects.

Phase 2 uses a CashTokens NFT as a portable state cell:

• the token commitment carries compact state commitments (hashes/roots/version tags)
• every update spends the old state NFT and creates a new one
• the covenant enforces correct state evolution

The mental model:

• State NFT = the state carrier
• Beaconless binding = the anti-tamper seal tying private context to the real spend

Core building block 4: interfaces that survive upgrades

Phase 2 treats interfaces like consensus-critical design artifacts, even when verification is still evolving:

• versioned public inputs (binary, fixed layout)
• proof-blob ABI: parse → hash → bind (bounded sizes)
• deterministic transcript hashing with domain separation
• CI budget gates (bytes/ops/loops/stack)

This is the difference between “a demo” and “a protocol direction.”

Wallet-local sharded pools (why this is the scaling shape)

Instead of one global pool, Phase 2 starts with wallet-local shards:

• each wallet maintains multiple independent shard state cells
• deposits/imports/withdrawals touch one shard at a time
• the structure is ready for stronger Phase 3 privacy (nullifiers, conservation, etc.)

This avoids early “global pool bootstrapping” problems and reduces contention by splitting state across independent cells.

Post-quantum readiness, in implementation terms

Phase 2 does not claim post-quantum security today.

Implementation-wise, readiness means: move from pay-to-keys as the end state toward pay-to-scripts as the long-term control surface.

A practical bridge pattern (often called “Phase 2.5”) is a vault-like lane:

• Receive: stealth-style one-time receive output (RPA)
• Park: roll into a covenant-governed vault/state cell
• Release: enforce policy gates (rate limits, delays, constraints)
• Authorize later: swap authorization backend when PQ primitives/verifiers are available

That “new lane” approach mirrors how Zcash supports both transparent and shielded pools: migration into stronger modes happens over time.

Why Electron JS GUI in Phase 2 (yes, it’s part of the security story)

Phase 2 prioritizes an Electron desktop demo app because community verification matters:

• guided funding → lock → return → spend flow
• log pane + deterministic replay
• explorer links so anyone can validate it’s real

A privacy system that can’t be independently reproduced tends to become either vaporware or trustware.

What to expect in follow-up technical posts

This post is intentionally high-level. The next technical posts will go deeper on:

• the exact output fingerprint policy and golden vectors
• bounded parsing + hashing for the proof-blob ABI
• state-cell covenant templates and loop-budget discipline
• threat model notes (including “STARKs aren’t automatically ZK” considerations)
• integration guidance for wallet tooling and scanning

How to contribute

If you’d like to support Phase 2 directly, the best place to start is the funding announcement post:

• Visit: Phase 2 Funding is Now Live — Beaconless Binding + Sharded Pool Plumbing

If you’re a wallet, exchange, or infrastructure project and want to get involved more deeply, reach out — especially if you’re interested in:

• sponsorship,
• co-designing integrations,
• commissioning specific features (wallet plugin, server infra, docs, or test vectors).

If financial support isn’t an option, reviewing the design, sharing feedback, or trying the prototype once it’s public already helps a lot.

The vision is simple:

A Bitcoin Cash wallet that can live entirely in SRPA space — receive → fuse → send — while remaining 100% compatible with today’s network.

If that’s a future you want to see, any form of support helps move it from demo to reality.