Skip to content

Settlement

Settlement is the on-chain endpoint for Relay. It stores validator set headers (operators, keys, weights, thresholds) per network / subnetwork / epoch and verifies aggregated signatures (attestations) against those headers on the chains where apps live. Applications don’t talk to VotingPowerProvider or ValSetDriver directly; they call Settlement to check whether enough of the current validator set signed a given message.

Contract responsibilities

Settlement instances (one per Relay network per chain) are responsible for:

  • Committing headers

    Accept compressed validator set headers (for example, once per epoch) and store them keyed by (network, subnetwork, epoch).

  • Verifying attestations

    Given:

    • a message (or hash)
    • an epoch / header ID
    • an aggregate signature or zk proof

    Verifier checks:

    • the proof matches the message
    • the participating validators’ total voting power is at least the threshold from the header

    If both hold, it returns success so the calling app can continue.

Multi-chain

The same validator set can secure multiple chains. Each chain runs its own Settlement instance, and the Relay committer posts the same header to all replicas. Applications on different chains therefore verify against identical validator sets and thresholds for a given epoch, even though verification is performed locally on each chain.

Cost model (intuition)

Costs stay near-flat in validator set size. Header updates are small, infrequent writes because a compressed header is stored once per epoch. Verifying an attestation requires a single aggregate check: with the Simple verifier this is one BLS aggregate pairing plus summing the listed signers’ weights, while with the ZK verifier it is one zkSNARK verification where the signer set and weight check are already encoded in the proof. You pay per attestation, not per validator.

Failures

Verification fails (returns false / reverts) if:

  • the referenced epoch or header is not committed or does not match the network
  • the proof is invalid or does not match the message hash
  • the signing validators’ total voting power is below the threshold

In all of these cases, the application must not execute the gated action (no unlock, no finalize, no state update).