Protocol map
Three records, three jobs
Each layer has one job. The recovery envelope restores secrets, the pool records deposits and spends, events reconstruct public state, and the runtime keeps every piece pointed at the same deployment.
Value lifecycle
- The client prepares a template, child secrets, encrypted recovery envelope, and deposit proof. Save the recovery envelope before submission.
- The wallet deposits the template’s parent amount with one bundle commitment.
- The pool inserts that commitment and accepts a new root.
- The client restores the bundle and selects one unspent child.
- The client proves child ownership and bundle 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.
- Recovery material stays out of RPC requests, analytics, logs, and public support channels.