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

# StateSet Set L2

> The anchoring layer for verifiable commerce — what goes on-chain, what stays off, and what a third party can check.

Set L2 is where commerce events become **independently verifiable**. The
[sequencer](/stateset-sequencer/stateset-sequencer) orders and batches events; Set L2 anchors each
batch's commitment on-chain so that any party — a customer, an auditor, a counterparty agent — can
verify an event happened, without trusting StateSet's word for it.

## What goes on-chain, and what doesn't

| On-chain | Off-chain |
| - | - |
| Batch **Merkle root** | The events themselves |
| Proof hashes and policy hashes | Amounts, customers, order contents |
| Batch metadata (sequence range, timestamp) | STARK proof bodies |

The chain stores commitments, not data. Verification is the act of connecting an off-chain event to
an on-chain root through a Merkle inclusion proof.

## Components

* **SetRegistry** — the contract holding batch commitments and proof metadata
* **Anchor service** — submits commitments and proofs; runs alongside the sequencer
* **Verifier clients** — recompute proofs against the registry, independently of StateSet

## What a third party can verify

1. **Inclusion** — this signed event is in that anchored batch. The leaf and node hashing is
   domain-separated (`VES_LEAF_V1` / `VES_NODE_V1`); the exact preimages and a worked example are in
   [Verify an event](/set/stateset-set-l2-verification-example).
2. **Compliance** — a private amount satisfied a policy (an AML threshold, an order cap) without the
   amount being revealed, via [STARK proofs](/set/stateset-stark) whose hashes are anchored next to
   the batch.
3. **State transitions** — batch N follows batch N−1; a gap or fork is detectable from the registry
   alone.

<Tip>
  The reason to care is the asymmetry: producing these guarantees requires running the sequencer, but
  **checking** them requires only the proof bytes and public chain state. A counterparty can verify
  your commerce history without an account, an API key, or any trust in your infrastructure.
</Tip>

## The flow, end to end

```
agent signs event ─▶ sequencer assigns sequence #, batches
                          │
                          ├─ Merkle root computed (domain-separated)
                          ▼
                    anchor service ─▶ SetRegistry (on-chain commitment)
                          │
                          ▼
        anyone: fetch receipt ─▶ verify inclusion against the root
```

An [x402 payment](/stateset-x402-walkthrough) rides the same rails: the payment intent is sequenced,
batched, anchored, and its receipt carries the same class of inclusion proof.

## Related

* [Set L2 architecture](/set/stateset-set-l2-architecture) — the registry and anchor service in detail
* [Verify an event](/set/stateset-set-l2-verification-example) — the exact hashing, with code
* [Compliance proofs](/set/stateset-set-l2-compliance-proof) — verifying an anchored STARK proof
* [Sequencer](/stateset-sequencer-architecture) — how batches are built


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