Secure Attestations

Secure attestations are stake-backed signatures over a message hash that contracts can verify against the active validator set header.

Concretely:

• The validator set for epoch e is fixed by a committed header (operators, keys, weights, threshold).
• Operators in that set sign a message hash.
• An aggregator combines these signatures into an aggregate proof.
• A Settlement contract on the destination chain verifies the proof against the header for epoch e.

Message Contents (typical)

The protocol doesn’t hardcode a single message struct, but in practice you want something like:

• networkId – Relay network identifier
• subnetworkId – optional, for partitioned logic
• epoch or valsetId – which validator set header must be used
• payloadType – enum or tag (bridge, checkpoint, oracle, etc.)
• payloadHash – hash of the actual data your app cares about
• dstChainId – EVM chain where this will be verified
• dstApp or dstContract – target contract / app identifier
• expiry – timestamp or block after which the attestation is invalid
• nonce – monotonically increasing per channel / app

You encode this structure, compute messageHash = keccak256(encodedMessage), and only messageHash is signed by operators.

Aggregation and Verification

The flow is:

1. Build the message

   Middleware or the app constructs the message struct, fills epoch, dstChainId, dstApp, nonce, expiry, etc., and computes messageHash.

2. Operators sign

   Each operator in the current validator set for epoch signs messageHash with its registered key (BLS or ECDSA, depending on your Relay config).

3. Aggregate off-chain

   An aggregator collects signatures and:

   • for the Simple path:
     • aggregates BLS signatures into sigmaAgg
     • builds a participant bitmap / list
   • for the ZK path:
     • uses the individual signatures and weights to generate a zk proof that “signers’ voting power ≥ threshold for header H and messageHash M”
4. Submit to Settlement

   On the destination chain, the aggregator (or any relayer) calls something like:

   • settlement.verifyAndConsume(message, epoch, sigmaAgg, participants) for Simple, or
   • settlement.verifyAndConsume(message, epoch, zkProof) for ZK.
5. On-chain check

   Settlement:

   • loads the validator set header for epoch
   • reconstructs keys and weights from that header
   • runs either:
     • SimpleVerifier: check BLS aggregate against the participants and ensure their summed voting power ≥ threshold
     • ZKVerifier: check the proof that encodes both signature validity and power ≥ threshold

   If verification passes, your app logic (bridge, rollup, oracle, etc.) is allowed to execute.

Safety Properties

Secure attestations are tied down in a few specific ways:

• Bound to a validator set The message includes epoch (or a valset ID). Settlement only verifies against the header stored for that epoch. An attestation for epoch e cannot be validated against the header for epoch e+1.

• Bound to destination dstChainId and dstApp are part of the signed payload. The same hash cannot be replayed on a different chain or different contract because the signature is over the full encoded message.

• Replay protection Your app (or Settlement integration) tracks:

  • nonce: reject messages with a nonce ≤ lastSeenNonce for that channel / app
  • expiry: reject messages whose expiry is in the past
• Slashable misbehavior

  If operators sign:

  • two different payloads for the same (networkId, subnetworkId, epoch, nonce)
  • or obviously invalid content (e.g. violates your protocol’s invariants),

  that evidence can be fed into your Network’s middleware, which then submits a slashing request to the relevant vaults in Symbiotic. The economic backing for those keys is what makes the attestation “secure”.

So in short: a secure attestation is a message bound to a specific epoch, network, and destination, proven on-chain to have signatures from enough stake-weighted operators in that epoch’s validator set.