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

# Nullark protocol overview

See how Nullark moves ETH from one public bundle deposit through a private child proof to public settlement.

Nullark keeps ETH and settlement state in a public contract. You keep the recovery material for each deposited bundle. The client restores a child, builds its witness, and proves the withdrawal locally.

## Protocol map

```mermaid
flowchart TB
  subgraph Client["Client — secrets stay here"]
    R["Recovery envelope"] --> B["Bundle with child notes"]
    B --> C["Select one unspent child"]
    C --> P["Local Groth16 proof"]
  end

  subgraph Chain["MegaETH — public state"]
    D["ETH + bundle commitment"] --> T["Pool tree and accepted roots"]
    V{"Proof valid and nullifier unused?"}
    V -->|yes| S["Record nullifier, accrue fee, send net ETH"]
    V -->|no| X["Revert with no state change"]
  end

  T -->|membership data| C
  P -->|proof and nine public inputs| V
```

## Three records, three jobs

| Record | Source of truth | Question it answers |
| --- | --- | --- |
| Pool state | Contract | Was the bundle inserted? Is the root accepted? Is this child spent? |
| Recovery envelope | User-controlled storage | Can the bundle and child secrets be restored? |
| Runtime | SDK package | Which chain, pool, verifier, proving files, selectors, and input order belong together? |

Each layer has one job. The recovery envelope restores secrets, the pool records deposits and spends, events reconstruct public state, and the runtime keeps every piece pointed at the same deployment.

## Value lifecycle

1. The client prepares a template, child secrets, encrypted recovery envelope, and deposit proof. Save the recovery envelope before submission.
2. The wallet deposits the template's parent amount with one bundle commitment.
3. The pool inserts that commitment and accepts a new root.
4. The client restores the bundle and selects one unspent child.
5. The client proves child ownership and bundle membership without publishing the witness.
6. The pool records that child's nullifier, accrues the fee, and sends net ETH.
7. Any sibling remains available under the original bundle commitment.

## Read by question

- [What identifies a deposited bundle?](/concepts/commitments-and-roots.md)
- [What prevents a second spend?](/concepts/nullifiers.md)
- [Which amounts can a template use?](/concepts/fixed-denominations.md)
- [How are fees and the remaining sibling handled?](/concepts/fees-and-private-change.md)

## Core invariants

- Each bundle commitment is inserted once.
- Each child nullifier is spent once.
- Parent value equals the sum of its two child slots.
- Proof inputs bind the intended root, child, destination, amount, fee, chain, pool, context, and payload.
- Pool accounting and ETH balance cover allowed exits without double-counting fees.
- Recovery material stays out of RPC requests, analytics, logs, and public support channels.

These are design rules, not a blanket security claim. Read [What a Groth16 proof proves](/security/proof-system.md) and [Security status](/security/status.md) for the current scope.