Skip to main content

How to configure a custom gas token for your Rollup Arbitrum chain

When deploying an Arbitrum chain in Rollup mode, you can use a custom ERC-20 token as the native gas token. This token is usable for Transaction fees on that specific Arbitrum chain and reimbursing the Batch poster for data posted to Ethereum. An example would be an L2 Rollup that uses USDC as its custom gas token but pays ETH to post data to L1 Ethereum.

Enabling a custom fee token for a Rollup chain requires additional configuration compared to an AnyTrust chain; it also introduces important exchange-rate considerations. This guide outlines specific implementation steps and operational considerations for chain owners or operators to consider when enabling a custom fee token for Rollups.

Requirements of the custom gas token​

A key requirement for a custom gas token is that it has a representation on the parent chain. During chain deployment, the gas token is "natively bridged" and then properly configured as the native gas token on the Arbitrum chain. Additional requirements include:

  • Must be a standard ERC-20 token
  • Transfers and approvals must occur directly via the token contract, not via proxies or hooks
  • Must not be rebasing or include transfer fees and
  • Must not use transfer callbacks or any onchain behavior that reverts if the sender and recipient are the same

Understanding the fee token pricer​

In Rollup mode, data posting costs to the Parent chain are paid in the parent chain’s native token but get reimbursed in the Child chain’s fee token. To facilitate this, you must deploy and register a fee token pricer contract, providing an exchange rate between the two tokens (child fee token and parent fee token). We use this exchange rate to calculate the custom fee tokens required to reimburse the batch poster for each batch they post to the parent chain.

Below are three example implementation options that chain owners may consider. Chain owners are free to develop their custom fee token pricers.

warning

The implementations included in the examples below have not undergone comprehensive testing or auditing. The intent is to illustrate different options for chain owners to consider.

1. Manual exchange rate​

The Chain Owner manually sets and updates the exchange rate; this is the simplest option but requires manual updates to track price changes or dependence on an owner-defined oracle.

This approach generally makes sense if:

  • You, as the chain owner, want full control over the exchange rate
  • The chain owner and the batch poster are the same entity
  • You are operating in a tightly controlled or experimental environment

An (unaudited) example to reference is: OwnerAdjustableExchangeRatePricer.sol

2. External oracle​

An external oracle fetches the exchange rate; this reduces operational requirements for the chain owner but introduces a dependency on an external service to provide accurate, reliable pricing data.

This approach generally makes sense if:

  • Reliable, robust oracles are available for the gas token pair
  • Reducing trust in the chain owner is important for your implementation
  • You, as the chain owner, want to avoid manual exchange rate updates

See an (unaudited) example here using a TWAP oracle: UniswapV2TwapPricer.sol

3. Exchange rate tracking​

The batch poster records the rate when converting the child gas token to the parent gas token. This approach can ensure accurate reimbursement but also requires trusted reporting and more complex accounting.

This approach generally makes sense if:

  • Your batch poster is trusted and willing to record exchange rates when purchasing parent chain gas
  • You want reimbursement to be precise and not over or under-charging users
  • You want to minimize reliance on the chain owner or external oracles

Consider this (unaudited) example: TradeTracker.sol

An important risk for chain owners to consider is exchange rate stability. If the fee token pricer returns stale or manipulated prices, the batch poster may be under- or over-reimbursed. In the case of under-reimbursement, the batch poster would continue operating but at a loss. In the case of over-reimbursement, end users would end up overpaying transaction fees. While this risk may be acceptable for experimental or early-stage chains, you should carefully consider the financial consequences for the batch poster or end users on your Arbitrum chain. The “External oracle” and the “Exchange rate tracking” approaches seek to mitigate this risk. Ultimately, the chain owner should assess their unique situation when determining which fee-pricing strategy makes the most sense for them (if any).

Configuration of the Rollup when using a custom gas token​

Here are the steps you should take to deploy your Arbitrum chain with a custom gas token:

  1. Deploy your ERC-20 token on the parent chain (if not already deployed)
  2. Deploy your fee token pricer
  3. Configure the fee token and pricer when creating the rollup
    • Use the createERC20Rollup.ts script, which accepts environment variables for:
    • FEE_TOKEN_ADDRESS = your ERC-20 gas token
    • FEE_TOKEN_PRICER_ADDRESS = your deployed pricer
    • ROLLUP_CREATOR_ADDRESS = the Rollup creator contract on L1
    • STAKE_TOKEN_ADDRESS = token used for staking (see BoLD docs for more details)
    • The script will deploy and initialize the Rollup accordingly.

You can refer to the source files for more details on:

You can also find more info about how Nitro manages gas and fees here. If you’re unsure how to configure the Rollup correctly or have questions about fee pricer implementations, please get in touch with Offchain Labs or your chain’s deployment provider.