Skip to Content
SupraNova (Bridge)Workflow of HyperNova Bridging within SupraNova

Workflow of Hypernova Bridging within SupraNova

SupraNova uses the HyperNova trustless bridging protocol in both directions. The components are the same in each case; what changes is which chain emits the event and which chain runs the verifier.

At a high level, the two flows look like this:

Ethereum Wallet → Lock ETH → Emit Event → Relayer → Proof Bundle → Supra Verifier → Mint supETH

Supra Wallet → Burn supETH or Lock $SUPRA → Emit Event → Relayer → Proof Bundle → Ethereum Verifier → Deliver asset


Ethereum to Supra

The system consists of several coordinated components:

Ethereum Source Chain

  • Bridge contracts in the Service layer like Token Bridging Component typically locks the asset, and the contracts in the message passing layer emits events containing the user bridge request details.
  • The Ethereum-side bridge component resides in the message layer, it emits verifiable events that capture user intent, but it does not execute any asset-related logic on its own.

Off-Chain Relayer

  • A permissionless relayer listens for bridge events.

  • It constructs cryptographic proofs:

    a. Receipt Proof (that the transaction succeeded)

    b. Sync Committee Signature(that the block was finalized)

    c. Ancestry Proof

Supra Destination Chain

  • The message is consumed by a service-layer smart contract (like the Token Bridge) that handles typically minting of wrapped tokens.

  • The relayer submits the proof bundle along with the bridge request event to the Service Contract (Token Bridge contract) on Supra.

  • The Token Bridge contract does not perform validation itself. Instead, it submits the request event and the proof bundle to the HyperNovaCore Verifier on Supra. If the proof is verified successfully, the control is returned to the service contract that proceeds with minting of the wrapped token.

The HyperNovaCore checks:

  • That the block is correctly signed (using Ethereum’s Sync Committee)
  • That the event originates from the expected bridge contract
  • That the transaction receipt is valid

Upon successful verification, the wrapped asset (like supETH) is minted for the user.

Below you can see the bridge life cycle:

HyperNova Bridging Workflow diagram

Consensus Validation in Ethereum to Supra HyperNova

SupraNova does not rely on validator attestations. Instead of using third-party validators, HyperNova validates Ethereum blocks using consensus-level cryptographic signatures.

This validation logic powers the message-passing core of SupraNova, handled by HyperNova Core.

It uses Ethereum’s native finality mechanisms:

  • Gasper Consensus: Combines Casper the Friendly Finality Gadget with LMD-GHOST fork choice rule.
  • Sync Committee Attestations: A lightweight subset of validators (512 randomly selected nodes) sign block headers every ~27 hours (8192 slots).

The bridge process checks that:

  • The block after the block containing the bridge event has sufficient Sync Committee signatures.
  • It uses an Ancestry Proof to connect to a recent block that does.

This makes sure that SupraNova bridges only from valid Ethereum blocks.

Summary of Components (Ethereum to Supra)

ComponentRole
HyperNovaCore (Ethereum)Emit event
Token Bridge Contract (Ethereum)Lock ETH
RelayerGenerate proofs, submit to Supra
HyperNovaCore Verifier (Supra)Validate proofs on-chain
Token Bridge Contract (Supra)Mint supETH to user
Committee UpdaterPublishes new Sync Committee public keys to HypernovaCore Verifier on Supra every ~27 hours (256 epoch).

Supra to Ethereum

The system consists of the following coordinated components:

Supra Source Chain

  • The Token Bridge service contract on Supra takes custody of the asset and the message passing layer emits an event containing the bridge-out request details: asset type, amount, and recipient Ethereum address. For an asset that originated on Ethereum (such as supETH or supUSDC) it burns the wrapped balance; for a Supra-native asset such as $SUPRA it locks the balance in the Supra-side vault.
  • Both actions are binding. A burn permanently reduces the circulating supply of the wrapped asset on Supra, which is the condition that allows the matching collateral to be released on Ethereum. A lock keeps the Supra-native asset in the vault until the Ethereum-side representation is sent back.
  • As on the Ethereum side in forward bridging, the Supra-side component emits a verifiable event capturing user intent; it does not deliver anything on the destination chain itself.

Off-Chain Relayer

  • A permissionless relayer listens for bridge-out events on Supra.

  • It constructs the proof bundle:

    a. Move Event – the raw MessagePosted event, its type tag and BCS-encoded payload

    b. Event Merkle Proof – that the event was emitted by the claimed transaction

    c. Transaction Merkle Proof – that the transaction was executed in the claimed Supra block

    d. Transactions Inclusion Certificate – the committee’s aggregated BLS12-381 threshold signature over that block’s accumulator roots

Ethereum Destination Chain

  • The message is consumed by the Token Bridge service contract on Ethereum, which delivers the destination asset to the recipient.
  • The relayer submits the proof bundle along with the bridge-out event to the Token Bridge contract on Ethereum.
  • The Token Bridge contract does not perform validation itself. Instead, it submits the event and the proof bundle to the HyperNovaCore Verifier on Ethereum. If the proof is verified successfully, control is returned to the service contract, which proceeds with delivering the asset.

The HyperNovaCore verifier on Ethereum checks:

  • That the certificate carries a valid committee threshold signature over the block’s accumulator roots
  • That the event originates from the expected Token Bridge contract on Supra
  • That the event and transaction Merkle proofs anchor the bridge-out event to that certified block

Upon successful verification, the destination asset is delivered to the user’s recipient address: released from the Ethereum vault when the asset originated on Ethereum, or issued by the bridge when the Ethereum-side token is a bridge-issued representation of a Supra-native asset.

Consensus Validation in Supra to Ethereum HyperNova

Reverse bridging applies the same principle in the opposite direction: the Ethereum-side verifier does not trust the relayer, and instead validates Supra blocks using Supra’s own consensus-level cryptographic signatures.

Supra finality is produced by its Byzantine Fault Tolerant (BFT) validator committee:

Committee Threshold Certificates: Supra’s active committee certifies each block’s Merkle accumulator roots with a single aggregated BLS12-381 threshold signature. Because the threshold is enforced inside the aggregated key, the Ethereum contract verifies one signature against one public key and never enumerates validators or tracks stake weights on-chain.
Direct Block Anchoring: Unlike Ethereum, where a small rotating Sync Committee signs only a subset of blocks, the certificate names the exact block height it certifies, so the block carrying the bridge-out event is anchored directly.

The process checks that:

  • The certificate carries a valid ClanMajority threshold signature from a committee registered on Ethereum.
  • The event and transaction Merkle proofs chain the bridge-out event up to the accumulator root that certificate covers.

This makes sure that SupraNova delivers assets only against certified Supra blocks. See Proof Validation Structure for the full pipeline.

Summary of Components (Supra to Ethereum)

ComponentRole
Token Bridge Contract (Supra)Burn the wrapped FA, or lock the Supra-native asset
HyperNovaCore (Supra)Emit bridge-out event
RelayerGenerate proofs, submit to Ethereum
HyperNovaCore Verifier (Ethereum)Validate Supra proofs on-chain
Token Bridge Contract (Ethereum)Deliver the destination asset to the recipient
Committee UpdaterPublishes the active Supra committee’s threshold public keys to the HyperNovaCore Verifier on Ethereum at each epoch change
Last updated on