> ## 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.

# Integrate deposits

Build a Nullark deposit in three steps: prepare the bundle and recovery envelope, submit once, then match the inserted commitment.

A safe deposit flow has three phases: prepare the bundle and recovery envelope, submit one transaction, 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.

```text
runtime
  + fixed amount
  + fresh bundle and child secrets
  + encrypted recovery payload
  = commitment and deposit witness
```

The prepared plan includes:

- Chain ID and verifying pool
- Supported ETH amount
- Fresh nonzero commitment
- Fixed 144-byte encrypted recovery payload and its hash
- Deposit selector and proof context
- Exact deposit public-input order
- Matching recovery export

Create the recovery export before asking the wallet to send ETH. 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:

| Field | Required source |
| --- | --- |
| `to` | Runtime pool address |
| `value` | Prepared fixed denomination |
| `data` | Proof, six ordered public inputs, encrypted recovery payload |
| Chain | Runtime chain ID confirmed by wallet provider |

Do not rebuild the commitment or encrypted payload after wallet review. Any change creates a new deposit plan and needs a new recovery export.

## 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 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.

For queued deposits, use the existing [multi-deposit queue](/use/multi-deposit.md) state machine. Each item owns its own preparation and transaction outcome.

## Integration tests

- Reject unsupported amount and zero commitment
- Reject chain, pool, selector, public-input, and encrypted-payload mismatches
- Prove recovery export maps to prepared commitment
- Treat receipt without commitment event as incomplete
- Resume confirmed queue items without resubmission
- Pause on unknown wallet or RPC outcome

Use the [TypeScript SDK](/developers/sdk.md) for the working preparation boundary. Read [Runtime selection](/developers/runtime-selection.md), [Recovery data](/developers/recovery-format.md), and [Contract events](/reference/events.md) before implementing transport.