> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nullark.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Protect recovery authority

Store Nullark recovery exports as spend authority, validate every import, and know what to do after loss or suspected disclosure.

> **Warning:**
> 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:

1. Export immediately after the app presents the recovery step.
2. Keep at least one offline encrypted 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.

> **Info:**
> 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

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.