A Nullark recovery note can unlock its private balance. Anyone who gets it may be able to withdraw. Keep it offline, never paste it into another site, and never send it to support.
Nullark has two recovery paths. Wallet recovery derives a local key from exact verified signature bytes and decrypts public onchain records. A bearer recovery note carries an independent recovery root. Either the unlock signature or bearer note can become spend authority for matching records.

​
Threat scenarios

​
Public ciphertext boundary

The pool emits a fixed-size encrypted recovery payload with each supported deposit. Everyone can copy that ciphertext and correlate it with the public deposit. Decryption still requires the matching wallet-derived key or bearer recovery root. The browser binds authenticated decryption to chain, pool, runtime, template-set hash, and bundle commitment. A wrong source, context, key, payload hash, or reconstructed commitment fails closed.

​
Optional bearer-backup storage

If you export a bearer backup, keep at least one offline encrypted copy and use this small, deliberate backup set:
  1. Wait for Deposit successful and Confirmed, then open Save recovery note.
  2. Store the exported copy outside the active browser profile.
  3. Record a human label for purpose and network beside the file, never by editing serialized bytes.
  4. Prevent cloud photo, clipboard, source-control, telemetry, and chat systems from ingesting it.
  5. Check that you can read the stored copy without publishing it or importing it into another site.
Multiple copies improve availability but increase disclosure surface. Keep the minimum number needed for recovery, with independent access controls.

​
Import validation

The client must stop before balance recovery if any of these checks fail:
  • Prefix, Base58 body, checksum, byte length, or strict JSON schema
  • Format version supported by the selected importer
  • Chain ID and pool identity
  • Commitment recomputed from secret material
  • Wallet unlock requirement when the recovery format uses one
  • Duplicate, malformed, spent, or unsupported note state
Parsing validates the file format. Balance recovery also needs matching pool state and a valid Merkle path.

​
Recovery availability

Wallet recovery remains available only while the wallet can return the same canonical signature bytes for the bound request. EIP-712 defines the signed message, while wallet implementations control signature production. A different valid signature can derive a different key. The bearer note preserves recovery when wallet software, account access, or signature reproducibility changes. If no bearer copy exists, loss of the usable wallet-derived path permanently loses the secret.

​
Suspected disclosure

  1. Stop copying, pasting, uploading, or testing the exposed value.
  2. From a trusted environment, verify its chain, pool, commitment, and unspent state.
  3. If spendable, prepare a withdrawal to a new self-custody destination.
  4. Recheck recipient, gross amount, fee, proof-bound context, and submission route.
  5. Confirm the expected pool event and recorded nullifier.
  6. Preserve only public incident evidence; remove unnecessary secret copies.
There is no revocation list for an exposed unspent note. Spending the note records its nullifier and blocks later reuse.