Fee Structure in SupraNova

SupraNova’s fee model is designed to sustain a permissionless, decentralized bridging ecosystem while incentivizing critical actors like relayers and committee updaters.

Fee Overview and Responsibilities

SupraNova applies two levels of fees internally but simplifies the user experience by exposing only the Service Layer Fee during transaction confirmation.

Verification Fee

An internal fee that compensates Committee Updaters for:

• Proof generation
• Signature validation
• Validator public key updates

Paid by: Service Layer (not the user directly)

Service Layer Fee

Visible to users and deducted upon initiating a bridge transaction. It covers:

• Operational costs
• Treasury accumulation
• Relayer and Committee Updater rewards

Then the system separates fees into two distinct layers:

Message Passing Layer Fee

This fee is charged for:

• Verifying Sync Committee proofs
• Verifying ancestry and receipt proofs
• Managing public key updates (Committee Updater work)
• Safe validators committee handovers through public key updates.

Who Charges It?

• The HyperNovaCore verifier contract charges this fee internally. Service-contracts calling the message-passing layer for validation pay this fee as part of the process.

Service Layer Fee (Token Bridge Specific)

This fee is charged by service-specific components like the Token Bridge and includes:

• Operational Service costs.
• Relayer rewards.

Who Sets It?

• The Token Bridge smart contract service owner (typically the protocol team).

How is it Collected?

Testnet and Mainnet collect the fee the same way. A small cut is deducted on the source chain, out of the asset being bridged, at the time the bridge request is submitted — not on the destination chain at delivery time.

• Bridging ETH or USDC from Ethereum, the cut comes out of the ETH or USDC being locked.
• Bridging supETH or supUSDC back from Supra, the cut comes out of the wrapped asset being burned.
• Bridging $SUPRA out of Supra, the cut comes out of the $SUPRA being locked.

What Does It Fund?

• Relayer incentives
• Operational treasury buildup

Fee Breakdown Example During a Bridge Transaction

• The net amount received on the destination chain will be slightly less than the amount sent, after fees.
• All fees are transparent and visible during the bridge confirmation step.
• Quote the exact figure from the contract before relying on it: inboundTokenFee on the Ethereum Token Bridge, get_fee_for_amount on the Supra Token Bridge module.

Incentivizing Liveness

Both relayers and committee updaters are permissionless roles that ensure network liveness and decentralization.

They are incentivized through fee rewards:

Without sufficient rewards:

• Relayers may delay proof submissions
• Committee updates may lapse, compromising security

SupraNova’s modular fee and reward system ensures both roles remain sustainably incentivized.

Fee Model for the SupraNova Bridge Protocol

This protocol involves a Token Bridge Service and a Message Passing Layer. The model details various fees and rewards, including:

• Service Fee (S)
• Relayer Rewards (RR)
• Committee Updater Rewards (CUR)
• Relayer Expense (RG)
• Committee Updater Expense (CUG)
• Verification Fee (V)

Key points of the model:

• Users pay a Service Fee (S) and gas costs when initiating a bridge request.
• Relayers are compensated with Relayer Rewards (RR) that cover their expenses (RG).
• Committee Updaters (CU) are rewarded (CUR) for keeping the source chain’s consensus keys current on the destination chain, covering their expenses (CUG). For Ethereum to Supra this is the Ethereum Sync Committee keys published to Supra; for Supra to Ethereum it is the Supra committee threshold keys published to Ethereum.
• RG and CUG are treated as constants determined by the Admin.

The same formulas apply in both directions, with the destination chain’s Committee Updater and verification costs substituted into the CUR, CUG and V terms.

Fee Derivation Formulas

Given traffic estimate X, and gross margins SM, VM, CUM, RM:

• CUR = CUG / (1 - CUM)
• V = (CUR / X) / (1 - VM)
• RR = (V + RG) / (1 - RM)
• S = RR / (1 - SM)

Tiered Service Fee Structure

To accommodate varying bridge volumes, SupraNova applies a tiered service fee model based on the value bridged in USDT:

Current On-Chain Fee Parameters

These are the values configured on the live deployments. Rates are expressed in basis points against a percentage base of 10000.

SupraNova Address Details

The same deployments serve both bridging directions. On Ethereum the contracts are proxies; on Supra the bridge is a set of Move modules.

Ethereum Mainnet

Supra Mainnet Move Modules

All six bridge modules are published under a single account, 0xda20f7d0ec813c751926f06004a10bc6ee1eefc96798f6a1aa31447ee146f932. Address a module as <account>::<module>, for example 0xda20f7d0ec813c751926f06004a10bc6ee1eefc96798f6a1aa31447ee146f932::token_bridge_service.

token_bridge_codec and the hypernova_core support modules (eth_types, message_types, proof_verifier, merkle_tree, helpers) are published at the same account as internal libraries.

Supra Testnet Move Modules

Asset Details

Each row is a bridging pair. Going Ethereum to Supra, the Ethereum-side asset is locked and the Supra-side asset is minted; going Supra to Ethereum, the same pair runs in reverse. Burning supETH can deliver either native ETH or WETH, depending on the destination token you select; both settle from the same vault against the same supETH balance.

Testnet

Mainnet

Asset Transaction Limits

Every bridged asset carries three configured caps, enforced on-chain by the vault that holds it:

• Global Cap – the total value the vault will hold in that asset.
• Per-Request Lock Limit – the most that can be locked in a single outbound request.
• Per-Request Release Limit – the most that can be released in a single inbound settlement.

A request outside these bounds is rejected up front, so the transfer cannot be started for an over-limit amount.

Ethereum Vault (Mainnet)

These caps apply to assets custodied on Ethereum: locked when bridging Ethereum to Supra, released when bridging Supra to Ethereum. The minimum is 1 base unit for every asset in both directions.

Native ETH is wrapped on the way in, so ETH transfers are bound by the WETH row.

Supra Vault (Mainnet) — $SUPRA

$SUPRA is native to Supra, so it is custodied by the Supra-side vault rather than the Ethereum vault. Its caps are configured on that vault through set_lock_limits and set_release_limits, and the Ethereum vault’s limits above never apply to it. $SUPRA amounts are denominated in quants (8 decimals).

The lock limit applies when $SUPRA leaves Supra for Ethereum; the release limit applies when it comes back. See Token Bridging Models for how the path works.

Reference Prices Used to Size the Caps

The caps above are value-normalised. These are the reference prices they were derived from, not live prices: