Cross-Layer Token Integration (ERC-20 Gateway)

The Scroll ERC-20 gateway provides the canonical path for representing native L1 tokens on the L2. When a token project deploys on Ethereum mainnet and wants its asset to be available on Scroll, it does not deploy a new contract on the L2. Instead, it registers the L1 token with the gateway, which deploys a corresponding ScrollStandardERC20 proxy contract at a deterministic address on Scroll. This proxy automatically mirrors the L1 token's name, symbol, and decimals, ensuring that wallets, explorers, and dApps display the asset consistently without requiring manual metadata synchronization.

The gateway operates as a lock-and-mint bridge: users deposit tokens into the L1StandardERC20Gateway contract on Ethereum, which locks the assets and sends a cross-layer message to the L2StandardERC20Gateway on Scroll to mint an equivalent amount on the L2 proxy. Withdrawals reverse the flow by burning tokens on Scroll and releasing the locked L1 tokens after the challenge period. This architecture means that token projects do not need to write custom bridge contracts for standard ERC-20s, but they must ensure their L1 token is registered correctly—including verifying that the gateway recognizes the correct metadata and that no conflicting registrations exist.

For token project teams, DeFi protocol deployers, and wallet integrators, the gateway registration process is a critical integration step. Incorrect metadata resolution can fragment liquidity, confuse users, and break composability with lending markets, AMMs, and aggregators. Chainscore Labs helps teams audit the registration flow, verify metadata consistency across layers, and review the gateway's interaction with custom token logic such as fee-on-transfer mechanics or rebasing tokens that may behave unexpectedly within the lock-and-mint model.

The standard gateway is the default, permissionless mechanism for bridging fungible tokens between Ethereum L1 and Scroll. It operates through a pair of gateway contracts—one on L1 and one on L2—that communicate via the canonical bridge's message-passing system. When a token project calls registerToken on the L2 gateway, the system deploys a counterpart token contract on the opposite layer using a deterministic CREATE2 address. This ensures that every L1 token maps to exactly one L2 representation and vice versa, preventing the liquidity fragmentation and user confusion that plague multi-bridge ecosystems.

The gateway enforces strict metadata consistency. During registration, it queries the original token's name(), symbol(), and decimals() and encodes them into a cross-layer message. The counterpart ScrollStandardERC20 contract is initialized with this exact metadata. This design prevents a common integration failure where wallets and explorers display incorrect token information because they rely on on-chain metadata rather than off-chain token lists. The gateway also handles the deposit and withdraw lifecycle: L1 tokens are locked in the gateway contract while the equivalent amount is minted on L2; on withdrawal, L2 tokens are burned and the L1 tokens are released. This lock-and-mint pattern preserves total supply invariants across layers.

For token project teams, the integration surface is small but the correctness requirements are high. The L1 token must be a standard ERC-20 without rebasing, fee-on-transfer, or other non-standard balance mechanics that would break the gateway's accounting. Teams must also verify that the automatically deployed L2 contract matches their expected bytecode and that the gateway and counterpart addresses are correctly set. Wallet integrators should resolve token metadata from the L2 contract directly rather than maintaining manual mappings. Chainscore Labs reviews token gateway integrations for metadata consistency, supply invariant correctness, and edge-case handling—ensuring that tokens behave identically across layers and that users never encounter broken balances or incorrect display names.