Fee Model

A simple, predictable model where users pay a static, pre-defined amount for a transfer, regardless of transaction size or network congestion. This provides cost certainty but can be inefficient, overcharging for small transfers and undercharging for large ones.

• Example: A bridge might charge a flat 0.1 ETH fee for any transfer from Ethereum to an L2.
• Pros: Simple UX, predictable costs.
• Cons: Not cost-reflective, can be regressive.

Fees are calculated based on the real-time gas costs required to execute transactions on the source and destination chains. This model directly passes network congestion costs to the user.

• Mechanism: The bridge's relayer pays gas, and the user reimburses this cost plus a small service fee.
• Example: Bridges like Hop Protocol and Across use gas-aware models, where fees spike during high Ethereum congestion.
• Key Feature: Aligns bridge costs with underlying blockchain operational expenses.

A variable fee calculated as a percentage of the transfer amount. This is common for liquidity pool-based bridges, where fees compensate liquidity providers (LPs) for capital commitment and impermanent loss risk.

• Typical Range: Often between 0.1% and 0.5% of the transferred value.
• Purpose: Incentivizes and sustains the liquidity pool, which is the bridge's backbone.
• Consideration: Can be expensive for large transfers, favoring the bridge's economic security over pure cost-efficiency.

A core component for AMM-based bridges. Fees are distributed to users who deposit assets into the bridge's liquidity pools. This model creates a sustainable flywheel: fees attract LPs, which increases liquidity, improving swap rates and attracting more users.

• Distribution: Fees are often split between the protocol treasury and LPs.
• Example: Stargate Finance directs swap fees to veSTG token voters and LPs.
• Goal: Decentralize bridge ownership and security by financially rewarding backers.

For generic message bridges (e.g., LayerZero, Axelar), fees are charged for transmitting arbitrary data or smart contract calls, not just token value. The fee is based on the computational and storage cost of verifying the message on the destination chain.

• Pricing Factors: Message size, destination chain gas costs, and security configuration.
• Use Case: Enables cross-chain DeFi, governance, and NFT minting where the 'value' is in the instruction, not an asset.

Some models incorporate a fee that contributes to a security fund or insurance pool. This fund is used to cover user losses in the event of a bridge exploit or failure, acting as a decentralized insurance backstop.

• Mechanism: A small slice of each transaction fee is allocated to the fund.
• Rationale: Mitigates the systemic risk inherent in bridging by creating a collective safety net.
• Trade-off: Increases the base cost of transactions to pay for this risk mitigation.

On Ethereum and other EVM-compatible chains, a gas fee is the cost to execute a transaction or smart contract operation. It is calculated as:

• Gas Units: The computational work required.
• Gas Price: The price per unit, denominated in Gwei (10⁻⁹ ETH).
• Base Fee: A network-determined, burned component (post-EIP-1559).
• Priority Fee: An optional tip to validators for faster inclusion.

Total Fee = (Base Fee + Priority Fee) × Gas Units.

A priority fee (or tip) is a user-paid incentive for a validator to prioritize a transaction's inclusion in the next block. This interacts directly with Maximal Extractable Value (MEV), where validators and searchers reorder, include, or exclude transactions to capture arbitrage, liquidation, or other profits. High priority fees are often necessary to outbid competing MEV opportunities.

EIP-1559 reformed Ethereum's fee model by introducing a variable base fee that adjusts per block based on network congestion. This base fee is burned (removed from supply), creating a deflationary pressure. The model aims for more predictable fees and a fee market where users bid with priority fees for limited block space, improving economic efficiency and security budget.

A network's security budget is the total value expended annually to secure the chain, primarily via block rewards and transaction fees paid to validators. A sustainable fee model ensures this budget is sufficient to make attacks prohibitively expensive. If fees are too low, security may rely excessively on inflationary token issuance, which can dilute holders and reduce long-term security.

Not all chains use auction-based gas models. Common alternatives include:

• Fixed Fees: A set, predictable cost per transaction (e.g., Solana's lamports).
• Fee Burning: A portion of all fees is permanently destroyed (e.g., BNB Chain's auto-burn).
• Fee Distribution: Fees are shared with stakers or a treasury (common in Cosmos SDK chains).

Each model creates different economic incentives for users, validators, and token holders.

Economic abstraction allows users to pay transaction fees in tokens other than the native chain currency (e.g., paying Ethereum gas fees in USDC). Sponsored transactions (or gasless transactions) enable a third-party dapp or relayer to pay fees on behalf of users, improving UX. Both concepts decouple fee payment from asset holding but introduce complex security and incentive considerations for validators.