BCH CT Phase 2: Beaconless Output Binding, a Demo App, and the Path to On-Chain ZK Verification

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. Cash doesn’t do that.

This post explains the next concrete step we’re building toward cash-like privacy on BCH — and why our Phase 2 funding plan is split into two campaigns:

• Campaign 1 (Phase 2, now live): ship a community-verifiable chipnet desktop demo app + the “plumbing” that makes future on-chain ZK verification safe and inevitable.
• Campaign 2 (Phase 3, planned next): implement the on-chain verification kernel for a selected proof system.

The goal is to make Phase 3 feel like “plug in the engine”, not “redesign the car.”

The key 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.”

Adding an OP_RETURN “beacon” or other metadata that screams “this is a privacy transaction,” creating chainanalysis identifyers and potential attack vectors.

Beaconless Output Binding solves the same binding problem without adding a beacon.

What “beaconless” means in practice

When we say Beaconless Output Binding, we mean something simple:

The covenant can verify that a private payment is tied to the real transaction outputs — without adding any extra metadata output like OP_RETURN.

Here’s the high-level idea:

• The covenant computes a fingerprint from the transaction’s real outputs.

  • It derives a single 32-byte fingerprint from outputs the network already sees and validates.

• The wallet proves it’s talking about this transaction by matching that fingerprint.

• The wallet/tooling provides the expected fingerprint (or it’s carried by covenant parameters). The covenant requires:

  computed fingerprint == claimed fingerprint

• If anyone changes any output, it breaks.

• If output value, token fields, script/template, or ordering changes, the fingerprint changes and the spend fails.

• That’s the “binding” part: the private context cannot be reused with different outputs.

What goes into the fingerprint (conceptually)

We intentionally keep the exact byte layout as part of Phase-2 spec work, but conceptually the fingerprint is derived from only chain-visible, deterministic fields, like:

• output values (as applicable),
• CashTokens fields (when present),
• and a commitment to each output’s locking script/template (so the script is bound without adding a special marker output).

Why this matters

Beaconless binding is the bridge between:

• privacy logic off-chain (wallets and proof systems), and
• enforcement on-chain (the covenant can reject tampering),

without adding new metadata tells that make privacy transactions easy to identify or target.

The other Phase-2 building block: the “State NFT” (portable on-chain state)

Beaconless binding answers: “Are these the real outputs?”
But confidential protocols also need: “What is the current contract state, and how does it evolve?”

On a UTXO chain like BCH, there isn’t a global smart-contract storage slot. So we carry state inside UTXOs.

What a “state NFT” means in practice

In our design, a state NFT is a CashTokens NFT used as a portable state cell:

• It carries compact state commitments (think: small hashes / roots) in the NFT’s commitment bytes.
  Examples include:

  • a pool/state root,
  • a nullifier/spent-note root,
  • a version tag.

• Every update spends the old state NFT and creates a new one.
  The “state” advances by replacing the NFT that carries the old roots with a new NFT that carries the updated roots.

• The covenant enforces correct state evolution.
  It checks that the transition (old roots → new roots) matches what the proof/public inputs claim.

How the state NFT and beaconless binding work together

They’re complementary:

• The state NFT gives the covenant a compact, on-chain “anchor” for what state we’re in.
• Beaconless binding ensures that whatever proof/public inputs claim about this transition is tied to the actual transaction outputs — not a look-alike.

In other words:

• The state NFT is the state carrier.
• Beaconless binding is the anti-tamper seal that keeps the private context bound to the real spend.

Why we’re creating an Electron demo app

A lot of crypto “research” dies in the gap between good ideas and something real people can run.

Right now, the repo already has a working end-to-end chipnet demo flow (CLI-driven). Community feedback was clear: a UI would make the work easier to validate, easier to share, and harder to dismiss as “just a dev demo.”

So Phase 2 prioritizes a desktop demo app that:

• runs end-to-end on chipnet,
• guides a user through the flow (funding → lock → return → spend),
• shows progress, logs, and explorer links,
• makes it easy for anyone to validate “this is real” without being a JavaScript power user.

Important clarification:
This is an Electron app (the JavaScript desktop framework: Chromium + Node.js packaging).
It is not “Electron Cash” (the BCH wallet). The names are similar; the software is unrelated.

The elephant in the room: “STARK privacy leaks” (and why we’re strict about it)

You may have heard claims that some STARK-based systems “leak privacy.”

The simple version: many proof systems publish openings of committed structures. If witness-bearing data is opened without proper ZK masking/blinding, those openings can leak information. And if you recurse/batch such proofs, you can compress the leak — not fix it.

Our stance is clear and non-negotiable:

• Masking/blinding is not optional where applicable.
• Never recurse/batch non-ZK inner proofs.
• Never promote witness-bearing openings into public inputs.
• Domain separation + no randomness reuse across proofs/layers/batches.

Phase 2 is where we bake these rules into the engineering plan and harness so we don’t discover problems after deployment.

Public references on “STARKs aren’t automatically ZK”

A few public resources that explain why STARK/FRI systems require explicit ZK techniques (masking/blinding) to achieve privacy:

• “A note on adding zero-knowledge to STARKs” (Haböck & Al Kindi, 2024)
  https://eprint.iacr.org/2024/1037.pdf

• ethSTARK / STARK constructions & ZK considerations (IACR ePrint 2021/582)
  https://eprint.iacr.org/2021/582

• libSTARK (research implementation)
  https://github.com/elibensasson/libSTARK

(We’ll keep this list updated as Phase 2B threat-model work cites specific disclosures/analyses.)

The plan: build the verifier in layers, not a leap

The end-state is on-chain verification of succinct proofs (target <100KB) that enforce:

• confidential identities (who can unlock/authorize),
• confidential amounts (hidden values + enforced conservation),

…while updating a compact pool state carried in a CashTokens NFT commitment.

Phase 2 doesn’t claim we’re done with full proof verification. Phase 2 makes full verification inevitable and safe by delivering the interfaces, binding, budgets, and harness that Phase 3 will build on.

The covenant step we’re building toward

Input[0]:  State NFT (oldStateRoot, oldNullRoot, …)  +  proofBlob  +  publicInputs
              |
              | covenant verifies:
              |  - output fingerprint parity (beaconless binding)
              |  - publicInputs encoding + transcript hash
              |  - verifier kernel checks (Phase 3: full ZK verification)
              v
Output[0]: State NFT (newStateRoot, newNullRoot, …)  +  (optional) note/commitment update

What Phase 2 delivers (Campaign 1 of 2)

Phase 2 includes two milestones, intentionally ordered:

Milestone 1 — End-to-end Demo UI (Electron, chipnet)

Deliverables:

• Electron desktop app (initial packaging target: macOS + Linux)
  • Windows builds are “best effort” unless we get community help testing/signing.
• Mode picker + guided flow for the confidential asset demo
• “Funding step” screen with address + required sats + re-check button
• Live logs pane (events streamed from the demo runner)
• Explorer links + copy buttons
• Deterministic replay mode (so issues are reproducible)

Outcome:

• A community-friendly way to verify the demo flow end-to-end.

Milestone 2 — ZK Plumbing (interfaces + budgets + harness)

Deliverables:

• Public Inputs Spec v0 (binary, versioned)
• Proof-Blob ABI v0 (parse → hash → bind), with explicit size limits
• Canonical hash policy (domain-separated tags; stable transcript hashing)
• Beaconless output fingerprint parity spec + reference tool + vectors
• Budget tables + CI budget gates (bytes/ops/loops/stack)
• Backend evaluation harness (benchmarks + proof size and verifier modeling)
• Runnable prototype harness tying together:
  • output binding,
  • proof blob parsing/transcript hashing,
  • state NFT “pool skeleton” (roots + deterministic updates),
  • off-chain proof object pipeline (backend may be placeholder initially)

Outcome:

• Phase 3 can focus on the kernel, not on re-arguing formats, hashes, and budget discipline.

Campaign 2 preview: Phase 3 (separate FundMe)

Phase 3 is the follow-on campaign where we implement the verification kernel for a selected proof approach, plus batching strategy and state-root evolution (pool + nullifiers).

Phase 2 is designed so Phase 3 is “plug in the engine,” not “redesign the car.”

Wrap-up: why two campaigns

This project’s end-state is ambitious but concrete:

On-chain verification of succinct ZK proofs (<100KB) to enforce confidential identities and confidential amounts without leaking metadata, while updating compact pool state carried in a CashTokens NFT commitment.

We’re funding it in two campaigns because it keeps the work legible, testable, and honest:

• Campaign 1 / Phase 2: ship the demo app + the binding/interfaces/budgets/harness.
  (So anyone can run it, inspect it, and see exactly what’s “done.”)

• Campaign 2 / Phase 3: plug in the real on-chain verifier kernel.
  (The heavy cryptographic engine work — enabled by Phase 2’s groundwork.)

If you’re a backer, a reviewer, or just curious: this structure is meant to make progress easy to track and hard to hand-wave.

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.