Scroll SDK Contracts

Overview

Contracts deployed for a Scroll SDK chain include both contracts on the L1 (or basechain), and contracts deployed on the L2 (or SDK chain). Additionally, the L2 has “pre-deployed” contracts, matching those on Scroll.

Primary Contracts

Although there are many contracts deployed during a new chain deployment, the most important contracts to understand are below.

Rollup Contract

• Deployed to L1 using a proxy and also called “Scroll Chain”
• Accepts new batches and proofs posted by the rollup-relayer service by calling “Commit Batch” and “Finalize Batch” methods.
• Keeps track of finalized State Roots and Withdraw Roots.
• View on Etherscan | View Source

Scroll Message Queues

• Deployed to L1 with a proxy and pre-deployed to L2
• On L1, every depost to the bridge is added as a message to the L1 message queue.
  • Messages are read by l2geth instances, including the sequencer, and brought into the Scroll chain via L1Message transaction types.
• On L2, every withdrawal sent through the bridge is added as a message, and each block’s resulting withdraw root is made available after finalization on the L1 Rollup Contract.
  • At any time, a user can permissionlessly generate proof to finish relaying the message on L1.
• Messages are added to the queues exclusively by the Messenger contracts on L1 and L2.
• View L1 Deployment on Etherscan | View Source
• View L2 Deployment on Scrollscan | View Source

Gas Oracle Contracts

• Deployed on L1 (as part of L1 Message Queue) and pre-deployed on L2
• On L1, it tracks the gas fees on L2. This is needed since L1 transactions need to pay for their L2 gas upfront.
  • Stored l2BaseFee can only be updated by whitelisted addresses, TODO: is this done by gas-oracle on L1 and L2?
• On L2, the contract keeps track of the fees on L1, allowing other contracts to know how the cost required to send a transaction back to L1
  • Stored l1BaseFee can only be updated by whitelisted addresses, TODO: is this done by gas-oracle on L1 and L2?
• View L1 Deployment on Etherscan | View Source
• View L2 Deployment on Scrollscan | View Source

Deployment Process

Contracts are deployed by the contracts chart. Deterministic addresses are used, with a salt used to generate the address of the contract. For every new deployment, a unique salt should be configured in config.toml.

During the configuration generation step, a simulation is first done to determine what address a contract will deploy to. This step is done during the creation of the config files for each service’s chart and when the genesis.json file is created. Contract addresses are then used to set each service’s configuration (see gen-configs.sh).

Then, before the contracts chart is installed, you will need to fund your SDK DEPLOYER account to deploy all contracts on L1 and L2 using actual transactions.

The contracts pod will connect to the L2 RPC and deploy the necessary contracts from the DEPLOYER account.

Funding Deployment Accounts

In production deployments, you will need to manually fund the following wallet addresses from config.toml:

• DEPLOYER_ADDR (only needs funded on L1)
• L1_COMMIT_SENDER_ADDR
• L1_FINALIZE_SENDER_ADDR
• L1_GAS_ORACLE_SENDER_ADDR
• L2_GAS_ORACLE_SENDER_ADDR (funded after L2 chain deployment)

Contracts Deployed

In the table below, we document every contract deployed for Scroll, including a link to the deployment for Scroll’s mainnet. Not all of these are used by default for Scroll SDK.