​
Using the Standard Bridge

The Standard Bridge is a basic token bridging system available on Adventure Layer Testnet and all other standard OP Stack chains. The Standard Bridge allows you to easily move ETH and most ERC-20 tokens between Ethereum and Adventure Layer Testnet. Transfers from Ethereum to Adventure Layer Testnet via the Standard Bridge are usually completed within 1-3 minutes. Transfers from Adventure Layer Testnet to Ethereum are completed in 7 days as a result of the withdrawal challenge period.

The Standard Bridge is fully permissionless and supports standard ERC-20 tokens. Other bridging systems also exist that provide different features and security properties. You may wish to explore some of these options to find the bridge that works best for you and your application.

​
Design

The Standard Bridge allows users to convert tokens that are native to one chain (like Ethereum) into a representation of those tokens on the other chain (like Adventure Layer Testnet). Users can then convert these bridged representations back into their original native tokens at any time.

This bridging mechanism functions identically in both direction — tokens native to Adventure Layer Testnet can be bridged to Ethereum, just like tokens native to Ethereum can be bridged to Adventure Layer Testnet. Here you’ll get to understand how the Standard Bridge works when moving tokens from Ethereum to Adventure Layer Testnet. Since the bridging mechanism is mirrored on both sides, this will also explain how the bridge works in the opposite direction.

​
Architecture

The Standard Bridge is composed of two contracts, the L1StandardBridge (on Ethereum) and the L2StandardBridge (on Adventure Layer Testnet). These two contracts interact with one another via the CrossDomainMessenger system for sending messages between Ethereum and Adventure Layer Testnet. You can read more about the CrossDomainMessenger in the guide on Sending Data Between L1 and L2.

​
Bridged Tokens

The Standard Bridge utilizes bridged representations of tokens that are native to another blockchain. Before a token native to one chain can be bridged to the other chain, a bridged representation of that token must be created on the receiving side.

A bridged representation of a token is an ERC-20 token that implements the IOptimismMintableERC20 interface. This interface includes a few functions that the StandardBridge contracts use to manage the bridging process. All bridged versions of tokens must implement this interface to be used with the StandardBridge. Native tokens do not need to implement this interface.

A native token may have more than one bridged representation at the same time. Users must always specify which bridged token they wish to use when using the bridge. Different bridged representations of the same native token are considered entirely independent tokens.

​
Bridging Native Tokens

The Standard Bridge uses a “lock-and-mint” mechanism to convert native tokens into their bridged representations. This means that native tokens are locked into the Standard Bridge on one side, after which bridged tokens are minted on the other side. The process for bridging a native token involves a few steps.

1

The Standard Bridge must be able to pull tokens from the user to lock them into the bridge contract. To do this, the user must first give the bridge an allowance to transfer the number of tokens that the user wishes to convert into a bridged representation.
2

After providing a sufficient allowance, the user calls the bridgeERC20To function on the StandardBridge contract on the chain where the native token lives (e.g., the L1StandardBridge contract if the token is native to Ethereum).
3

The user must provide the following parameters to this function call:
4

  • address _localToken: Address of the native token on the sending side.
  • address _remoteToken: Address of the bridged representation on the receiving side.
  • address _to: Address of the recipient of these tokens, usually the sender’s address.
  • uint256 _amount: Number of tokens to transfer.
  • uint32 _minGasLimit: Gas to use to complete the transfer on the receiving side.
  • bytes calldata _extraData: Optional identify extra data.
    • 5

    When the user triggers the bridgeERC20To function while transferring a native token, the Standard Bridge will pull the _amount of _localToken tokens from the user’s address and lock them inside of the bridge contract. A record of all locked tokens are stored within a deposits mapping that keeps track of the total number of tokens deposited for a given _localToken and _remoteToken pair.
    6

    Since a native token may have more than one bridged representation, the deposits token must keep track of the deposit pools for each _localToken/_remoteToken pair independently.
    7

    To illustrate, suppose that two users deposit 100 units of the same native token, Token A, but wish to receive two different bridged tokens, Token B and Token C. Although the Standard Bridge would now have a total balance of 200 units of Token A, the mapping would show that the Token A/Token B pool and the Token A/Token C pool both have only 100 units.
    8

    After locking the native tokens, the Standard Bridge contract on the sending side will trigger a cross-chain message to the Standard Bridge contract on the receiving side via the CrossDomainMessenger system. This message tells the receiving side to mint tokens according to the parameters specified by the user. Specifically, this message is an encoded call to the finalizeBridgeERC20 function on the other Standard Bridge contract. At this point, execution ends on the sending side.
    9

    Once the minting message is sent, it must be relayed to the receiving side. Message relaying is automatic when sending from Ethereum to Adventure Layer Testnet but requires additional user transactions when sending from Adventure Layer Testnet to Ethereum. Read more about the message relaying process in the guide to Sending Data Between L1 and L2.
    10

    When the message is relayed, the finalizeBridgeERC20 function will be triggered on the receiving Standard Bridge contract. This function will receive the _minGasLimit gas defined by the user to execute to completion.
    11

    Upon execution, finalizeBridgeERC20 verifies a number of things about the incoming request:
    12

    13

    If the minting message is fully verified, finalizeBridgeERC20 will mint tokens to the recipient equal to the number of tokens originally deposited on the other blockchain. For this to work properly, the bridged representation of the native token must correctly implement a mint function that allows the Standard Bridge to mint tokens arbitrarily. This is part of the IOptimismMintableERC20 interface.
    14

    This completes the process of bridging native tokens. This process is identical in both the Ethereum to Adventure Layer Testnet and Adventure Layer Testnet to Ethereum directions.

    ​
    Bridging Non-Native Tokens

    The Standard Bridge uses a “burn-and-unlock” mechanism to convert bridged representations of tokens back into their native tokens. This means that bridged tokens are burned on the Standard Bridge on one side, after which native tokens are unlocked on the other side. The process for bridging a non-native, bridged representation of a token involves a few steps.

    1

    Unlike when bridging native tokens, users do not need to provide an approval to trigger a transfer of a bridged token because the Standard Bridge should already have the ability to burn these tokens. Here, the user calls the bridgeERC20To function on the StandardBridge contract on the chain where the bridged token lives (e.g., the L2StandardBridge contract if the token is bridged to Adventure Layer Testnet).
    2

    The user must provide the following parameters to this function call:
    3

  • address _localToken: Address of the bridged token on the sending side.
  • address _remoteToken: Address of the native token on the receiving side.
  • address _to: Address of the recipient of these tokens, usually the sender’s address.
  • uint256 _amount: Number of tokens to transfer.
  • uint32 _minGasLimit: Gas to use to complete the transfer on the receiving side.
  • bytes calldata _extraData: Optional identify extra data.
    • 4

    When the user triggers the bridgeERC20To function while transferring a bridge token, the Standard Bridge will burn the corresponding _amount of tokens from the sender’s address.
    5

    After burning the bridged tokens, the Standard Bridge contract on the sending side will trigger a cross-chain message to the Standard Bridge contract on the receiving side via the CrossDomainMessenger system. This message tells the receiving side to unlock tokens according to the parameters specified by the user. Specifically, this message is an encoded call to the finalizeBridgeERC20 function on the other Standard Bridge contract. At this point, execution ends on the sending side.
    6

    Once the unlock message is sent, it must be relayed to the receiving side. Message relaying is automatic when sending from Ethereum to Adventure Layer Testnet but requires additional user transactions when sending from Adventure Layer Testnet to Ethereum. Read more about the message relaying process in the guide to Sending Data Between L1 and L2.
    7

    When the message is relayed, the finalizeBridgeERC20 function will be triggered on the receiving Standard Bridge contract. This function will receive the _minGasLimit gas defined by the user to execute to completion.
    8

    Upon execution, finalizeBridgeERC20 verifies a number of things about the incoming request:
    9

    10

    If the unlock message is fully verified, finalizeBridgeERC20 will unlock and transfer tokens to the recipient equal to the number of tokens originally burned on the other blockchain.
    11

    This completes the process of bridging native tokens. This process is identical in both the Ethereum to Adventure Layer Testnet and Adventure Layer Testnet to Ethereum directions.

    ​
    Bridging ETH

    The Standard Bridge contracts can also be used to bridge ETH from Ethereum to Adventure Layer Testnet and vice versa. The ETH bridging process is generally less complex than the ERC-20 bridging process. Users simply need to trigger and send ETH to the bridgeETH or bridgeETHTo functions on either blockchain.

    ​
    Tutorials

    ​
    Superchain Token List

    The Superchain Token List exists to help users discover the right bridged token addresses for any given native token. Consider checking this list to make sure that you’re not using the wrong bridged representation of a token when bridging a native token.

    Developers who are creating their own bridged tokens should consider adding their token to the Superchain Token List. Tokens on the Superchain Token List will automatically appear on certain tools like the Adventure Layer Bridge UI.

    ​
    Searching the Token List

    You should strongly consider using the Superchain Token List to verify that you’re using the correct bridged representation of a token when bridging a native token. Doing so can help you avoid accidentally bridging to the wrong token and locking up your native token permanently.

    You can easily find the bridged representation of a token for Adventure Layer Testnet on the Bridged Token Addresses page. If you want to find the bridged representation of a token for another chain, use the following steps.

    1

    The Superchain Token List is organized by the token’s address and native blockchain. Search the token list for the token you want to bridge to confirm that it’s included in the list. Make sure that the chain ID in the entry matches the chain ID of the blockchain you’re bridging from. Retrieve the token’s name and symbol from the list.
    2

    Once you’ve found the token you want to bridge, look for the token’s name and symbol in the list. Find the entry that matches the name and symbol of the token you want to bridge and where the chain ID matches the chain ID of the blockchain you’re bridging to. The address of this entry is the address of the bridged representation of the token you want to bridge.

    ​
    Special Considerations

    ​
    USDC

    Circle, the issuer of USDC, natively issues USDC on Adventure Layer Testnet as of September 2023. Before this service was made available, USDC had to be bridged to Adventure Layer Testnet via the Standard Bridge. This bridged representation of USDC is referred to as USDC.e.

    Circle recommends that users and developers make use of the native version of USDC issued by Circle over the bridged USDC.e token. Please note that the bridged USDC.e token will be deprecated in the near future.

    Information about the bridged USDC.e token and native USDC token can be found below.

    SymbolDescriptionAddress
    USDC.eBridged USDC from Ethereum0x7f5c764cbc14f9669b88837ca1490cca17c31607
    USDCNative USDC issued by Circle0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85

    Was this page helpful?