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

# Run a watcher

> What a Sundial L2 watcher does: read committed blocks, check them against the ledger rules, and prove fraud on L1 for a share of the operator's bond.

A watcher reads committed L2 blocks and checks them. If a block breaks a ledger rule, the watcher proves it on L1, the block is removed, and the watcher receives a share of the operator's forfeited bond. Anyone can be a watcher. No registration or bond is required.

> [!NOTE]
>
> This page describes the watcher role as the protocol specifies it. The fraud proof validators and the SDK are in the [monorepo](https://github.com/sundial-protocol/sundial-monorepo).

## What a watcher does

**1. Follow the state queue**

Read the state queue on L1 for newly committed headers. The node exposes it at [`GET /stateQueue`](https://docs.sundialprotocol.com/api/blocks).

**2. Retrieve each block**

Fetch the full block by its header hash from the data availability layer, and check that it matches the header on L1.

**3. Verify it**

Rebuild the block's four tries and compare their roots with the header. Then replay the block from the previous UTXO set and evaluate the ledger rules. See [Data availability](https://docs.sundialprotocol.com/l2/data-availability.md#how-a-watcher-retrieves-a-block).

**4. Prove fraud**

If you find a violation, start the matching computation thread, advance it through its steps, and use the resulting fraud proof token to remove the block. See [Fraud proofs and ledger rules](https://docs.sundialprotocol.com/l2/fraud-proofs.md).

## What you earn

A forfeited bond is split. `fraud_prover_reward` goes to the watcher that proved the fraud, and the rest goes to the settlement L1's treasury. The design range for the reward is 30% to 50% of the bond.

## What it costs

* **L1 fees and deposits.** A proof is several L1 transactions. A double-spend proof takes six. You lock some ADA in the thread while it runs, and get it back.
* **Time.** The proof must complete before the block's maturity period ends. Start early.
* **Compute and storage.** You need the latest confirmed UTXO set and the data of every block still in the queue.

Only the watcher that starts a thread can advance or cancel it. Cancelling returns the ADA locked in it.

## Tools

| Tool | Use |
| - | - |
| [Midgard SDK](https://docs.sundialprotocol.com/sdk/midgard-sdk.md#submitting-a-fraud-proof) | Builds the fraud proof transactions |
| [`midgard-ts`](https://docs.sundialprotocol.com/sdk/midgard-ts) | The block codec and the same rule checks the node runs |
| [Node API](https://docs.sundialprotocol.com/api/overview.md) | Reads blocks, transactions and the state queue |

## Archive nodes

An archive node stores the data of confirmed blocks and serves historical queries. It is a separate role from watching. Because the confirmed state pins the whole history by a chain of header hashes, archived data is either verifiably correct or not. See [Data availability](https://docs.sundialprotocol.com/l2/data-availability.md#archive-nodes).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.