Protocol map
Five records, five jobs
Each layer has one job. The pool anchors ciphertext and settlement, the wallet-derived key unlocks matching records locally, the bearer note preserves an independent recovery path, and the runtime keeps every piece pointed at the same deployment.
Value lifecycle
- The client verifies one wallet unlock signature and derives a chain-and-pool-bound recovery key.
- It prepares a template, child secrets, fixed-size encrypted recovery record, encoded recovery entry, and deposit proof. Wallet-derived recovery material is required. The client exposes it only after confirmation; exporting the bearer fallback is optional.
- The wallet deposits the template’s parent amount with one bundle commitment and encrypted recovery record.
- The pool inserts that commitment and accepts a new root.
- A later wallet connection scans public records, decrypts matching bundles locally, and selects no note automatically.
- The user selects one unspent child; the client proves ownership and membership without publishing the witness.
- The pool records that child’s nullifier, accrues the fee, and sends net ETH.
- Any sibling remains available under the original bundle commitment.
Read by question
- What identifies a deposited bundle?
- What prevents a second spend?
- Which amounts can a template use?
- How are fees and the remaining sibling handled?
Core invariants
- Each bundle commitment is inserted once.
- Each child nullifier is spent once.
- Parent value equals the sum of its two child slots.
- Proof inputs bind the intended root, child, destination, amount, fee, chain, pool, context, and payload.
- Pool accounting and ETH balance cover allowed exits without double-counting fees.
- Encrypted recovery records are public; wallet unlock signatures, derived keys, bearer notes, and decrypted secrets stay out of RPC requests, analytics, logs, and public support channels.