Each deposit publishes a fixed-size encrypted bundle record through CommitmentInserted. The Transfer Console derives its decryption key from a verified browser-wallet signature. The SDK exposes the strict envelope restore boundary; application code owns wallet authorization and log discovery.
The onchain envelope is public ciphertext. Wallet unlock signatures, derived recovery roots, bearer recovery notes, decrypted bundle secrets, and proof witnesses are spend-sensitive. Keep them out of logs, URLs, analytics, support tickets, tests, and source control.

​
Onchain discovery record

Reject malformed logs, wrong pools, non-field commitments, nonpositive amounts, unsafe leaf indexes, and wrong payload lengths before decryption.

​
Wallet key derivation

The browser requests EIP-712 typed data whose domain binds the chain ID and verifying pool. Its message binds wallet, pool, recovery and encryption versions, purpose, issuance scope, and warning text. Required order:
  1. Accept only a full or compact secp256k1 signature with canonical scalars.
  2. Normalize its encoding and recover the typed-data signer.
  3. Require the recovered signer to equal the requested EOA wallet.
  4. Feed the exact canonical signature bytes into HKDF-SHA-256.
  5. Bind the recovery root to application ID, chain ID, and lowercased pool.
  6. Derive a bundle-specific key from the recovery epoch and bundle commitment.
Canonical encoding removes equivalent wire encodings of one signature. Two different valid signatures remain different after canonicalization. Wallet-only durability therefore requires the wallet to reproduce the same canonical signature bytes for the same request.

​
Authenticated envelope

AES-GCM associated data binds:
  • Chain ID and lowercased pool
  • Runtime ID and template-set hash
  • Bundle commitment
  • Recovery associated-data schema and version
Restore also binds the recomputed payload hash and externally anchored bundle commitment. After decryption, reconstruct the canonical bundle and its child commitments. Any mismatch fails closed.

​
Restore through the SDK

The restore path checks the envelope schema, active runtime, pool, template set, payload hash, authenticated-encryption context, and externally anchored bundle commitment. It then recomputes the bundle and child commitments before returning spendable data.

​
Complete recovery order

  1. Scan CommitmentInserted only from the configured pool and deployment block.
  2. Parse the event and construct the exact recovery record without field coercion.
  3. Derive the verified wallet recovery key, or explicitly import a bearer recovery root.
  4. Verify payload shape, byte length, and hash.
  5. Decrypt with the exact authenticated context.
  6. Recompute and match the externally anchored bundle commitment.
  7. Resolve onchain membership and current accepted root.
  8. Check each child nullifier; expose only positive, unspent children.
  9. Leave note selection empty until the user chooses one.

​
Bearer fallback

The nullark1_... recovery note packages the recovery root with chain, pool, runtime, template, amount, commitment, deposit-context, payload-hash, and ciphertext bindings. It is independent spend authority and is a recommended optional export. Wallet-derived recovery is the required deposit path; exporting a bearer note reduces the availability risk created by EIP-1193 wallets having no universal deterministic-signature guarantee. Do not write a looser compatibility parser. If a field, hash, runtime, key, or commitment differs, restoration fails and no chain action should follow. Recovery security and operational boundaries live on the recovery-note safety page. The formal report covers withdrawal fund safety separately.