Proof Validation Structure in HyperNova

SupraNova uses HyperNova, a trustless bridge protocol that relies on Ethereum’s native secondary consensus layer to verify cross chain messages. This section explains the full proof pipeline, including how bridge events are validated securely and cryptographically before minting wETH 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.

Since, Sync committee is not signing every block, ancestry proofs are used to solve this.

---

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 in SupraNova

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

Proof Type	Purpose
Sync Committee Signature	Verifies the sync committee attestation of the block
Receipt Proof	Verifies that the transaction successfully executed
Ancestry Proof	Links the old block which have bridge event to the recent block with enough sync threshold

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

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:

Proof Type	Used When
Block Roots Ancestry Proof	If the Targent block is within 8192 recent slots (~27 hours)
Historical Summaries Proof	If the block is older than 8192 slots(archived in historical_summaries vector)

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

Scenario	Handling logic (Component + Action)
Block has < required Sync Committee signatures	We always generate Ancestry Proof
Sync Committee rotates	Committee Updater refreshes keys on Supra
Proof is invalid or tampered	Supra on-chain verifier rejects the bridge request