Search for projects by name
Scroll is ZK Rollup that extends Ethereum’s capabilities through ZK tech and EVM compatibility.
Scroll is ZK Rollup that extends Ethereum’s capabilities through ZK tech and EVM compatibility.
The project will move to Stage 0 because:
2024 May 02 — 2025 May 02
2024 May 03 — 2025 May 02
The section shows the operating costs that L2s pay to Ethereum.
2024 May 03 — 2025 May 02
Scroll Euclid upgrade
2025 Apr 24th
Scroll becomes Stage 1 by improving permissions and introducing enforced batch mode.
SNARKs are zero knowledge proofs that ensure state correctness, but require trusted setup.
All of the data needed for proof construction is published on Ethereum L1.
There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
New requirements coming soon
All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.
Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.
Scroll circuits are openvm based Guest Programs based on the Halo2 proof system. The source code of the base circuits can be found here.
SNARK verification keys can be generated and checked against Ethereum verifier contract using this guide. The system requires a trusted setup.
Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.
While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. The enforced liveness mechanism is activated if either an L1 message has not been finalized for more than 7d or a batch has not been finalized for more than 7d. When activated, transactions that were directly posted to the smart contract can be forcefully included by anyone on the host chain, which finalizes their ordering.
All core contracts in the Scroll protocol are upgradable by the ProxyAdmin
, which is controlled by the Security Council through the ScrollOwner
contract. The ScrollOwner is a central governance contract controlled by four distinct Timelocks: two governed by the Security Council multisig and two by the Scroll team multisigs. Each multisig can initiate specific types of changes with differing delay guarantees. The team can change parameters that affect L1->L2 messaging and the activation of permissionless sequencing (i.e., enforcedBatchMode), such as by calling the updateMessageQueueParameters
and updateEnforcedBatchParameters
functions through the TimelockFast
, or by pausing the EnforcedTXGateway
through the TimelockEmergency
. It also has authority to revert unfinalized batches and add or remove sequencers and provers while sequencing is in permissioned mode. As the ScrollOwner admin, the Security Council can revert the team actions by revoking the team roles in the ScrollOwner contract (through the TimelockSCSlow
) and upgrading the affected contracts. SCR token holders perform onchain voting on governance proposal through the AgoraGovernor
contract on L2. However, upgrades are not triggered automatically, the Security Council is in charge of executing upgrades.
Contract used to update the verifier and keep track of current and old versions.
Contract used to send L1 -> L2 and relay messages from L2. It allows to replay failed messages and to drop skipped messages. L1 -> L2 messages sent using this contract pay for L2 gas on L1 and will have the aliased address of this contract as the sender. This contract stores the following tokens: ETH.
System configuration contract for Scroll, contains enforcedBatchParameters and messageQueueParameters determining permissionless mode.
The main contract of the Scroll chain. Allows to post transaction data and state roots, along with proofs. Sequencing and proposing are behind a whitelist unless enforcedBatchMode is activated.
Main entry point for depositing ETH and ERC20 tokens, which are then forwarded to the correct gateway.
This contract stores the following tokens: wstETH.
This contract stores the following tokens: DAI.
Contract used to verify zk proofs given the aggregate proof and the public input hash.
Can be used to upgrade implementation of L1MessageQueueV2, L1ERC721Gateway, DaiEscrow, L1ScrollMessenger, EnforcedTxGateway, L1WETHGateway, L1ETHGateway, SystemConfig, ScrollChain, L1CustomERC20Gateway, L1ERC1155Gateway, L1StandardERC20Gateway, L1USDCGateway, L1GatewayRouter.
Used to propose and manage onchain governance proposals.
Contract of the USDC token on Scroll.
Counterpart to the L1GatewayRouter contract.
Used to append messages to the L2MessageQueue from the L2ScrollMessenger.
Counterpart to the L1ERC1155Gateway contract.
Counterpart to the L1CustomERC20Gateway contract.
Contract used to deploy ScrollStandardERC20 tokens for L2StandardERC20Gateway.
Contract of the L2ScrollMessenger contract.
ETH is pre-minted to this contract in the genesis block and released on Scroll whenever corresponding deposits are made on Ethereum.
Counterpart to the L1ERC721Gateway contract.
Can be used to upgrade implementation of AgoraGovernor.
Can be used to upgrade implementation of Scroll USDC, L2GatewayRouter, L2ERC1155Gateway, L2CustomERC20Gateway, L2ETHGateway, L2ScrollMessenger, L2ERC721Gateway, L2GatewayRouter.
Manager contract for minter management [sic].
Contract of the ERC20 standard token used by the ERC20 factory.
Can be used to upgrade implementation of SCRToken.
Custom token escrow with third-party governance, using the canonical bridge only for messaging.
Custom token escrow with third-party governance, using the canonical bridge only for messaging.
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).