SupraNova Bridge - Bridging between Ethereum and Supra

Introduction

SupraNova is a cross-chain communication framework developed by Supra. It enables the transfer of assets and messages across blockchains by integrating multiple bridging technologies under a unified architecture.

SupraNova does not represent a single bridge protocol. Instead, it supports two different bridging technologies based on use cases:

HyperNova : A trustless bridge protocol that uses the source chain’s consensus layer for event verification using validator signatures.
Hyperloop : A fast, multi-signature based game-theoretically secure bridge designed for source chains for which HyperNova style trustless bridging is not applicable or feasible or results in high latency (Layer 2 chains).

By combining these models, SupraNova offers both trust-minimized and high-speed bridging capabilities that can be selected per deployment context.

✅

SupraNova currently supports bi-directional HyperNova style trustless bridging between Ethereum and Supra.

Ethereum to Supra

The forward direction locks the original asset on Ethereum and issues a wrapped representation on Supra.

Native ETH, wETH, USDC, USDT, WBTC and SolvBTC are locked in the Ethereum vault.
The matching wrapped asset (supETH, supUSDC, supUSDT, supBTC, supSolvBTC) is minted on Supra using the FA token standard.
A permissionless relayer proves the Ethereum lock event to the HyperNovaCore verifier on Supra, using Sync Committee signatures, a receipt proof and, when needed, an ancestry proof.

This is the Lock-Mint model.

Supra to Ethereum

The reverse direction returns value to Ethereum. Which action the Supra side takes depends on where the asset originates:

An asset that originated on Ethereum is held on Supra as a wrapped FA, so it is burned on Supra and the original is released from the Ethereum vault.
An asset native to Supra, such as $SUPRA, cannot be burned on its own home chain, so it is locked in the Supra-side vault and the Ethereum-side token is delivered to the recipient.
A permissionless relayer proves the Supra event to the HyperNovaCore verifier on Ethereum, using Merkle accumulator proofs and the Supra committee’s threshold certificate.

See Token Bridging Models for the per-asset breakdown.

Direction and Model Summary

Direction	Asset origin	Source chain action	Destination chain action
Ethereum to Supra (Forward)	Ethereum-native (ETH, WETH, USDC, …)	Lock in the Ethereum vault	Mint the wrapped FA on Supra
Supra to Ethereum (Reverse)	Ethereum-native, wrapped on Supra	Burn the wrapped FA on Supra	Release the original from the Ethereum vault
Supra to Ethereum (Reverse)	Supra-native ($SUPRA)	Lock in the Supra-side vault	Deliver the Ethereum-side token to the recipient

On the Supra to Ethereum leg, whether the Ethereum-side token is released from the vault or issued by the bridge is a per-token property of that token on Ethereum, not a different bridge flow. Verification, relaying and fee handling are identical either way.

How the Two Directions Compare

Aspect	Ethereum to Supra	Supra to Ethereum
Consensus anchor	Sync Committee BLS aggregate over the beacon block header	Committee `ClanMajority` BLS12-381 threshold signature over the block’s accumulator roots
Reaching the event’s block	Ancestry Proof via `block_roots` or `historical_summaries`	Not required; the certificate names the block height directly
Inclusion evidence	Receipt proof showing the bridge event was emitted in a successful transaction	Two Merkle accumulator proofs: event → transaction → block
Key rotation	Committee Updater refreshes Sync Committee keys on Supra every ~27 hours	Committee Updater refreshes Supra committee threshold keys on Ethereum every epoch
Verification cost control	Per-proof verification	Cached accumulator root per block height, plus batch verification under one signature check
Failure mode of a bad relayer	Supra verifier rejects the request	Ethereum verifier rejects the request