Proof Validation Structure in HyperNova
Last updated
Last updated
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 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 .
Each block is signed by:
Participation of hundreds of thousands of validators.
Sync Committee signatures for lightweight validation.
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.
It allows fast and lightweight validation of Ethereum consensus.
It enables trustless bridging without requiring the full Ethereum validator set.
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.
They are required to prove the execution, and authenticity of bridge events without relying on external validators.
Verifies that a majority of the Sync Committee signed the block header.
The Supra verifier contract aggregates public keys and validates the BLS signature.
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.
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
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)
Ethereum’s block_roots array for recent event blocks
Ethereum’s historical_summaries for older event blocks
The relayer generates an Ancestry proof using Ethereum’s state vectors, which is then verified by the HyperNovaCore contract on Supra.
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