StarkGate bridge overview

StarkGate, developed by StarkWare, bridges ETH and ERC-20 tokens between Ethereum and Starknet. Each supported token is associated with an L1 and L2 bridge contract that communicates via Starknet’s messaging mechanism.

To use StarkGate, go to https://starkgate.starknet.io.

A bridge enables you to fund your L2 wallet with ETH and ERC-20 tokens that reside on L1.

The terms deposit, transact, and transfer refer to various operations involving a bridge, even though ETH and ERC-20 tokens never actually leave Ethereum.

StarkGate 2.0 provides a contract that enables seamless backward compatibility with the previous version of StarkGate.

When you update the code in your contract, make sure that you use the most up-to-date versions of all StarkGate contracts.

Supported tokens in StarkGate

StarkGate supports many tokens, including ETH, WBTC, USDC, DAI, and many more.

For a comprehensive list of tokens that StarkGate supports, see the JSON files in the Starknet GitHub repository shown in the table StarkGate bridged tokens.

Table 1. StarkGate bridged tokens
Network StarkGate bridged tokens JSON file

Mainnet

mainnet.json

Sepolia testnet

sepolia.json

Goerli testnet (deprecated)

goerli.json

Previously, StarkGate placed limitations for each supported token on the amount that could be deposited and the total value locked in the L1 bridge contract on Mainnet. These limits have been removed.

L1→L2 transfer (deposit)

Step 1: Call the deposit function on L1

  1. A call to the L1 deposit function initiates a deposit.

  2. The function does the following:

    • Transfers the funds from the user’s account to the Starknet bridge.

    • Emits a Deposit event that includes the L1 and L2 addresses of the user, and the amount deposited.

    • Sends a message to the corresponding L2 bridge with the amount deposited, and the recipient’s address.

    Starknet’s sequencer is now aware of the deposit transaction.

  3. The sequencer waits for enough L1 block confirmations to fill its quota to run before the corresponding deposit transaction is initiated on L2. During this period of time, the status of the L2 deposit transaction is NOT_RECEIVED.

Step 2: Deposit triggered on Starknet

  1. The sequencers refer to the deposit request by triggering the L1 handler using the handle_deposit function on the L2 bridge.

  2. The handle_deposit function verifies that the deposit indeed came from the corresponding L1 bridge. It then calls the relevant token’s contract on Starknet and mints the specified amount of the token on L2 for the user.

  3. The sequencers complete constructing the block.

The status of the deposit request is now ACCEPTED_ON_L2.

Step 3: The block that includes the transfer is proved

  1. Starknet’s provers prove the validity of the block and submit a state update to L1.

  2. The message confirming transfer of the funds is cleared from the Starknet Core Contract, and the fact that the user has transferred their funds is part of the now finalized state of Starknet.

If the message wasn’t on L1 to begin with, that is, if the deposit request was fraudulently created on Starknet, the state update would fail.

L2→L1 transfer (withdrawal)

Step 1: Initiate a withdrawal from L2

  1. A call to the L2 initiate_withdraw function initiates a withdrawal.

  2. The function does the following:

    • Burns the transferred amount of tokens from the balance of the withdrawal’s initiator.

    • Sends a message to the relevant L1 bridge with the amount to be transferred and the recipient’s address.

Step 2: Proving the block that includes the withdrawal transaction

  1. The sequencer completes the block construction

  2. Starknet’s provers prove the validity of the block and submit a state update to L1.

  3. The message from the previous step is stored in the Starknet Core Contract.

Step 3: Transferring the funds on L1

After the withdrawal message has been recorded on the Starknet Core Contract, anyone can finalize the transfer on L1 from the bridge back to the user, by calling the withdraw function.

This step is permissionless, anyone can do it. The recipient’s address is part of the recorded message on L1, so they receive the funds regardless of who calls the withdraw function on L1.

Additional resources