Proof Validation Structure

SupraNova uses HyperNova, a trustless bridge protocol in which the destination-chain verifier trusts no off-chain actor and re-derives validity from the source chain’s own consensus signatures. This section explains the full proof pipeline in both directions: how Ethereum events are validated on Supra before wrapped assets are minted, and how Supra events are validated on Ethereum before assets are delivered.

Only the cryptographic material differs between the two legs, because Ethereum exposes a beacon-style Sync Committee while Supra exposes committee threshold certificates over Merkle accumulator roots.

Ethereum to Supra

This leg relies on Ethereum’s native secondary consensus layer to verify cross chain messages before minting wrapped assets (like supETH) on Supra.

Ethereum’s Consensus: Gasper and Sync Committee

Ethereum transitioned to Proof-of-Stake with the Beacon Chain and introduced Gasper which is a combination of:

• Casper FFG (Finality Gadget) – makes sure finalized checkpoints.
• LMD-GHOST (Fork Choice Rule) – Decides which chain fork is the head.

These two mechanisms define block finality and fork choice respectively in Ethereum’s Proof-of Stake consensus.

Each block is signed by:

• Participation of hundreds of thousands of validators.
• Sync Committee signatures for lightweight validation.

The Sync Committee

The Sync Committee is a subset of 512 validators randomly selected every ~27 hours (8192 slots).

• Each block includes an Aggregate public key, which contains signatures from the Sync Committee members who attested to the block.
• These aggregate signatures allow external systems (like HyperNova) to validate block headers without requiring full validator participation.
• The Sync Committee signatures are verified on-chain in the HyperNovaCore verifier contract on Supra.

Need of the Sync Committee for SupraNova?

• It allows fast and lightweight validation of Ethereum consensus.
• It enables trustless bridging without requiring the full Ethereum validator set.

Proof Pipeline (Ethereum to Supra)

When you bridge assets like ETH using SupraNova, the following proofs are generated by the Relayer:

These proofs are generated off-chain by relayers and submitted to the Supra Token bridge service contract for on-chain verification.

Importance of these proofs:

• They are required to prove the execution, and authenticity of bridge events without relying on external validators.

Sync Committee Signatures does the following:

• Verifies that a majority of the Sync Committee signed the block header.
• The Supra verifier contract aggregates public keys and validates the BLS signature.

Minimum Signature Threshold (Ethereum to Supra)

SupraNova’s configuration can require more than 90% of Sync Committee signatures for extra security. This minimum signature requirement applies to the Sync Committee’s aggregated BLS signature during proof validation.

Receipt Proof

• Verifies that the transaction execution resulted in a successful receipt.
• Checks that the expected event (LOGX) was emitted by the correct bridge contract.
• Check that the receipt contains the bridge event or not

Ancestry Proof

This always operates with two blocks. One is the target block (block with the event), other is the recent block (can be a finalised/safe/optimistic block) and link these blocks with ancestry proof. And then, verify the sync committee signature verification for the recent block

It handles two types of ancestry proofs:

Ancestry proofs use:

• Ethereum’s block_roots array for recent event blocks
• Ethereum’s historical_summaries for older event blocks

Fallback

The relayer generates an Ancestry proof using Ethereum’s state vectors, which is then verified by the HyperNovaCore contract on Supra.

Handling Edge Cases (Ethereum to Supra)

Supra to Ethereum

The Supra to Ethereum leg follows the same trust-minimised principle. Supra does not expose a beacon-style Sync Committee; instead, Supra’s MoveVM commits every executed transaction and every emitted event into Merkle accumulators, and the active Supra committee certifies each block’s accumulator roots with a single aggregated BLS12-381 threshold signature.

This section explains how a MessagePosted event emitted on Supra (for example, by the Token Bridge after burning supETH, or after locking $SUPRA) is validated on Ethereum before any asset is delivered.

Supra’s Consensus: Committee Threshold Certificates

Supra finality is produced by its Moonshot BFT consensus, in which validators are organised into clans and an authorised committee serves each epoch. For cross-chain verification, the important property is that the committee publishes aggregated threshold public keys rather than a list of individual validator keys.

• A committee is identified by a committee hash computed over its epoch info (chain id, epoch, start height, SMR timestamp), its threshold public keys, and the hash of its member set.
• Each committee exposes several threshold types (Validity, Quorum, Unanimous, BcftValidity, BcftQuorum, BcftFallbackViewChange, ClanMajority). The Ethereum verifier stores only the two it actually needs:
  • ClanMajority – certifies transaction inclusion in a Supra block.
  • BcftQuorum – authorises the next epoch’s committee.
• Because the threshold is already enforced inside the aggregated key produced by Supra L1 consensus, the Ethereum contract verifies one signature against one public key. It never enumerates validators, counts votes, or tracks stake weights on-chain, which is what keeps this direction cheap enough for EVM gas limits.

The Ethereum-side verifier therefore only ever needs two things to be current: the latest committee’s threshold public keys, and a certificate for the block that contains the event.

Proof Pipeline (Supra to Ethereum)

When you bridge an asset back to Ethereum, the Relayer assembles the following bundle and submits it to the Token Bridge service contract on Ethereum, which forwards it to HyperNovaCore:

What the Ethereum Verifier Checks, In Order

A single verifyMessagePostedOnSupra call enforces every one of the following, and reverts on the first failure:

1. Source chain is enabled for the chain id carried in the certificate’s epoch id.
2. Exact verification fee is paid in ETH: the configured base verification fee v multiplied by the number of events being verified. Over- and under-payment are both rejected.
3. Certificate binds to the proof: the transaction Merkle proof’s root must equal the certificate’s moveVmMerkleTreeRoot. A certificate for a different block cannot be paired with this proof.
4. Certifying committee is known and recent: the committee hash must already be registered on Ethereum, and its epoch must not lag the latest known committee by more than the configured epoch tolerance.
5. Event identity: keccak256(typeTag) must equal the sourceHypernovaEventIdentifierHash configured for that source chain, proving the event is HyperNovaCore’s own MessagePosted event and not some look-alike event from another Move module.
6. Message routing and authorship: the decoded event’s destination chain id must equal this chain’s block.chainid, and its caller must equal the expected caller supplied by the consumer, which the Token Bridge sets to the authorised Supra-side Token Bridge address.
7. Replay protection: the message id must not already be marked processed for the tuple (source chain id, consumer, message id).
8. Merkle inclusion: both accumulator proofs are verified (event → transaction → block).
9. Consensus signature: the certificate’s BLS threshold signature is verified, unless a certificate for that block height was already verified earlier (see caching below).

Event Emission Proof

The event leaf is keccak256(typeTag || data). It is verified against the event accumulator of a single transaction, where internal nodes are hashed as keccak256(prefix || left || right) with a fixed domain-separation seed prefix = keccak256("SUPRA::EventAccumulator").

This step answers only one question: was this exact event emitted by that transaction? It does not yet say anything about whether the transaction was accepted by the network.

Transaction Inclusion Proof

The transaction leaf is keccak256(keccak256("SUPRA::TransactionAccumulator") || transactionHash || eventRoot), verified against the block’s MoveVM transaction accumulator root using the same domain-separated internal-node hashing.

Two properties matter here:

• The leaf commits to the transaction hash and the event accumulator root together, so a valid event root cannot be re-attached to a different transaction.
• The two accumulators use distinct domain-separation seeds, so a node from one tree can never be replayed as a leaf or an internal node of the other.

Together with the previous step this proves that the event was emitted by a specific transaction, and that the transaction was executed in a specific Supra block.

Transactions Inclusion Certificate

The certificate is what makes the claimed block real rather than relayer-asserted. It carries the certifying committee hash, the certified data, and the aggregated signature. The signed digest is a Keccak-256 hash over:

moveVmMerkleTreeRoot || evmMerkleTreeRoot || blockHeight (little-endian u64) || chainId (1 byte) || epoch (little-endian u64)

The signature is checked against the certifying committee’s ClanMajority aggregated threshold public key using Ethereum’s EIP-2537 BLS12-381 pairing precompile, evaluating e(pk, H(m)) · e(-G1, sig) == 1, with the message hashed to G2 under the POP domain separation tag. Two defensive properties are worth calling out:

• The digest covers both the MoveVM and the EVM accumulator roots along with height and epoch, so a certificate cannot be re-cut to certify a different root or replayed under a different epoch or chain.
• An identity (point-at-infinity) signature is explicitly rejected, so no degenerate signature can satisfy the pairing equation even if a zero public key were ever stored by an upstream defect.

Certificate Caching and Batch Verification

BLS pairing verification is the expensive part of this direction, so HyperNovaCore on Ethereum verifies it as rarely as is safely possible:

• On the first successful verification for a block height, the certified MoveVM accumulator root is cached against that height.
• Later messages from the same Supra block can then be verified through the “without certificate” entry points, which skip the signature check and validate the proof against the cached root instead. If no certificate has been verified for that height yet, those calls revert.
• If a certificate is later submitted for a height that is already cached but carries a different root, verification fails outright. A mismatch can only mean the certificate data was altered after the earlier, already-verified submission.
• Batch entry points verify many events from one block with at most a single BLS verification, while still verifying each event’s own Merkle proofs and replay state. Batches are atomic: if any message in the batch fails verification or was already processed, the whole transaction reverts.

Minimum Signature Threshold (Supra to Ethereum)

Where the Ethereum to Supra leg can require more than 90% of Sync Committee signatures, this direction inherits its threshold from Supra L1 consensus itself. The bridge contract does not choose a percentage; it verifies a signature that Supra’s consensus only produces once the corresponding threshold has been met:

• ClanMajority for transaction inclusion certificates.
• BcftQuorum for committee authorisation certificates, the Byzantine-fault-tolerant quorum of the active committee.

In addition, the epoch tolerance setting bounds how old a certifying committee may be. Certificates signed by a committee more than the configured number of epochs behind the latest registered committee are rejected, which prevents indefinite use of a long-retired committee’s keys.

From Verified Event to Delivered Funds

HyperNovaCore returns only a verified event: caller, message id, destination chain id, and an opaque message payload. Interpreting that payload is the service layer’s responsibility, and the Token Bridge on Ethereum applies its own validation before moving value:

• The payload is RLP-decoded into exactly nine fields: sender address, source token address, source chain id, payload, receive amount, service fee, relayer reward, receiver address, and an unwrap flag. A list of any other length is rejected rather than silently truncated.
• Supra addresses must decode to exactly 32 bytes, and the amount fields must fit in u64, so an encoder change on either side fails loudly instead of resolving to a different token or amount.
• The source token must be registered and enabled for that chain, amounts are denormalised using the token’s cached decimal rate, and only then is the destination asset delivered to the receiver, either released from the vault or issued by the bridge, with the relayer reward paid out of the same message.

Handling Edge Cases (Supra to Ethereum)