Skip to main content

​
StateSet Set L2

Set L2 is where commerce events become independently verifiable. The 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

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.
  2. Compliance — a private amount satisfied a policy (an AML threshold, an order cap) without the amount being revealed, via STARK proofs 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.
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.

​
The flow, end to end

An x402 payment rides the same rails: the payment intent is sequenced, batched, anchored, and its receipt carries the same class of inclusion proof.