A safe deposit flow has three phases: derive the verified wallet recovery key and stage matching encrypted recovery material, submit one transaction with the encrypted record, then reconcile the expected commitment. A raw contract call can put ETH in the pool without leaving the user usable recovery material.

​
Prepare

Choose one runtime and one supported amount before you create recovery material.
The prepared plan includes:
  • Chain ID and verifying pool
  • Supported ETH amount
  • Fresh nonzero commitment
  • Fixed 144-byte encrypted recovery payload and its hash
  • EIP-712 signer verification plus chain-and-pool-bound key derivation
  • Deposit selector and proof context
  • Exact deposit public-input order
  • Matching encoded recovery entry held in client memory for optional post-confirmation export
Create and verify the encrypted record and encoded recovery entry before asking the wallet to send ETH. Copy, download, and acknowledgement are optional user actions after confirmation; they are not submission gates. If preparation fails, discard only the unfinished plan. Keep any older valid recovery record.

​
Submit

The wallet transaction uses the runtime pool, the prepared ETH value, and the matching calldata. Review them together: Do not rebuild the commitment, encrypted payload, or staged recovery material after wallet review. Any change creates a new deposit plan and needs new recovery material.

​
Reconcile

The deposit finishes after its receipt succeeds. Then:
  1. Confirm receipt target is the configured pool.
  2. Match CommitmentInserted to the prepared commitment, amount, and leaf index.
  3. Match the event’s encrypted payload to the wallet-encrypted recovery envelope prepared before submission.
  4. Refresh membership from the configured deployment block.
  5. Mark recovery record live only after commitment confirmation.
If the receipt succeeds but the expected event is missing, stop. Keep the hash and prepared recovery material while you investigate.

​
Uncertain submission

A wallet rejection is final only if no transaction hash was accepted. A network error after signing can leave the result unknown. Do not create another note and resend the same value until you have checked the original commitment. Treat every repeated deposit as an independent preparation and transaction outcome. Never resend an uncertain deposit until its original commitment has been reconciled.

​
Integration tests

  • Reject unsupported amount and zero commitment
  • Reject chain, pool, selector, public-input, and encrypted-payload mismatches
  • Prove the wallet-derived recovery record and encoded fallback map to the prepared commitment
  • Treat receipt without commitment event as incomplete
  • Reconcile repeated deposits independently without resubmission
  • Pause on unknown wallet or RPC outcome
Use the TypeScript SDK for the working preparation boundary. Read Runtime selection, Recovery data, and Contract events before implementing transport.