Proof metadata
Each batch commitment can carry proof metadata:Field names appear in two conventions — camelCase on the on-chain contract surface, snake_case in
the sequencer’s own schema (
ves_compliance_proofs). They’re the same values; use whichever your
side of the boundary exposes.proof_type (e.g. stark.compliance.v1), policy_id
(e.g. aml.threshold), policy_params (e.g. {"threshold": 10000}), public_inputs in
canonical JCS form, witness_commitment as a Rescue hash of the private witness, and the proof
bytes themselves at roughly 100–200KB.
Verification flow
1. Fetch proof metadata from Set L2. The on-chain record gives youproofHash, policyHash,
and allCompliant.
2. Retrieve the proof artifact from your prover storage. Proofs are large, so they’re
referenced on-chain by hash rather than stored there.
3. Verify the proof locally against the policy inputs, using the STARK verifier.
4. Compare hashes. Hash the artifact you just verified and check it equals the on-chain
proofHash. Separately, check policyHash matches the policy you care about.
What allCompliant does and doesn’t tell you
allCompliant is a batch-level flag: every event in the batch satisfied the policy. A false
value tells you something in the batch didn’t — it doesn’t tell you which event. For per-event
detail you need the individual proof records, keyed by event_id.
When to use them
Next steps
Set L2 verification
Inclusion proofs — proving an event was anchored at all.
Set L2 architecture
The full proof record and how batches are committed.
Verified decisions
The same principle applied to authorising an action.
Set L2
The settlement layer these proofs anchor to.