Skip to main content

Why choose to use a custom gas token on your Arbitrum chain

Choosing a custom gas token refers to configuring the chain to use a specific ERC-20 token—rather than ETH—as the native currency for paying transaction fees (gas costs) on your chain. This allows developers to tailor the fee structure to their project's ecosystem, such as using a stablecoin like USDC, a yield-bearing asset, or the project's own native token. The choice is made during chain deployment and is generally immutable afterward, integrating directly into the chain's genesis parameters.

Key Concepts​

  • Gas and Fees in Arbitrum: Gas represents the computational resources required for transactions and smart contract executions. Fees are calculated as gas used multiplied by gas price, covering sequencer costs, data posting to the parent chain (e.g., Ethereum or another Arbitrum chain), and network maintenance. In standard setups (like Arbitrum One), these are paid in ETH.
  • Custom Gas Token: An ERC-20 token deployed on the parent chain is "natively bridged" to the new Orbit chain and set as the gas token. Transactions on the child chain are validated against users' balances of this token, with fees deducted accordingly. The token must meet strict requirements: standard ERC-20 compliance (no proxies, hooks, rebasing, or transfer fees), typically 18 decimals, and transfers/approvals must not revert in edge cases.

How Fees Are Handled​

  • On the child chain: Gas costs are calculated and deducted in the custom token.

  • For data posting to the parent chain: The sequencer or batch poster collects custom tokens as revenue but must convert them to the parent's native token (e.g., ETH) to cover posting costs. This is managed via an exchange rate mechanism, such as a pricer contract that uses manual updates, oracles, or trade tracking. Inaccurate rates can lead to over- or under-reimbursement, impacting profitability.

  • Compatibility with Chain Types:

    • Rollup Mode: Supported for L2 chains posting data to Ethereum, requiring BoLD (Bounded Liquidity Delay) enabled and a fee token pricer for exchange rates. L3 support is planned but not yet available.
    • AnyTrust Mode: Directly supported with simpler configuration (no heavy pricer emphasis), ideal for cost-sensitive setups.
    • Alt-DA (Alternative Data Availability): Compatible, especially with cheaper DA providers like Celestia or EigenDA, which reduce conversion risks from token volatility.

Pros​

  • Enhanced token utility and demand: Using a custom ERC-20 token for gas fees creates inherent utility and constant demand for the project's native token, driving value accrual through practical use rather than speculation. This utility is particularly beneficial for ecosystems like gaming or DeFi, where it can support in-app economies and incentivize network participation.
  • Internalized economic value: Retention of transaction fees within the ecosystem, creating a sustainable model where the community captures the value generated by network activity, rather than relying on external tokens like ETH.
  • Improved user experience and onboarding: Users can pay fees with a single native token, eliminating the need to manage multiple assets (e.g., acquiring ETH separately). Using a single token can reduce friction, simplifying fee estimation, and enabling features like gas subsidies where projects pay fees on behalf of users, which is ideal for mainstream adoption in gaming or social platforms.
  • Unified brand and ecosystem identity: Interactions stay within the project's token economy, reinforcing branding and immersion (e.g., in-game currencies handling all fees).
  • Stability and predictability (with stablecoins): Using a stable token like USDC mitigates volatility in transaction costs compared to ETH, providing consistent and affordable fees.
  • Integration with existing tools: Native implementation in Arbitrum Orbit ensures compatibility with EVM tooling, deterministic gas accounting, and seamless deployment.

Cons​

  • Limited Flexibility (Native Implementation): Once deployed, it's difficult to support multiple gas tokens or switch tokens, requiring users to acquire the specific ERC-20 token, which can complicate onboarding and limit ecosystem diversity.
  • Potential sell pressure and economic risks: Fees must be converted to the parent chain's token (e.g., ETH) for data availability costs, creating systematic sell pressure on the custom token. Significant price declines (e.g., 50%) could lead to operational deficits, necessitating advanced economic modeling for forecasting, hedging, and reserve management.
  • Compatibility issues: May not work well with applications or tools expecting ETH, potentially impacting integration with broader Ethereum ecosystems.
  • Increased complexity (account abstraction implementation): This adds infrastructure, such as paymasters and bundlers, which complicates gas estimation, transaction flows, and tooling configuration (e.g., for explorers or indexers), with the risk of inconsistent adoption.
  • Migration challenges: Changing or migrating the gas token post-deployment involves high technical risks, including contract updates, chain pauses, and potential loss of funds.
  • Requirements and limitations: The token must meet specific criteria (e.g., standard ERC-20). While supported in Orbit, it relies on chain-wide adoption, which may not be suitable for all cases.

Examples​

  • Bridged USDC: Allows stable, predictable fees.
  • Project-native tokens in gaming or DeFi appchains, where users pay fees in the ecosystem's token for seamless integration.

For implementation, refer to the docs or your RaaS; a list of RaaSes is on the Third-party providers page.