Search

Search for projects by name or address

Badges

About

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...



Badges

About

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...


Total
Canonically BridgedCanonically Bridged ValueCanonical
Natively MintedNatively Minted TokensNative
Externally BridgedExternally Bridged ValueExternal

ETH & derivatives
Stablecoins
BTC & derivatives
Other
Compare with other projects
Past Day UOPS
Past Day Ops count
Max. UOPS
Past day UOPS/TPS Ratio
Compare with other projects

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 toEthereumEthereum.



Data posted
Avg size per day
Avg size per L2 UOP

Compare with other projects

Fully centralized sequencing

2026 Sep 22nd

Only submitters staked in the new Submitter contract can commit batches. BLS input removed.

Learn more
The current 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. version loses livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. if bad/random data is posted to 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. using commitBatch()
The current 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. version loses livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. if bad/random data is posted to 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. using commitBatch()
Sequencer failureState validationData availabilityExit windowProposer failure
Sequencer failure
Force via L1

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.

State validation
Fraud proofs (1R, ZK)

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.

Data availability
Onchain

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..

Exit window
None

There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.

Proposer failure
Self propose

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.

Morph
Morph is a
Stage 0
Optimistic Rollup.

Learn more about Stages
Please keep in mind that these stages do not reflect project security, this is an opinionated assessment of project maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.

All data required for proofs is published on chain

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.

  1. Rollup.sol - Etherscan source code commitBatch() and commitBatchWithBlobProof() functions
Learn more about the DA layer here: Ethereum logoEthereum
Fraud proofs

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.

  1. Whitelisted Challengers - Morph Docs
  2. Rollup.sol - Etherscan source code, commitBatch(), challengeState(), proveState() functions
  3. Submitter.sol - Etherscan source code, isActive(), stake(), slash() functions

Trusted Setups

Onchain verifier

Used in

Base Chain logoMantle logoCelo logoMorph logoX Layer logo

Projects used in

Search for projects used in

Onchain verifier

Used in

Base Chain logoMantle logoCelo logoMorph logoX Layer logo

Projects used in

Search for projects used in

Program Hashes

Name
Hash
Repository
Verification
Used in
0x00c4...c25c
Morph logo
0x00b4...0c63
Morph logo

Past upgrades

The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.

Count of upgrades
23
Last upgrade
5d 12h ago
Avg upgrade interval
7mo 3d
2026 September 22, 12:41 UTC
High severity
20changes

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.
2026 August 14, 15:02 UTC
3changes

critical contracts and severities for the ossification perimeter

New and verified contracts

+ 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.
2026 August 14, 15:02 UTC
10changes

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"}
}
2026 August 10, 09:04 UTC
1change

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"
}
2026 June 08, 10:27 UTC
High severity
10changes

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

The system has a centralized operator

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.

  1. Rollup.sol - Etherscan source code, onlyActiveSubmitter modifier
  2. Submitter.sol - Etherscan source code, addSubmitter()

Users can force 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.

  1. EnforcedTxGateway proxy - PAUSED - Etherscan source code
  2. EnforcedTxGateway.sol implementation - Etherscan source code

Regular messaging

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.

  1. L1ETHGateway.sol - Etherscan source code, finalizeWithdrawETH function
A dashboard to explore contracts and permissions
Go to Disco
Disco UI Banner

Ethereum

Actors:

L1Staking0x0Dc4…43F7

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.

  • Can interact with Whitelist
    • can send gasless transactions to L2 (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. fee waived)
Morph Multisig 20xB822…4377

A Multisig with 3/5 threshold.

  • Can interact with L1Staking
    • whitelist and remove stakers (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 relayed to L2) and manage the staking, slashing and reward config of this contract
  • Can interact with L1MessageQueueWithGasPriceOracle
    • manage L2 base fee, max gas limitThe maximum amount of gas a transaction or block may consume. and set the whitelist checker contract
  • Can interact with TimelockController
    • cancel queued transactions
    • propose transactions
  • Can interact with 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.
    • Allowed to challenge or delete state rootsA cryptographic hash succinctly representing a state using a Merkle tree. proposed by 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.
  • Can interact with EnforcedTxGateway
    • pause and unpause, update the fee vault
  • Can interact with Whitelist
    • manage the whitelist
Morph Multisig 10xF101…D887

A Multisig with 4/6 threshold.

  • Can upgrade with no delay
    • L1Staking
    • L1ETHGateway
    • L1USDCGateway
    • L1MessageQueueWithGasPriceOracle
    • L1StandardERC20Gateway
    • TimelockController
    • L1GatewayRouter
    • 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.
    • L1CustomERC20Gateway
    • EnforcedTxGateway
    • L1USDCGatewayLegacy
    • L1CrossDomainMessenger
    • Submitter
  • Can interact with TimelockController
    • execute transactions that are ready
    • manage all access control roles
  • Can interact with MultipleVersionRollupVerifier
    • register new verifiers to be used starting from a given 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. batch index
  • Can interact with L1GatewayRouter
    • manage token to escrow mapping and (un-)register escrows
  • Can interact with Rollup
    • can pause and unpause, revert unfinalized batches, update proof window and finalization period, manage challengers, modify the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. address
  • Can interact with L1CrossDomainMessenger
    • set critical configs and contract references and pause/unpause
  • Can interact with Submitter
    • 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
  • Can interact with 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.
    • Allowed to challenge or delete state rootsA cryptographic hash succinctly representing a state using a Merkle tree. proposed by 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.
  • Can interact with L1Staking
    • Stakers relayed to 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. Staking contract as the L2 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. This does not authorize committing batches or proposing state rootsA cryptographic hash succinctly representing a state using a Merkle tree. on 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., which the Submitter contract controls
  • Can interact with Submitter
    • Actors allowed to commit transaction batches and propose and prove state roots while staked at or above the minimum
  • Can interact with L1Staking
    • Stakers relayed to 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. Staking contract as the L2 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. This does not authorize committing batches or proposing state rootsA cryptographic hash succinctly representing a state using a Merkle tree. on 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., which the Submitter contract controls
A dashboard to explore contracts and permissions
Go to Disco
Disco UI Banner
A diagram of the smart contract architecture
A diagram of the smart contract architecture

Ethereum

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..

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1

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..

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1
ProxyAdmin0x3111…16A0
  • Roles:
    • owner: TimelockController
L1MessageQueueWithGasPriceOracle0x3931…C1EFImplementation (Upgradable)Admin

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.

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1
    • owner: Morph Multisig 2

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.

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1

A timelock with access control. The current minimum delay is 0s.

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1
    • canceller: Morph Multisig 2
    • defaultAdmin: Morph Multisig 1, TimelockController; ultimately Morph Multisig 1
    • executor: Morph Multisig 1
    • 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.: Morph Multisig 2
MultipleVersionRollupVerifier0x5d15…0EC1

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.

  • Roles:
    • owner: Morph Multisig 1
ZkEvmVerifierV1
2 instances
0x651c…d1c90x9774…4624

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.

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1
    • owner: Morph Multisig 1

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().

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1
    • challengers: EOA 1, EOA 10, EOA 11, EOA 13, EOA 14, EOA 15, EOA 16, EOA 18, EOA 19, EOA 2, EOA 20, EOA 21, EOA 22, EOA 23, EOA 24, EOA 25, EOA 26, EOA 27, EOA 28, EOA 3, EOA 30, EOA 31, EOA 32, EOA 33, EOA 34, EOA 35, EOA 36, EOA 37, EOA 38, EOA 4, EOA 40, EOA 41, EOA 42, EOA 5, EOA 6, EOA 8, EOA 9, Morph Multisig 2
    • owner: Morph Multisig 1
ProxyAdmin0x8654…Ec17
  • Roles:
    • owner: Morph Multisig 1

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.

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1

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.

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1
    • owner: Morph Multisig 2

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..

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1

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.

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1
    • owner: Morph Multisig 1

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.

  • Roles:
    • admin: ProxyAdmin; ultimately Morph Multisig 1
    • owner: Morph Multisig 1
    • submitters: EOA 12, EOA 29, EOA 7
Whitelist0xFFaf…6984

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..

  • Roles:
    • owner: Morph Multisig 2
    • whitelisted: L1Staking

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).

Program Hashes

Name
Hash
Repository
Verification
Used in
0x00c4...c25c
Morph logo
0x00b4...0c63
Morph logo