Search for projects by name or address
Morph is an EVM compatible rollup. It operates as an optimistic rollup with ZK fault proofs and has plans for decentralizing the Sequencer. Their mission is to build the first blockchain for consumers, where user-friendly applications integrate seamlessly... into everyday life, becoming indispensable utilities.
Morph is an EVM compatible rollup. It operates as an optimistic rollup with ZK fault proofs and has plans for decentralizing the Sequencer. Their mission is to build the first blockchain for consumers, where user-friendly applications integrate seamlessly... into everyday life, becoming indispensable utilities.
This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data to; previously it posted to
Ethereum.
Fully centralized sequencing
2026 Sep 22nd
Only submitters staked in the new Submitter contract can commit batches. BLS input removed.
commitBatch()commitBatch()Users can force the sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. to include a transaction by submitting a request through L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. If the sequencer censors or is down for 7d, new L1 batches must include at least 1 transaction from the queue.
Fraud proofs allow actors watching the chain to prove that the state is incorrect. Single round proofs (1R) only require a single transaction to resolve. ZK proofs are used to prove the correctness of the state transition. The system currently operates with at least 5 whitelisted challengers external to the team.
All of the data needed for proof construction is published on Ethereum L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development..
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
Anyone can become a ProposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. after 7d of inactivity from the currently whitelisted Proposers. This requires using the source-available proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. to submit a zk proof of validity for the proposal.
All the data that is used to construct the system state is published on chain in the form of cheap blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. or calldata. This ensures that it will be available for enough time.
Morph uses a one round fault proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. where whitelisted Challengers, if they find a faulty state rootA cryptographic hash succinctly representing a state using a Merkle tree. within the 2d challenge window, can post a 1 WEI bond and request a ZK proof of the state transition. At least 5 Challengers are operated by entities external to the team. After the challenge, during a 3d proving window, a ZK proof must be delivered, otherwise the state root is considered invalid and the submitter’s whole stake in the Submitter contract (at least 1 ETH) is slashed, with 30% of it forwarded as challenger reward and the rest accruing to the Submitter owner. The zkVMA special type of zk proving system that proves the correctness of state transitions of a virtual machine. Computation is represented by a program in a specific instruction language, it can have private and public inputs and public outputs. Most of zkVMs are STARKs. used is SP1 by Succinct. If a valid proof is delivered, the Challenger loses the challenge bond. The Morph Multisig can revert unfinalized batches.
Funds can be stolen if no whitelisted challenger posts a challenge for an incorrect state root.
Onchain verifier
Onchain verifier |
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
Rollup upgrade https://disco.l2beat.com/diff/eth:0xaC3C379D772f3520B34690d32BA14510ab36C3fB/eth:0x213CE22b487B71Ac68a1B5b12d2b93D1AF30Ea1d: batch commitment, state proposal and slashing are now authorized through a new staked Submitter contract (owned by Morph Multisig) instead of L1Staking. The never-verified BLS signature input was removed. A new SP1 verifier was registered with a new program vkey (Morph v0.6.3 guest program, reproduced from source).
Rollup upgrade https://disco.l2beat.com/diff/eth:0xaC3C379D772f3520B34690d32BA14510ab36C3fB/eth:0x213CE22b487B71Ac68a1B5b12d2b93D1AF30Ea1d: batch commitment, state proposal and slashing are now authorized through a new staked Submitter contract (owned by Morph Multisig) instead of L1Staking. The never-verified BLS signature input was removed.
A new SP1 verifier was registered with a new program vkey (Morph v0.6.3 guest program, reproduced from source).
| contract ProxyAdmin (eth:0x31110622D6CA24c9FF307d6ae1715F16E47F16A0) [global/ProxyAdmin] { | |
| +++ description: None | |
| directlyReceivedPermissions.11: | |
| + | {"permission":"upgrade","from":"eth:0xf2d50000C994565A4742059802fdbb0BEE1CBef6","role":"admin"} |
| } | |
| EOA (eth:0x34E387B37d3ADEAa6D5B92cE30dE3af3DCa39796) { | |
| +++ description: None | |
| receivedPermissions.1: | |
| + | {"permission":"interact","from":"eth:0xf2d50000C994565A4742059802fdbb0BEE1CBef6","description":"Actors allowed to commit transaction batches and propose and prove state roots while staked at or above the minimum.","role":".submitters"} |
| } | |
| contract MultipleVersionRollupVerifier (eth:0x5d1584c27b4aD233283c6da1ca1B825d6f220EC1) [morph/MultipleVersionRollupVerifier] { | |
| +++ description: Used to update the verifier and keep track of current and old versions. Routes to a registered verifier by batch index, so that every batch is verified by the latest verifier that is enabled for this batch. | |
| values.latestVerifier.1.verifier: | |
| - | "eth:0xD9F24400816c4CC1a3cBb9B851C9B0bAB63Ad692" |
| + | "eth:0x651cA600813fC0126225b727EDbA617949b1d1c9" |
| values.latestVerifier.1.startBatchIndex: | |
| - | 54332 |
| + | 60478 |
| } | |
| EOA (eth:0x6aB0E960911b50f6d14f249782ac12EC3E7584A0) { | |
| +++ description: None | |
| receivedPermissions.1: | |
| + | {"permission":"interact","from":"eth:0xf2d50000C994565A4742059802fdbb0BEE1CBef6","description":"Actors allowed to commit transaction batches and propose and prove state roots while staked at or above the minimum.","role":".submitters"} |
| } | |
| contract Rollup (eth:0x759894Ced0e6af42c26668076Ffa84d02E3CeF60) [morph/Rollup] { | |
| +++ description: The main contract of the Morph rollup. Allows to post transaction data and state roots and implements the proof system. Sequencing and proposing are permissioned to the active submitters registered and staked in the Submitter contract. If the EnforcedTxGateway is not paused, any submitter must include at least one L1 -> L2 message in their proposal if the oldest message is > 7d old. If the submitters are censoring or down for more than 7d, users can permissionlessly propose and prove via `commitBatchWithProof()`. | |
| sourceHashes.1: | |
| - | "0x9505004977004cf77ebe02c63bae0f3420673028462e69fe68350d91356eb33b" |
| + | "0xf24c39e5b0d3851769ddbafcad7ce6770f9aac6e89c6b220c902ab07d97ab225" |
| values.$implementation: | |
| - | "eth:0xaC3C379D772f3520B34690d32BA14510ab36C3fB" |
| + | "eth:0x213CE22b487B71Ac68a1B5b12d2b93D1AF30Ea1d" |
| values.$pastUpgrades.11: | |
| + | ["2026-09-22T07:54:35.000Z","0xdeb5268cbec1b47c77ad46cb8dd29491833e45ae374d2905f94f4e0499e8110e",["eth:0x213CE22b487B71Ac68a1B5b12d2b93D1AF30Ea1d"]] |
| values.$upgradeCount: | |
| - | 11 |
| + | 12 |
| values.l1StakingContract: | |
| - | "eth:0x0Dc417F8AF88388737c5053FF73f345f080543F7" |
| +++ description: Batch index at which the Rollup switched batch-submission authorization to the Submitter contract; batches above it are attributed to a single submitter account. | |
| values.legacyCutoverBatchIndex: | |
| + | 60477 |
| +++ severity: HIGH | |
| values.submitterContract: | |
| + | "eth:0xf2d50000C994565A4742059802fdbb0BEE1CBef6" |
| implementationNames.eth:0xaC3C379D772f3520B34690d32BA14510ab36C3fB: | |
| - | "Rollup" |
| implementationNames.eth:0x213CE22b487B71Ac68a1B5b12d2b93D1AF30Ea1d: | |
| + | "Rollup" |
| } | |
| EOA (eth:0xBBA36CdF020788f0D08D5688c0Bee3fb30ce1C80) { | |
| +++ description: None | |
| receivedPermissions.1: | |
| + | {"permission":"interact","from":"eth:0xf2d50000C994565A4742059802fdbb0BEE1CBef6","description":"Actors allowed to commit transaction batches and propose and prove state roots while staked at or above the minimum.","role":".submitters"} |
| } | |
| - | Status: DELETED |
| contract ZkEvmVerifierV1 (eth:0xD9F24400816c4CC1a3cBb9B851C9B0bAB63Ad692) [morph/ZkEvmVerifierV1] | |
| +++ description: A snark verifier based on SP1 by Succinct. It verifies RISC-V execution in a PLONK proof. Used to verify the validity of L2 state transitions for single round fraud proofs. | |
| contract Morph Multisig 1 (eth:0xF101f7f59A348c1F971A2BC64fdBdA58c7bBD887) [GnosisSafe] { | |
| +++ description: None | |
| receivedPermissions.7: | |
| + | {"permission":"interact","from":"eth:0xf2d50000C994565A4742059802fdbb0BEE1CBef6","description":"add and remove submitters (batch committers/proposers), set the minimum stake, the challenge deposit and the slashing reward share, and withdraw the non-rewarded remainder of slashed stakes.","role":".owner"} |
| receivedPermissions.20: | |
| + | {"permission":"upgrade","from":"eth:0xf2d50000C994565A4742059802fdbb0BEE1CBef6","role":"admin","via":[{"address":"eth:0x31110622D6CA24c9FF307d6ae1715F16E47F16A0"},{"address":"eth:0x542675E90E269F20ecbb9e0095d4751ac155B530"}]} |
| } | |
| + | Status: CREATED |
| contract ZkEvmVerifierV1 (eth:0x651cA600813fC0126225b727EDbA617949b1d1c9) [morph/ZkEvmVerifierV1] | |
| +++ description: A snark verifier based on SP1 by Succinct. It verifies RISC-V execution in a PLONK proof. Used to verify the validity of L2 state transitions for single round fraud proofs. | |
| + | Status: CREATED |
| contract Submitter (eth:0xf2d50000C994565A4742059802fdbb0BEE1CBef6) [morph/Submitter] | |
| +++ description: Registry and ETH staking contract for the accounts allowed to commit transaction batches and propose state roots to the Rollup. The owner whitelists submitters, who are active only while registered, not withdrawing and staked at or above the minimum. When a submitter's batch is successfully challenged, the Rollup slashes the submitter's whole stake through this contract: the configured reward share is forwarded to the Rollup for the challenger and the remainder accrues to the owner. Stake withdrawals are claimable only once the batch committed at withdrawal time is finalized. | |
critical contracts and severities for the ossification perimeter
critical contracts and severities for the ossification perimeter
| + | Status: CREATED |
| contract L1USDCGateway (eth:0x2C8314f5AADa5D7a9D32eeFebFc43aCCAbe1b289) [morph/L1USDCGateway] | |
| +++ description: Contract used to bridge USDC tokens from L1 to L2. | |
| + | Status: CREATED |
| contract L1CustomERC20Gateway (eth:0xA534BAdd09b4C62B7B1C32C41dF310AA17b52ef1) [morph/L1CustomERC20Gateway] | |
| +++ description: Contract used to bridge ERC20 tokens with custom L2 representations from L1 to L2. It allows to change the token mappings. | |
| + | Status: CREATED |
| contract L1USDCGatewayLegacy (eth:0xc9045350712A1DCC3A74Eca18Bc985424Bbe7535) [morph/L1USDCGateway] | |
| +++ description: Contract used to bridge USDC tokens from L1 to L2. | |
Ownership of MultipleVersionRollupVerifier, L1GatewayRouter and Rollup moved from Morph Multisig 2 (3 of 5) to Morph Multisig 1 (4 of 6), taking the verifier-registration, escrow-mapping and pause/revert permissions with it. Morph Multisig 2: member rotated.
Ownership of MultipleVersionRollupVerifier, L1GatewayRouter and Rollup moved from Morph Multisig 2 (3 of 5) to Morph Multisig 1 (4 of 6), taking the verifier-registration, escrow-mapping and pause/revert permissions with it. Morph Multisig 2: member rotated.
| contract MultipleVersionRollupVerifier (eth:0x5d1584c27b4aD233283c6da1ca1B825d6f220EC1) [morph/MultipleVersionRollupVerifier] { | |
| +++ description: Used to update the verifier and keep track of current and old versions. Routes to a registered verifier by batch index, so that every batch is verified by the latest verifier that is enabled for this batch. | |
| values.owner: | |
| - | "eth:0xB822319ab7848b7cC4537c8409e50f85BFb04377" |
| + | "eth:0xF101f7f59A348c1F971A2BC64fdBdA58c7bBD887" |
| } | |
| contract L1GatewayRouter (eth:0x7497756ADA7e656aE9f00781aF49Fc0fD08f8A8a) [morph/L1GatewayRouter] { | |
| +++ description: Main entrypoint for depositing ETH and ERC20 tokens, which are then forwarded to the correct escrow. | |
| values.owner: | |
| - | "eth:0xB822319ab7848b7cC4537c8409e50f85BFb04377" |
| + | "eth:0xF101f7f59A348c1F971A2BC64fdBdA58c7bBD887" |
| } | |
| contract Rollup (eth:0x759894Ced0e6af42c26668076Ffa84d02E3CeF60) [morph/Rollup] { | |
| +++ description: The main contract of the Morph rollup. Allows to post transaction data and state roots and implements the the proof system. Sequencing and proposing are behind a whitelist. If the EnforcedTxGateway is not paused, any sequencer must include at least one L1 -> L2 message in their proposal if the oldest message is > 7d old. If the Sequencers are censoring or down for more than 7d, users can permissionlessly propose and prove via `commitBatchWithProof()`. | |
| values.owner: | |
| - | "eth:0xB822319ab7848b7cC4537c8409e50f85BFb04377" |
| + | "eth:0xF101f7f59A348c1F971A2BC64fdBdA58c7bBD887" |
| } | |
| contract Morph Multisig 2 (eth:0xB822319ab7848b7cC4537c8409e50f85BFb04377) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.4: | |
| - | "eth:0xcE7257224441385345CE6eEdd9D8667AD9Bab9f0" |
| + | "eth:0xA52Bb0BEBfadEDA9DfFFa3Ba5eBFE86d9f6dB321" |
| receivedPermissions.3: | |
| - | {"permission":"interact","from":"eth:0x5d1584c27b4aD233283c6da1ca1B825d6f220EC1","description":"register new verifiers to be used starting from a given L2 batch index.","role":".owner"} |
| receivedPermissions.4: | |
| - | {"permission":"interact","from":"eth:0x7497756ADA7e656aE9f00781aF49Fc0fD08f8A8a","description":"manage token to escrow mapping and (un-)register escrows.","role":".owner"} |
| receivedPermissions.6: | |
| - | {"permission":"interact","from":"eth:0x759894Ced0e6af42c26668076Ffa84d02E3CeF60","description":"can pause and unpause, revert unfinalized batches, update proof window and finalization period, manage challengers, modify the verifier address.","role":".owner"} |
| } | |
| contract Morph Multisig 1 (eth:0xF101f7f59A348c1F971A2BC64fdBdA58c7bBD887) [GnosisSafe] { | |
| +++ description: None | |
| receivedPermissions.3: | |
| + | {"permission":"interact","from":"eth:0x5d1584c27b4aD233283c6da1ca1B825d6f220EC1","description":"register new verifiers to be used starting from a given L2 batch index.","role":".owner"} |
| receivedPermissions.4: | |
| + | {"permission":"interact","from":"eth:0x7497756ADA7e656aE9f00781aF49Fc0fD08f8A8a","description":"manage token to escrow mapping and (un-)register escrows.","role":".owner"} |
| receivedPermissions.5: | |
| + | {"permission":"interact","from":"eth:0x759894Ced0e6af42c26668076Ffa84d02E3CeF60","description":"can pause and unpause, revert unfinalized batches, update proof window and finalization period, manage challengers, modify the verifier address.","role":".owner"} |
| } | |
Owner switched to second Morph multisig. L1CDM owner can set rollup reference and change fee / critical configs.
Owner switched to second Morph multisig. L1CDM owner can set rollup reference and change fee / critical configs.
| contract L1CrossDomainMessenger (eth:0xDc71366EFFA760804DCFC3EDF87fa2A6f1623304) [morph/L1CrossDomainMessenger] { | |
| +++ description: 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. | |
| values.owner: | |
| - | "eth:0xB822319ab7848b7cC4537c8409e50f85BFb04377" |
| + | "eth:0xF101f7f59A348c1F971A2BC64fdBdA58c7bBD887" |
| } | |
Added batch data version 2: https://disco.l2beat.com/diff/eth:0x9e2Fb684935a32CEd121972f23BD0e4634377cA2/eth:0xaC3C379D772f3520B34690d32BA14510ab36C3fB, which handles submitting several blobs. Also, upgraded the verifier program, which is reproducible from the sources, and completely switched to SP1 Hypercube.
Added batch data version 2: https://disco.l2beat.com/diff/eth:0x9e2Fb684935a32CEd121972f23BD0e4634377cA2/eth:0xaC3C379D772f3520B34690d32BA14510ab36C3fB, which handles submitting several blobs.
Also, upgraded the verifier program, which is reproducible from the sources, and completely switched to SP1 Hypercube.
| - | Status: DELETED |
| contract ZkEvmVerifierV1 (eth:0x045d4BC73Bd1918192f34e98532A5272Ef620423) [morph/ZkEvmVerifierV1] | |
| +++ description: A snark verifier based on SP1 by Succinct. It verifies RISC-V execution in a PLONK proof. Used to verify the validity of L2 state transitions for single round fraud proofs. | |
| contract MultipleVersionRollupVerifier (eth:0x5d1584c27b4aD233283c6da1ca1B825d6f220EC1) [morph/MultipleVersionRollupVerifier] { | |
| +++ description: Used to update the verifier and keep track of current and old versions. Routes to a registered verifier by batch index, so that every batch is verified by the latest verifier that is enabled for this batch. | |
| values.latestVerifier.1.verifier: | |
| - | "eth:0x045d4BC73Bd1918192f34e98532A5272Ef620423" |
| + | "eth:0xD9F24400816c4CC1a3cBb9B851C9B0bAB63Ad692" |
| values.latestVerifier.1.startBatchIndex: | |
| - | 45847 |
| + | 54332 |
| } | |
| contract Rollup (eth:0x759894Ced0e6af42c26668076Ffa84d02E3CeF60) [morph/Rollup] { | |
| +++ description: The main contract of the Morph rollup. Allows to post transaction data and state roots and implements the the proof system. Sequencing and proposing are behind a whitelist. If the EnforcedTxGateway is not paused, any sequencer must include at least one L1 -> L2 message in their proposal if the oldest message is > 7d old. If the Sequencers are censoring or down for more than 7d, users can permissionlessly propose and prove via `commitBatchWithProof()`. | |
| sourceHashes.1: | |
| - | "0x744e3febdbddacbc25d9934fa259bfb08b24e38cb1325cdce9e9740b9b6f192b" |
| + | "0x9505004977004cf77ebe02c63bae0f3420673028462e69fe68350d91356eb33b" |
| values.$implementation: | |
| - | "eth:0x9e2Fb684935a32CEd121972f23BD0e4634377cA2" |
| + | "eth:0xaC3C379D772f3520B34690d32BA14510ab36C3fB" |
| values.$pastUpgrades.10: | |
| + | ["2026-06-03T11:26:11.000Z","0xe9128be913e8685a928c8e8468a030a95ad44ef4ad78534c688cd721af496a54",["eth:0xaC3C379D772f3520B34690d32BA14510ab36C3fB"]] |
| values.$upgradeCount: | |
| - | 10 |
| + | 11 |
| implementationNames.eth:0x9e2Fb684935a32CEd121972f23BD0e4634377cA2: | |
| - | "Rollup" |
| implementationNames.eth:0xaC3C379D772f3520B34690d32BA14510ab36C3fB: | |
| + | "Rollup" |
| } | |
| + | Status: CREATED |
| contract ZkEvmVerifierV1 (eth:0xD9F24400816c4CC1a3cBb9B851C9B0bAB63Ad692) [N/A] | |
| +++ description: None | |
Batches and state rootsA cryptographic hash succinctly representing a state using a Merkle tree. can only be committed to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. by submitters whitelisted by the Morph multisig in the Submitter contract, each staking at least 1 ETH. No sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. signatures are verified onchain, and the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.-producing sequencer set is managed separately through the L1Staking contract. Sequencing is centralized and permissioned to the listed submitters in practice.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can force the sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. to include a transaction by submitting a request through L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. If the sequencer censors such a request or is down for 7d, any new proposal must include at least 1 transaction from the queue. Proposing is permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. under these conditions if proven immediately.
The user initiates L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. messages by submitting a regular transaction on this chain. When the blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization takes a challenge periodIn optimistic rollups, the window of time wherein network participants can assert that some fraud was included in a prior block. Most optimistic rollups currently specify a challenge window of 7 days. By extending the period, there is more time for participants to guard against fraud (invalid state transitions), but also more time until withdrawals gets enabled. of 2d to complete.

Staking registry of the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. set. It relays staker additions and removals to the L2 Staking contract through the messenger, which determines the L2 blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.-producing sequencer set. The RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. does not reference it: L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. batch submission and slashing are authorized through the Submitter contract, so the stake, challenge-deposit and reward parameters here are not enforced by the Rollup.
A Multisig with 3/5 threshold.
A Multisig with 4/6 threshold.


Contract used to bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. ETH from L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups..
Contract used to bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. USDC tokens from L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups..
Contains the array of queued L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. -> L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. messages, either appended using the L1Messenger or the EnforcedTxGateway.
Contract used to bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. ERC20 tokens from L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.. It uses a fixed token list.
A timelock with access control. The current minimum delay is 0s.
Used to update the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. and keep track of current and old versions. Routes to a registered verifier by batch index, so that every batch is verified by the latest verifier that is enabled for this batch.
A snarkShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. based on SP1 by Succinct. It verifies RISC-VA free and open-source instruction set architecure (ISA) used in hardware and software. It is simple and well specified, for this reason it is chosen as an ISA for several zkVMs (usually 32-bit version with base integer instructions and multiplication extension RV32IM). execution in a PLONKA zk-SNARK proving system introduced by Gabizon, Williamson and Ciobotaru in 2019 that allows proving custom circuits. Plonk is based on KZG polynomial commitments and thus requires a universal trusted setup. proof. Used to verify the validity of L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. state transitions for single round fraud proofs.
Main entrypoint for depositing ETH and ERC20 tokens, which are then forwarded to the correct escrow.
The main contract of the Morph rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup.. Allows to post transaction data and state rootsA cryptographic hash succinctly representing a state using a Merkle tree. and implements the proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system.. Sequencing and proposing are permissioned to the active submitters registered and staked in the Submitter contract. If the EnforcedTxGateway is not paused, any submitter must include at least one L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. -> L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. message in their proposal if the oldest message is > 7d old. If the submitters are censoring or down for more than 7d, users can permissionlessly propose and prove via commitBatchWithProof().
Contract used to bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. ERC20 tokens with custom L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. representations from L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. to L2. It allows to change the token mappings.
Contracts to force L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. -> L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. messages with the L1 sender. Currently paused: false.
Contract used to bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. USDC tokens from L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups..
Contract used to send L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. -> L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. 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 gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. on L1 and will have the aliased address of this contract as the sender.
Registry and ETH staking contract for the accounts allowed to commit transaction batches and propose state rootsA cryptographic hash succinctly representing a state using a Merkle tree. to the RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup.. The owner whitelists submitters, who are active only while registered, not withdrawing and staked at or above the minimum. When a submitter’s batch is successfully challenged, the Rollup slashes the submitter’s whole stake through this contract: the configured reward share is forwarded to the Rollup for the challenger and the remainder accrues to the owner. Stake withdrawals are claimable only once the batch committed at withdrawal time is finalized.
Generic whitelist. Currently used to whitelist addresses that can send or relay messages to/from L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. without paying for L2 gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources..
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).