Why choose to use native interop token with mint/burn as your Arbitrum chain gas token

Bridge counterparty risk

While this feature allows an Arbitrum chain to use native interop tokens as gas tokens via third-party protocols, it introduces new trust assumptions. In a standard Arbitrum chain, the canonical bridge is the sole authority for minting the chain's gas token, inheriting the security of the parent chain.

However, by using a third-party bridge for the chain's gas token, your chain's gas token—and thus its liveness—becomes directly dependent on the security and integrity of the third-party bridge provider.

info

While Native Mint/Burn was introduced in ArbOS 41, we strongly recommend that teams upgrade to ArbOS 51 Dia to enable this feature.

Arbitrum chains are designed to “lock and mint” the native gas token in the canonical bridge. This process ensures the child representation of the gas token is always backed by the parent chain's gas token, locked in the canonical bridge.

This "lock and mint" pattern is not compatible with an emerging category of "native interop tokens." These tokens rely on cross-chain messaging layers to facilitate a "burn and mint" approach to cross-chain bridging, meaning the representative asset is burned on the source chain and minted on the destination chain. Examples of tokens with this pattern include: LayerZero OFTs, the xERC-20 standard, or stablecoins such as Circle’s Native USDC (possible with Circle-supplied adapter) and Tether's USDT0.

ArbOS 51 Dia introduces the ability for native-interop tokens to work seamlessly as the gas token of an Arbitrum chain. This feature allows a chain owner (ArbOwner) to manage:

1. Permissioning of onchain addresses (typically, a token adapter contract) that have mint and burn access to the chain's native gas token on the child chain.
2. A security switch to timelock changes to native mint and burn permissioned addresses (mitigating the risk of misuse or attack).
3. A collateral-sweeping method to ensure the third-party native interop token’s cross-chain adapter contract always remains properly collateralized.

important

The native mint/burn feature permits mint and burn capability of the Rollup’s native gas token by a permissioned address on the Rollup. It does not provide a solution for cross-chain interoperability and is not a replacement for third-party omni-chain gas token products provided by partners such as LayerZero or Hyperlane. The table below helps to clarify the components needed to enable the use cases below.

Component	Maintainer	Role/purpose
ArbOS/Nitro (consensus-v51 or higher)	Offchain Labs	• Precompile ArbNativeTokenManager • Owner allowlist and 7-day timelock • Node rule that blocks value-bearing withdrawals while an owner is present
Adapter contract	Bridge infra provider (LayerZero, Hyperlane, etc.)	• Verifies cross-chain messages • Calls mintNativeToken / burnNativeToken on L2 • Manages collateral vault on L1
Chain Configuration and Adjacent Infrastructure	Chain operator	• Permission the adapter address with mint & burn • Run the outbox-sweep bot (this could also be run by e.g., LayerZero) • Monitor timelock and supply events (could also be responsibility of e.g., LayerZero)

Use cases

• LayerZero OFT as a gas token.
• xERC-20 token as a gas token.
• Stablecoins (e.g. USDC) use mint/burn functionality for cross-chain interop.

What this feature helps with:

• Launch a new Arbitrum chain with a native mint/burn gas token using a third-party bridge provider.
• Transition an existing native gas token from the canonical bridge (lock-and-mint) to a third-party bridge (e.g., LayerZero OFT) to enable "burn-and-mint" interoperability.

What this feature does NOT help with:

• Changing gas tokens: This feature cannot be used to swap your chain's current gas token for a completely different token.
• Multiple gas tokens: You cannot add additional native mint/burn gas tokens to your Arbitrum chain; an Arbitrum chain only supports a single native gas token.

Notes:

• We do not recommend enabling native mint/burn if your chain relies on the canonical bridge for liquidity or if you cannot comfortably implement the operational safeguards listed below.
• This feature is bridge-agnostic, so it’s possible to migrate from a bridge adapter implementation (e.g., LayerZero-OFT adapter) to another adapter without forking the chain or changing the gas token.
• Infra-level benefit: unifies liquidity so Arbitrum stack chain users see only one native gas token and avoid the previous “two bridge pools” condition (LayerZero integration still uses a lockbox/representation model, thus it does not remove wrapping globally).

Feature architecture

There are three components make up the native mint/burn feature:

• Timelock gate (safety switch): a safety feature that tells the chain owners when the feature is live. The default value is seven days to give chain owners sufficient time to identify and prevent a malicious owner addition.
• Mint and burn precompile: the main component that gives access control and admin interface.
  • mintNativeToken(uint256 amount): mints to the caller (the adapter), the adapter then transfers to the end user in the same transaction.
  • burnNativeToken(uint256 amount): burns the caller’s balance as part of an exit.
• Collateral-safety track: this ensures that all withdrawals are processed through the adapter and includes an L1 helper contract to sweep any native gas stuck in the bridge to the adapter's escrow.

Below is a high-level data-flow diagram:

Security timeLock

As native mint/burn introduces a security risk (an ArbOwner-level attacker can mint unlimited native gas), we have introduced a speed bump/delay feature that introduces a hard-coded delay for enabling native mint/burn capabilities (for an already live chain).

Our hard-coded default for this period is seven days, commensurate with existing L2BEAT advisories on time locks. This period should give the chain owner time to respond to an attacker’s attempt to mint/burn the native gas token.

Details for the time lock switch are:

• A chain that has already initialized with native mint/burn disabled must wait seven days for the precompiles to activate
• A chain can disable native mint/burn instantly

A seven-day timelock gates the feature. Call ArbOwner.setNativeTokenManagementFrom with a UNIX timestamp ≥ now + 7 days to enable the feature; disabling is instantaneous.

Important

The native token mint/burn feature is currently not available for implementation at chain genesis. The ability to activate it during chain initialization will be part of a future release.

Native mint and burn precompiles

1. The chain exposes the ArbNativeTokenManager precompile with these methods:
   • mintNativeToken(uint256 amount): when the adapter receives a valid cross-chain message, it forwards a freshly minted gas token to the user in the same transaction.
   • burnNativeToken(uint256 amount): destroy native gas token as part of a withdrawal
2. Only addresses in the native-token owners list may call these methods. Chain owners manage that list through ArbOwner:
   • addNativeTokenOwner(address)
   • removeNativeTokenOwner(address)

A third-party messaging layer triggers its Adapter to unlock to a specific address. The Adapter mints new tokens and distributes them to the user.

Collateralization technique

Guarantee collateralization of the native mint/burn contract

The main risk of having two contracts responsible for native token issuance (the third-party contract and the chain’s bridge) is collateralization imbalances. For example, you could end up with:

• 90% of tokens in the third-party contract
• 10% of tokens in the Arbitrum Stack chain bridge

In which case, either could be under-collateralized for a withdrawal at any given time.

This problem can be resolved through a combination of automatic safeguard implemented by the protocol and a liquidity migration setup:

1. Automatic canonical bridge withdrawalal disabling: Value-bearing withdrawals via the canonical bridge are automatically rejected as long as at least one native-token owner exists. This ensures the third-party token contract is the primary way to exit the chain (prevents an under-collateralized withdrawal on the bridge). This approach still maintains the censorship-resistant properties, allowing the user to initiate a withdrawal from L1.
2. Collateral sweep: Allow the parent-chain bridge contract to ‘sweep’ native gas tokens to a designated third-party contract. Presumably, this is the contract that holds collateral for the chain (e.g., in LayerZero’s case, the parent chain's Adapter contract).

The collateral sweep is implemented by adding an outbox contract to the bridge that can permissionlessly send only native gas tokens locked on the parent chain bridge to a third-party contract. This keeps all collateral in one place when mint/burn is enabled.

• Outbox contracts are authorized to spend funds from the bridge. They can be registered using the admin function setOutbox.
  Typically, an Outbox contract requires verification of a proof for an authorized withdrawal to occur. A custom contract can be designed that permissionlessly sends native gas to a destination on the parent chain.
• A helper contract, ERC20MigrationOutbox, can sweep any “dust” that lands in the bridge and transfer it to the external adapter on L1.

How to configure

To learn how to configure this feature for your chain refer to the Configure a native mint/burn gas token page.