Protect recovery authority

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.

A recovery export is closer to a private key than a receipt. Anyone holding the same material can build the same witness.

Threat scenarios

Threat scenario	Consequence	Response
A site, extension, or support message requests the note	The requester may reconstruct and spend it	Close the surface; use only the canonical app and bound network
Clipboard history retains a copied note	Another app or later user may recover the secret	Clear unsafe history and prefer an offline file transfer
Cloud sync uploads the backup	Account compromise can become balance compromise	Move to offline encrypted storage and review existing copies
A screenshot or screen share captures the value	Image backups, chat, or recording systems may retain it	Stop sharing, identify every copy, then move unspent value
The export is edited, wrapped, or truncated	Checksum, schema, commitment, or runtime validation fails	Return to an untouched backup; never repair fields by guessing
Browser storage is cleared before export	The locally held note may become unrecoverable	Export and verify recovery material before relying on browser state
The same backup is used on the wrong network	Import must fail or bind to no spendable state	Verify chain ID, pool, format, and commitment before balance lookup

Storage pattern

Use a small, deliberate backup set:

Export immediately after the app presents the recovery step.
Keep at least one offline encrypted copy outside the active browser profile.
Record a human label for purpose and network beside the file, never by editing serialized bytes.
Prevent cloud photo, clipboard, source-control, telemetry, and chat systems from ingesting it.
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.

Lost but not disclosed

Losing every valid copy and browser record permanently loses the secret. Do not delete a working local record until its recovery authority is independently preserved.

Suspected disclosure

Stop copying, pasting, uploading, or testing the exposed value.
From a trusted environment, verify its chain, pool, commitment, and unspent state.
If spendable, prepare a withdrawal to a new self-custody destination.
Recheck recipient, gross amount, fee, proof-bound context, and submission route.
Confirm the expected pool event and recorded nullifier.
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.

Verification

Reporting

Protect recovery authority

Threat scenarios

Storage pattern

Import validation

Lost but not disclosed

Suspected disclosure

​Threat scenarios

​Storage pattern

​Import validation

​Lost but not disclosed

​Suspected disclosure

Threat scenarios

Storage pattern

Import validation

Lost but not disclosed

Suspected disclosure