Arbitrumbridge
Arbitrumbridge gateway options for different token requirements
Arbitrumbridge routes ERC-20 transfers through gateways that reflect each token's contract requirements. A standard representation suits ordinary token behavior. The generic-custom gateway accommodates a separately deployed child-chain token, while a dedicated gateway changes bridge logic. For holders, the token's configured gateway determines the destination representation.
Which gateway matches a token's requirements?
The standard gateway suits conventional ERC-20 behavior; custom token logic or specialized bridge accounting calls for different arrangements. Its automatic deployment avoids maintaining a separately designed child-chain token. A project that needs its own upgradeable representation can use the generic-custom gateway, provided the contracts meet its registration and token-interface requirements. A dedicated gateway becomes relevant when the built-in options cannot express the required transfer rules. These options describe different locations for customization within the same token bridge.
Gateway assignment belongs to token integration. A holder uses the established mapping and cannot freely substitute another gateway for the same token.
Router mappings connect tokens to their gateways
The router selects the gateway from the parent-chain token address, and that gateway identifies the corresponding child-chain token. This separates routing from the contracts that handle assets. L1GatewayRouter provides the parent-chain entry point; L2GatewayRouter handles routing on the child chain. Because each gateway pair coordinates transfers across a particular parent-and-child chain relationship, a matching name or symbol alone cannot establish that a specific destination token belongs to the gateway that handles the intended deposit.
In the shared router implementation, getGateway first reads the token-specific mapping. An unset mapping falls back to the configured default gateway. A disabled assignment or invalid gateway resolves to the zero address, indicating that this lookup has no usable gateway. These conditions prevent an assumption that every ERC-20 automatically follows the standard route in every deployment. The default gateway and any explicit assignment belong to the selected chain's bridge contracts.
The router forwards transfer calls. The gateway implements the asset-handling rules, including escrow or other specialized behavior.
Standard bridging creates a conventional token representation
For compatible tokens, standard bridging connects parent-chain escrow with a conventional ERC-20 balance on the child chain. For an eligible token without an existing counterpart, the standard gateway deploys StandardArbERC20 during child-chain deposit execution. The representation obtains its name, symbol, and decimals from the parent token when those metadata methods work. The child gateway controls bridge minting and burning. Automatic deployment does not reproduce arbitrary code from the parent token, such as its interest distribution or transfer restrictions.
Special transfer behavior needs separate consideration. In the shared parent-chain escrow implementation, the deposited amount follows the gateway's actual balance increase. A transfer tax can therefore make that amount differ from the requested transfer. Measuring incoming tokens does not establish that rebasing, transfer fees, or other custom behavior remains coherent throughout withdrawals and later transfers. Rebasing can change escrow balances without a matching bridge operation, which requires accounting beyond an ordinary fixed-balance representation. ERC-20 interface compatibility alone does not settle those questions.
Custom token behavior through the generic-custom gateway
The generic-custom gateway lets a project deploy its own child-chain token while retaining the built-in gateway pair. This arrangement supports project-selected token addresses, proxy-based upgrades, and address restrictions. Those features belong to the custom token implementation. Registering a token does not automatically add them, and its additional rules must remain compatible with the gateway's expected minting and burning behavior.
Parent-chain registration
Self-registration requires the parent token to return 0xb1 from isArbitrumEnabled during registration and make the gateway and router registration calls. The gateway records the parent-to-child token pairing. The router records the gateway assignment. These are related settings with different purposes, and a token deployment without the necessary registration methods cannot complete this self-registration path merely through a holder's wallet.
Child-chain interface
The child token implements IArbToken, which connects its token logic to the gateway's bridge operations. Additional functionality must preserve that contract relationship.
Mint and burn permissions
bridgeMint and bridgeBurn must accept calls only from the designated child-chain gateway. That restriction protects the gateway-controlled changes in token supply. Custom restrictions that prevent an expected gateway call from executing can interrupt the corresponding bridge operation, even though ordinary token transfers continue working.
Parent-token identity
The l1Address method returns the parent token's contract address. A matching ticker cannot replace this explicit relationship between the contracts.
When does a token need its own gateway?
A token needs dedicated gateway logic when its cross-chain accounting cannot fit the standard or generic-custom gateway. Interest-bearing assets need rules for value that accrues while tokens remain escrowed. Supply minted independently on the child chain also needs special treatment if those tokens must withdraw into assets that the parent contract recognizes. That requirement usually calls for a specialized gateway; ordinary deposit-backed minting does not establish backing for an unrelated supply increase.
In the WETH gateway implementation, deposits unwrap parent-chain WETH and wrap the transferred ETH into child-chain WETH. WETH means wrapped Ether. This gateway changes how the asset crosses the chain boundary while preserving a wrapped token at the destination. Its asset-handling logic differs from leaving an ERC-20 balance in parent-chain escrow. The mechanism belongs to that WETH gateway pairing and does not describe every wrapped token.
Dedicated gateways must implement the bridge interfaces and authenticate messages from their counterpart contracts. Custom code creates more responsibility for accounting and access control. Matching an interface does not establish that the implementation handles every token behavior safely, and demonstration code does not provide production security assurance.
An upgradeable token without a new gateway
In a hypothetical integration, a conventional parent-chain ERC-20 supports self-registration, the project wants an upgradeable child-chain token, and the bridge requires no special escrow accounting; the question is whether upgradeability requires a new gateway pair. The generic-custom gateway can accommodate that requirement because the project deploys the child token itself. The standard gateway's automatically created representation does not give the project the same control over its token implementation. The customization stays within the token contract, while the built-in gateway handles deposits and withdrawals.
For this integration, the parent token must support self-registration, and the child token must implement IArbToken with the designated gateway permissions. Once registration messages execute on the child chain, the mappings connect the parent token to that deployed representation through the generic-custom gateway. If an upgrade later changes supply or transfer behavior, that change still has to preserve the bridge's accounting and interface assumptions.
Registration messages establish the usable configuration
Generic-custom registration updates token pairing and router assignment through separate messages, even when a single parent-chain transaction initiates both. Successful parent-chain execution establishes the local updates; child-chain execution establishes their destination-side effects. A registration receipt alone cannot show that all child-chain configuration has completed. The destination contract must also exist at its registered address and enforce the required gateway permissions. Gas funding for registration messages remains separate from the token's design requirements. A completed mapping connects the contracts, but it does not remove restrictions that the token itself imposes.
What readers ask about Arbitrumbridge
Can an existing standard token later move to the generic-custom gateway?
An existing standard representation does not by itself prevent registration of a compatible custom token. The parent contract must meet registration requirements, and router permissions constrain changing an existing custom assignment. Updating the mapping changes where new deposits go; it does not automatically replace balances in the earlier child-chain contract. A migration must account for holders of those older tokens separately.
Do I approve the gateway or the router when depositing an ERC-20 token?
For deposits through the standard and generic-custom gateways, approve the gateway that the parent-chain router identifies for your token. The router forwards the deposit call, while the gateway transfers tokens into its custody. An allowance for a different spender does not give that gateway permission to use your balance. Approval establishes spending permission; it does not submit the deposit or complete the transfer on the destination chain.
How can I find a standard token's child-chain address before its first deposit?
The router's calculateL2TokenAddress method can resolve the destination address from the parent token address. For standard bridging, the gateway calculates that address deterministically, so the contract need not exist yet. A calculated address establishes the expected location, not successful deployment or a received balance. Use the router for the selected chain pairing so an explicit custom assignment also enters the lookup.
Will an extra approval requirement in bridgeBurn affect the Arbitrum bridge UI?
Adding an allowance check to bridgeBurn can prevent withdrawals from working through the Arbitrum bridge UI's default withdrawal flow. The UI expects the recommended gateway-token behavior and does not request that extra child-token approval by default. The contract may still support withdrawals through an integration that supplies the required allowance. Compatibility with gateway calls and compatibility with a particular interface are separate requirements.
Is custom registration possible when the parent token cannot be upgraded?
A chain-owner registration can provide an alternative when the parent token lacks the methods needed for self-registration. For Arbitrum One, that path involves Arbitrum DAO governance. A project may also wrap the parent token and register the wrapper, which creates a different token contract. Neither option lets an ordinary holder assign a gateway through a wallet approval.