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​

  • Enhances token utility and ecosystem alignment (e.g., demand sink for project tokens).
  • Improves user experience by avoiding ETH dependency and enabling stable or yield-bearing fees.
  • Supports onboarding strategies like airdrops and compliance via token controls.
  • More feasible with low-cost DA, minimizing economic risks.

Cons​

  • Adds deployment and operational complexity (e.g., pricers, funding for conversions).
  • Introduces risks from exchange rate fluctuations, potentially causing losses for operators or higher fees for users.
  • Immutable post-deployment; token must adhere to strict standards.
  • Not ideal for high-volatility tokens without hedging, especially on expensive DA like Ethereum mainnet.

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.