Phase 3: Aggregated Private Note Transfer

Phase 3 — ML-KEM Private Notes, Beaconless Binding, and Chain-Verified Groundwork for Private Payments on Bitcoin Cash Summary Thank you to the Bitcoin Cash community for the continued support across these privacy-focused funding rounds. Phase 1 demonstrated an SRPA-style stealth payment proof of concept. Phase 2 demonstrated beaconless output binding: BCH covenant logic can bind statement material to real transaction outputs without obvious metadata beacons such as OP_RETURN. BCH Cloak Phase 3 builds the next layer: Aggregated Private Note Transfer (APNT). This round funds concrete BCH-native privacy groundwork: ML-KEM encrypted private note recovery, beaconless output binding, covenant-bound import funding, deterministic APNT commitment helpers and test vectors, WizardConnect signing, Fulcrum verification, local JSON aggregator handoffs, and an initial chain-backed private note design with multi-user aggregation. The goal is not to claim final private money. The goal is to prove the minimum working foundation for private note transfer on BCH while documenting the remaining conservation-proof work needed for future chain-native privacy. Verbose details are available here. Why this matters Physical cash does not publish a social graph. Most online payments do. BCH already has powerful ingredients for better payment privacy: UTXOs for one-time settlement and double-spend prevention covenants for enforceable transaction rules CashFusion-style intuition for multi-user transaction privacy fast low-cost payments improving VM capabilities Phase 3 uses those ingredients to move toward private note transfer without custodians, committees, trusted aggregators, or obvious metadata beacons. What Phase 3 demonstrates Phase 2 showed that BCH transaction outputs can be bound to committed statement material without obvious beacons like OP_RETURN. A covenant can recompute a compact fingerprint of the transaction’s real outputs and require that it match the supplied statement commitment. Phase 3 uses that idea to build the next layer: transparent BCH enters a covenant-bound import flow, wallets create deterministic commitments, note recovery material is encrypted with ML-KEM, and recipients can recover and verify chain-backed private note candidates. In plain English: Phase 2: prove the BCH outputs match the committed statement, without a beacon Phase 3: use that beaconless binding with ML-KEM recovery and BCH UTXO uniqueness to build the first chain-backed private-note candidate flow on BCH This is also a recovery story. Private note wallets must survive lost local state. BCH Cloak’s target recovery model uses deterministic note commitments and encrypted recovery packet bindings so a wallet can rescan chain-observed packet data, recover candidate note material with ML-KEM, recompute commitments, and verify the result against BCH chain evidence. This resembles the useful in-band recovery pattern from Zcash, where wallets scan encrypted chain data and verify recovered notes locally. BCH Cloak does not claim Zcash equivalence. It adapts that recovery idea to BCH covenant structure and a more post-quantum-oriented ML-KEM packet layer. Main technical challenge: private conservation The crucial unsolved problem is conservation. A private note system must prove that hidden input value equals hidden output value plus fees without revealing the amounts, owners, or sender/recipient linkage. Hiding data is not enough. The system must also prove nobody created money. Phase 3 does not claim full hidden-value conservation. Instead, it builds the integration baseline and proof roadmap needed to solve it. Target direction Pedersen commitments: Hide values and support additive balance checks STARK/hash proofs: Prove range validity, note correctness, nullifier correctness Packet binding, output derivation, and proof transcript binding BCH UTXO uniqueness: Provides chain-backed double-spend protection at the public boundary Aggregation: Improves anonymity sets without making the aggregator protocol truth What Phase 3 buys Milestone 1 — Beaconless Import Funding and ML-KEM Recovery Goal: Demonstrate transparent BCH entering a covenant-bound import flow and producing wallet-verifiable private note candidate evidence. Deliverables: APNT import funding covenant template as the first chain-anchored entry point deterministic APNT commitment helpers and test vectors ML-KEM recovery packet reference example beaconless output-binding evidence wallet-side note-candidate verification flow Acceptance criteria: A transparent BCH UTXO can enter the import flow on chipnet. The transaction output boundary is verified using beaconless output binding. The recipient can recover note material using ML-KEM packet data. The wallet verifies the recovered note candidate against commitments and evidence. No OP_RETURN beacon or reusable receive descriptor is placed on-chain. Milestone 2 — Wallet and Chain Integration Goal: Make the flow usable through normal BCH wallet/dapp integration patterns. Deliverables: WizardConnect signing flow where Electron Cash signs only the transparent funding input Fulcrum verification evidence for broadcast/output checks local JSON aggregator handoff object proof-bound P2S scaffold showing compact statement binding public evidence artifacts Acceptance criteria: The wallet never exports private keys. The aggregator does not custody funds. Fulcrum evidence verifies the public chain boundary. The handoff object is deterministic and inspectable. Transport is not treated as protocol truth. Milestone 3 — Initial Multi-User Aggregation Goal: Demonstrate the privacy direction by combining independently prepared note-candidate handoffs. Deliverables: at least two independently prepared wallet/import handoffs one combined aggregation handoff or transaction flow aggregator broadcast path wallet-verifiable note-candidate evidence for each participant documentation of anonymity-set limits Acceptance criteria: Multiple participant handoffs are combined. The aggregator acts only as an assembler. No custody or protocol authority is introduced. Aggregation improves privacy by weakening linkage inference. No production privacy claims are made. Milestone 4 — Chain-Backed Private Note Design and Proof Roadmap Goal: Document the target APNT model and the proof work needed to solve conservation securely. Deliverables: chain-backed private note candidate object design chain-anchor rules modular value commitment interface proof profile interface proof-roadmap report proof-size/verifier-profile benchmark scaffold Acceptance criteria: The design explains BCH UTXO uniqueness in plain language. Consensus remains the double-spend boundary at the public layer. Full conservation requires range and hidden-balance proofs. Future verifier tracks are documented (STARK, BCH2026, TXv5, EC-opcodes). What backers will be able to verify chipnet transactions and txids beaconless output fingerprint evidence ML-KEM recovery packet test vectors deterministic APNT commitment test vectors WizardConnect signing logs Fulcrum verification evidence local JSON aggregator handoff examples multi-user aggregation evidence proof-roadmap reports Privacy non-negotiables Will not be placed on-chain: note plaintext note openings wallet seeds spend keys ML-KEM secret keys recipient contact keys static recipient markers reusable receive descriptors as identifiers The aggregator must not become: custodian validator by authority protocol truth shared-state sequencer recovery truth Non-claims production privacy Zcash or Monero equivalence full hidden-value conservation full range proof verification on-chain ZKP execution in CashVM post-quantum secure funds in all custody paths mature wallet UX or SDK Why fund this phase This phase funds the foundation, not hype. It delivers a BCH-native privacy demo while documenting what remains unsolved. It produces reusable patterns for future BCH development: beaconless output binding covenant-bound imports ML-KEM recovery flows deterministic APNT commitments WizardConnect signing Fulcrum verification JSON aggregator handoffs It also defines benchmarks for future BCH privacy upgrades, including TXv5 and EC opcode-based verification paths.