Fees

A bridge transfer's total cost has exactly two components:

totalFee = LayerZero messaging fee + fixed protocol fee

• LayerZero messaging fee - paid to LayerZero for verification (DVNs) and destination execution (executor gas you buy via options). This part is dynamic and depends on the route, the gas you request, and current prices.
• Fixed protocol fee - a flat fee collected by the bridge. There is no percentage fee on bridge transfers: the dynamic protocol fee component is 0%.

Current native-fee settings:

Both fee settings are public on each bridge (fixedProtocolFee(), fixedFeeTokenProtocolFee()) and adjustable only by that chain's owner Safe, with FixedProtocolFeeChanged / FixedFeeTokenProtocolFeeChanged events on every change. Fee caps, receiver, issuer attribution, and issuer-specific fallback balances live in the bridge's feesManager(). Read the contract immediately before quoting; the table records the launch configuration, not a promise that governance can never update it within the onchain cap.

Quoting

Always quote immediately before sending. The quote functions return one number - the total the bridge will require, protocol fee included:

uint256 totalFee = bridge.quoteSendOriginal(
    dstEid,
    token,
    amount,
    recipient,
    isFirstTransfer,
    compose,
    options
);

Use the same isFirstTransfer flag, compose, and options bytes for the quote and the send, otherwise the amounts will not match. A composed transfer must buy separate index-0 lzReceive and lzCompose gas; adding both budgets into the receive option is not equivalent.

Exact-fee enforcement

The bridge requires the paid fee to exactly equal its own quote at execution time - not at least, exactly:

• On standard chains: msg.value == LayerZero fee + fixedProtocolFee, otherwise the call reverts with InvalidFee.
• Overpayment is rejected, not refunded - this keeps the contract free of refund logic and dust.

Because the LayerZero fee can move between your quote and your send, production integrations should re-quote and retry on an InvalidFee revert (the Omnisea web app retries up to 3 times).

Fee-token chains

On chains using LayerZero's EndpointV2Alt - detected at runtime via endpoint.nativeToken() != address(0) - fees are paid in an ERC-20 fee token instead of msg.value:

1. endpointNativeToken() returns the fee token address.
2. The quote is denominated in the fee token's smallest units and includes fixedFeeTokenProtocolFee.
3. The sender must approve the bridge for the quoted total and send with msg.value = 0. Any non-zero msg.value is rejected by the endpoint.

The active production route mesh currently uses native-token fee payment on every supported chain.

Omnilink read fees

Omnilink read delivery uses the same two-part shape but separate accounting from bridge transfers:

sendRead totalFee = LayerZero messaging fee + Omnilink fixedProtocolFee

quoteRead returns the total for one destination message. sendRead forwards the LayerZero portion, accounts for one flat Omnilink fee, and refunds excess native payment. Unlike the bridge transfer path, Omnilink therefore accepts msg.value >= totalFee rather than requiring exact equality.

The Omnilink owner can update fixedProtocolFee only up to the contract's immutable maxProtocolFee. Collected read fees remain reserved from native surplus recovery and can only be withdrawn to protocolFeeReceiver. Omnilink currently rejects LayerZero endpoints configured to collect their message fee in an ERC-20 token.

An optional OMNI read reward is not a protocol fee. requestRead sends no LayerZero message and charges no flat fee; it locks the requester's chosen OMNI amount locally until a matching read awards it or the requester cancels after one hour.

See Omnilink reads and Relay a read with Omnilink.

Omnibook taker fee

Omnibook orders use a separate fee model from bridge transfers.

Omnibook fills may charge a taker fee in the quote token. The deployment default is 5 bps, with an on-chain maximum of 100 bps. Direct takers set a maximum accepted fee for each transaction; permissionlessly matched orders use the aggressive order's creation-time fee snapshot.

There is no maker fee. A bounded share of the fee from crossed orders may be paid to the matcher. The remaining fee always accrues to the configured Omnibook fee recipient.

This fee is not a LayerZero messaging fee and is not part of the fixed bridge protocol fee. Read takerFeeBps() and matcherRewardBps() from the selected Omnibook deployment.

Who receives what

LayerZero's portion is forwarded to the endpoint at send time. The fixed protocol fee is paid directly to the configured protocolFeeReceiver when no issuer is configured for the source-chain token.

For verified issuer routes, the fixed protocol fee is split at send time:

Issuer attribution is configured per chain and token address. The source token can be either an original token or an Omnisea OFT representation. See Verified assets for the issuer-facing model.

If a protocol or issuer payout fails, the transfer still continues. The unpaid amount is stored in fallback accounting on the fee manager. Aggregate protocol balances are also exposed through bridge compatibility getters (collectedProtocolFees, collectedFeeTokenProtocolFees), while issuer-specific balances are read from feesManager().

Restore transfers - returning a failed transfer to its source - intentionally collect no protocol fee.