Token Bridge Smart Contract Interface

SupraNova’s Token Bridge is a service layer contract deployed on both chains. There is no separate “reverse” contract: the same deployments serve both directions, with an outbound entry point on each chain and a verification-gated inbound path on the other.

Ethereum-side Token Bridge contract

Outbound calls, used when bridging from Ethereum to Supra:

function sendNative(uint64 chainId, bytes32 receiver, bytes32 payload) external payable;
function sendTokens(uint64 chainId, address token, uint256 amount, bytes32 receiver, bytes32 payload) external;

• sendNative(): Locks native ETH on Ethereum and emits a bridge event for Supra to process.
• sendTokens(): Locks an approved ERC20 token for cross-chain bridging.
• calculateTokenBridgeFee(address token, uint256 amount): Returns the service fee applicable for a given asset and amount.
• isRegistered(address tokenAddress): Checks if a token is approved for bridging.
• isChainIdRegistered(uint256 chainId): Checks if a destination chain is supported.

The inbound path is not called by users. A relayer submits the Supra event together with its proof bundle, the contract forwards it to HyperNovaCore for verification, and only on success does it deliver the destination asset, releasing it from the vault or issuing it, depending on the token.

Configuration and view functions relevant to integrators: inboundTokenInfo(chainId, token), outboundTokenInfo(chainId, sourceToken), chainData(chainId), isChainEnabled(chainId), vault(), hypernova(), feeOperator().

Supra-side Token Bridge module

The outbound call is a single Move entry function. It covers both bridging models — burning a wrapped FA asset, and locking a Supra-native asset such as $SUPRA — because the registry already records which applies to the token being sent.

public entry fun send_tokens<CoinType>(
    account: &signer,
    to_chain_id: u64,
    token_address: address,
    should_unwrap: bool,
    amount: u64,
    receiver_address: vector<u8>,
    payload: vector<u8>,
)

• to_chain_id selects the destination chain; receiver_address is the 20-byte EVM recipient.
• should_unwrap asks the destination to deliver the native asset rather than its wrapped ERC20 form, which is how burning supETH can release ETH instead of WETH.
• amount is a u64 in the token’s Supra-side denomination.

Supporting views on the same module include get_outbound_token_info, get_inbound_release_token_info, get_fee_for_amount, get_chain_config, and is_token_bridge_paused.

Supra-side token vault

Custody for Supra-native assets lives in the vault module, which mirrors the Ethereum vault:

• lock_tokens(token_bridge: &signer, fa: FungibleAsset) – locks the asset on the outbound leg.
• release_tokens(...) – releases it again when the Ethereum-side representation is returned.
• lock_limits(token_address) / release_limits(token_address) – the configured caps, set by set_lock_limits and set_release_limits.
• locked_token_balance(token_address), is_release_enabled(), is_vault_paused() – state views.

These methods provide a flexible, decentralized interface for both end-users and cross-chain applications interacting with SupraNova.