Cross-Chain Gas

This feature abstracts the complexity of managing multiple native tokens for gas. A user can initiate a transaction on Chain B (e.g., an Arbitrum swap) while paying the gas fee with an asset held on Chain A (e.g., Ethereum's ETH). The underlying protocol handles the fee estimation, conversion, and payment on the user's behalf.

• Eliminates Pre-funding: No need to bridge gas tokens to a new chain before first use.
• Simplifies UX: Users interact with a single asset across multiple ecosystems.

Cross-chain gas is typically facilitated by a network of independent relayers or gas stations. These entities pay the upfront native gas fee on the destination chain. They are later reimbursed, often with a small premium, in the user's source-chain asset via a smart contract settlement layer.

• Incentive Model: Relayers earn fees for providing liquidity and service.
• Non-Custodial: User assets are never held by the relayer; settlement is trustless.

The system must dynamically calculate the equivalent cost of a destination chain's gas fee in the user's source-chain asset. This involves a real-time cross-chain price oracle to fetch the exchange rate between the two gas tokens and an accurate estimation of the required gas units for the pending transaction.

• Real-Time Quotes: Users see the total cost in their preferred token before confirming.
• Prevents Underpayment: Accurate estimation ensures transactions are properly relayed.

The user's core action (e.g., a swap, mint, or bridge) and the cross-chain gas payment are executed as a single, atomic operation. If the gas payment fails, the entire transaction bundle reverts, protecting the user from partial execution.

• Atomicity: Guarantees all-or-nothing execution.
• Security: Users cannot lose funds to a failed gas payment while their main transaction succeeds.

Some implementations allow dApps or protocols to sponsor gas fees for their users as a growth tactic. This is a form of meta-transaction where the fee logic is embedded in the application's smart contracts, enabling gasless interactions.

• User Acquisition: Lowers barrier to entry for new users.
• Flexible Models: Sponsorship can be full, partial, or conditional.

A model where a third-party network of relayers pays the gas fee on the destination chain on behalf of the user. The user typically signs a message authorizing the fee payment, and the relayer is reimbursed, often with a small premium, in the user's native asset from the origin chain. This decouples the need for the user to hold the destination chain's native token.

• Example: The Axelar Network uses a decentralized network of validators that act as gas relayer-executors.
• Key Concept: User signs a gasless transaction intent; the relayer executes and gets paid later.

In this model, the user prepays for the destination chain's gas fees when initiating the cross-chain message. The fees are locked in a smart contract on the origin chain, often in a stablecoin or the origin chain's native token. A bridge validator or relayer then uses these locked funds to cover the gas costs upon executing the message on the destination chain.

• Example: Wormhole's Automatic Relayer allows developers to prepay fees in USDC to cover gas costs on any supported destination.
• Key Concept: Eliminates trust in a relayer's liquidity by prepaying into a verifiable escrow.

Protocols create a universal gas token (e.g., a stablecoin or a protocol-specific token) that is accepted as payment for gas across all connected chains. Users hold this single token to pay for transactions on any supported network. The bridge infrastructure handles the conversion or provides the necessary native gas tokens to validators.

• Example: LayerZero's OFT (Omnichain Fungible Token) standard can be extended to facilitate gas payments, where the token itself carries value to cover fees on the destination.
• Key Concept: Reduces portfolio fragmentation by using a single, cross-chain accepted asset for fees.

This advanced model uses account abstraction (ERC-4337) or similar concepts on the destination chain. A smart contract wallet (the abstracted account) on the destination chain can have its transactions paid for by a separate sponsor or paymaster. The cross-chain protocol acts as or coordinates with the paymaster, settling gas fees in the user's preferred currency off-chain.

• Example: Polygon's Gas Station Network concepts, applied cross-chain, where a dApp or bridge protocol sponsors user gas.
• Key Concept: Leverages smart contract wallets to separate fee payment logic from transaction execution.

The protocol maintains liquidity pools of native gas tokens on various destination chains. Users pay a fee in their origin-chain asset, which is used to replenish these pools. A keeper or validator draws from the destination chain's pool to execute the user's transaction. The economic model ensures pools remain solvent through fee calculations and rebalancing.

• Example: Celer Network's cBridge uses a liquidity pool model where relayers are incentivized to maintain gas token liquidity.
• Key Concept: Relies on decentralized financial primitives (liquidity pools) to source gas tokens efficiently.

This is not an implementation but the core challenge that the above models solve. Every blockchain requires transaction fees (gas) to be paid in its native token (e.g., ETH on Ethereum, MATIC on Polygon). For a user on Chain A to interact with Chain B, they must acquire Chain B's token first, creating a poor user experience and fragmentation.

• Key Barriers: Onboarding complexity, capital inefficiency (holding multiple gas tokens), and centralized exchange dependency.
• Solution Goal: All cross-chain gas models aim to abstract this problem away from the end-user.

A user on Chain A wants to interact with a dApp on Chain B. Without cross-chain gas, they must first acquire Chain B's native token (e.g., ETH for Ethereum, MATIC for Polygon) to pay fees, a cumbersome multi-step process. Cross-chain gas solutions abstract this by allowing payment with the asset already in the user's wallet on the origin chain.

A common architectural pattern where a third-party relayer (or the protocol itself) pays the gas fee on the destination chain on the user's behalf. The user's initial transaction on the origin chain includes a small premium or fee that compensates the relayer, often in the origin chain's native asset. This is foundational to many gasless transaction experiences in cross-chain apps.

Several major interoperability protocols have built-in or auxiliary gas payment features:

• Axelar's Gas Services: Allows dApps to prepay for users' gas on connected chains.
• LayerZero's Omnichain Fungible Token (OFT) Standard: Can be configured to deduct estimated destination chain gas from the bridged amount.
• Wormhole's Native Token Transfers (NTT): Enables token-specific governance to manage relay costs.
• Chainlink CCIP: Offers a fee management system where fees can be paid in the source chain's LINK token.

Some ecosystems propose a universal gas token that is accepted across multiple chains. A user holds this single token (e.g., in a wallet on a primary chain) and it is automatically converted or used to sponsor transactions on any connected chain. This approach aims for maximal user abstraction but requires deep integration and liquidity across chains.

ERC-4337 Account Abstraction and similar standards on other chains are a powerful enabler. A smart contract wallet (account) on the destination chain can be programmed to accept fee payments from a paymaster contracted on the origin chain. This decouples the fee payment logic from the transaction execution, creating a seamless user experience.

Cross-chain gas introduces new economic models and risks:

• Relayer Incentives: Systems must ensure relayers are reliably compensated, often via fee auctions or fixed rates.
• Gas Estimation Volatility: Mispricing destination chain gas can lead to failed transactions or relayer losses.
• Centralization Risk: Relayer networks can become bottlenecks; decentralized validator-based payment is a developing solution.
• Sponsored Transaction Limits: Protocols often impose caps to prevent spam and economic attacks.

A protocol or standard that enables communication and value transfer between distinct blockchains. These are the foundational systems that make cross-chain gas possible. Key examples include:

• IBC (Inter-Blockchain Communication): A protocol for sovereign chains to exchange data and tokens.
• CCIP (Cross-Chain Interoperability Protocol): A standard for generalized messaging and token transfers.
• LayerZero: An omnichain protocol for lightweight message passing.

The process of moving assets or data from one blockchain to another. It is the primary action that requires cross-chain gas. There are two main models:

• Lock-and-Mint: Assets are locked on the source chain and a wrapped representation is minted on the destination.
• Liquidity Pool-Based: Assets are swapped via pools on both chains, facilitated by relayers. The gas fee on the destination chain must be covered, often via the relayer or a meta-transaction.

A network participant or service responsible for submitting transactions or proof data on a destination blockchain. In cross-chain operations, the relayer is often the entity that must pay the native gas fee. Users may reimburse the relayer in a different token, which is the core function of cross-chain gas abstraction. Relayers can be permissionless or permissioned.

A broader concept where users pay for transaction fees using methods other than the network's native token. Cross-chain gas is a specific form of gas abstraction. Other forms include:

• Sponsored Transactions: A third party (dApp, relayer) pays the gas fee.
• Paymasters (EIP-4337): Smart contracts that allow fee payment in ERC-20 tokens or via alternative logic on the same chain.

The fundamental action in cross-chain communication, where arbitrary data or instructions are sent from a source to a destination chain. Executing these messages on the destination chain consumes gas. Cross-chain gas solutions ensure the executor (e.g., a relayer or a smart contract) is compensated, enabling generalized cross-chain applications beyond simple token transfers.