Search

Search for projects by name or address

Mantle logo
Mantle

Badges

About

Mantle is a modular general-purpose Ethereum rollup. Transaction data is posted to Ethereum blobs and state transitions are validated onchain via OP Succinct ZK validity proofs (SP1). Its design philosophy aims to offer users a less costly and more...



Badges

About

Mantle is a modular general-purpose Ethereum rollup. Transaction data is posted to Ethereum blobs and state transitions are validated onchain via OP Succinct ZK validity proofs (SP1). Its design philosophy aims to offer users a less costly and more...


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

The section shows the operating costs that L2s pay to Ethereum.



Total cost
Avg cost per L2 UOP
Avg cost per day

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 toEthereumEthereum; previously it posted toEigenDAEigenDA.


Data source: API provided by EigenLayer

Data posted
Avg size per day
Avg size per L2 UOP

Compare with other projects

This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.

No ongoing anomalies detected

Avg. tx data subs. interval
Avg. state updates interval
Past 30 days anomalies
100% normal uptime

Arsia upgrade: full Ethereum DA

2026 Apr 16th

EigenDA code path removed; DA is Ethereum only. Mantle reclassified as a 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..

Learn more

Upgrade to OP Succinct

2025 Sep 16th

Mantle upgrades to OP Succinct, integrating ZK proofs for state validation.

Learn more
Sequencer failureState validationData availabilityExit windowProposer failure
Sequencer failure
Self sequence

In the event of a 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. failure, users can force transactions to be included in the project’s chain by sending them 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.. There can be up to a 12h delay on this operation.

State validation
Validity proofs (ST, SN)

STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits..

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
Cannot withdraw

Only the whitelisted proposers can publish 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., so in the event of failure the withdrawals are frozen.

Mantle
Mantle is a
Stage 0
ZK 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. Derivation: Batch submission - OP Mainnet specs
  2. BatchInbox - address
  3. OptimismPortal.sol - source code, depositTransaction function
Learn more about the DA layer here: Ethereum logoEthereum
Validity proofs

Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract. Through the SuccinctL2OutputOracle, the system also allows to switch to an optimistic mode, in which no proofs are required and a challenger can challenge the proposed output state rootA cryptographic hash succinctly representing a state using a Merkle tree. within the finalization period.

  • Funds can be stolen if in non-optimistic mode, the validity proof cryptography is broken or implemented incorrectly.

  • Funds can be stolen if optimistic mode is enabled and no challenger checks the published state.

  • Funds can be stolen if the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route id.

  • Funds can be frozen if the permissioned proposer fails to publish state roots to the L1.

  • Funds can be frozen if in non-optimistic mode, the SP1VerifierGateway is unable to route proof verification to a valid verifier.

  1. Op-Succinct architecture

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
0x00fa...6bbf
Mantle logo
0x1e2b...8fdb
Mantle 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
4
Last upgrade
5mo 16d ago
Avg upgrade interval
1y 2mo
2026 September 17, 14:45 UTC
2changes

OPSuccinctL2OutputOracle: aggregationVkey and rangeVkeyCommitment updated to the mantle-v1.6.1 op-succinct release keys.

contract OPSuccinctL2OutputOracle (eth:0x31d543e7BE1dA6eFDc2206Ef7822879045B9f481) [succinct/OPSuccinct/OPSuccinctL2OutputOracle_mantle] {
+++ description: Contains a list of proposed state roots which Proposers assert to be a result of block execution. The SuccinctL2OutputOracle modifies the L2OutputOracle to support whenNotOptimistic mode, in which a validity proof can be passed as input argument to the proposeL2Output function.
values.aggregationVkey:
- "0x005ec5d81cbc4a9a70334f16cb0078d55ae20da550819bd0dc9c5ed12913b407"
+ "0x00fa36417110bce994f3054a68baef78ca51dee1a38659c70e108da7eb3d6bbf"
values.rangeVkeyCommitment:
- "0x2a928ed475bd7d8b7a54fac7666c68eb62d36fa15fafa8006b885b3237a7bd21"
+ "0x1e2b863405480e5509bcae955f9e23e1170419ba26af2f271cd0199f1e228fdb"
}
2026 September 10, 12:52 UTC
2changes

OPSuccinctL2OutputOracle: aggregationVkey and rangeVkeyCommitment updated to the mantle-v1.6.0 op-succinct release keys.

contract OPSuccinctL2OutputOracle (eth:0x31d543e7BE1dA6eFDc2206Ef7822879045B9f481) [succinct/OPSuccinct/OPSuccinctL2OutputOracle_mantle] {
+++ description: Contains a list of proposed state roots which Proposers assert to be a result of block execution. The SuccinctL2OutputOracle modifies the L2OutputOracle to support whenNotOptimistic mode, in which a validity proof can be passed as input argument to the proposeL2Output function.
values.aggregationVkey:
- "0x0063d017f049d215e2cda7f7826d7c1a8176a678203d6f74a731fc331cc16377"
+ "0x005ec5d81cbc4a9a70334f16cb0078d55ae20da550819bd0dc9c5ed12913b407"
values.rangeVkeyCommitment:
- "0x1dc938274cd550224002662e765b50c838b6fcb3234308b847ece2ce0e4a5631"
+ "0x2a928ed475bd7d8b7a54fac7666c68eb62d36fa15fafa8006b885b3237a7bd21"
}
2026 August 10, 11:02 UTC
3changes

OPSuccinctL2OutputOracle: aggregationVkey , rangeVkeyCommitment and rollupConfigHash rotated to the OP-Succinct v3.8.1 program versions. Both new verification keys are recorded in programHashes.ts as not verified, because reproducing them currently requires a private dependency.

contract OPSuccinctL2OutputOracle (eth:0x31d543e7BE1dA6eFDc2206Ef7822879045B9f481) [succinct/OPSuccinct/OPSuccinctL2OutputOracle_mantle] {
+++ description: Contains a list of proposed state roots which Proposers assert to be a result of block execution. The SuccinctL2OutputOracle modifies the L2OutputOracle to support whenNotOptimistic mode, in which a validity proof can be passed as input argument to the proposeL2Output function.
values.aggregationVkey:
- "0x001db6dc655ffc97e6ec7a2b5c9b1ddf42c2235faa007d8a96d659c68b7c432a"
+ "0x0063d017f049d215e2cda7f7826d7c1a8176a678203d6f74a731fc331cc16377"
values.rangeVkeyCommitment:
- "0x6f0230de6e9b59592b3127f55829c9a766d397903df5c57d557c91634a30b32b"
+ "0x1dc938274cd550224002662e765b50c838b6fcb3234308b847ece2ce0e4a5631"
values.rollupConfigHash:
- "0x6681c11eccf96068a081bbb888fd64ce72aa83bd1ccda5bbb53b4c43368cf87f"
+ "0x40d5353fb8c9257f03461070a2bfc2b18f2f822b69c64f0c467402c2fc422ecb"
}
2026 June 24, 11:01 UTC
2changes

Upgraded op-succinct programs to v2.2.4-mainnet.4. Hashes reproduced.

contract OPSuccinctL2OutputOracle (eth:0x31d543e7BE1dA6eFDc2206Ef7822879045B9f481) [succinct/OPSuccinct/OPSuccinctL2OutputOracle_mantle] {
+++ description: Contains a list of proposed state roots which Proposers assert to be a result of block execution. The SuccinctL2OutputOracle modifies the L2OutputOracle to support whenNotOptimistic mode, in which a validity proof can be passed as input argument to the proposeL2Output function.
values.aggregationVkey:
- "0x0006e0a9f37edc912bb269856518599d61689c78300c23615b2f90868d0181cf"
+ "0x001db6dc655ffc97e6ec7a2b5c9b1ddf42c2235faa007d8a96d659c68b7c432a"
values.rangeVkeyCommitment:
- "0x1d1e0ac74bb66ded0388062e779adae47925fd572a49a3424e2684f83d776004"
+ "0x6f0230de6e9b59592b3127f55829c9a766d397903df5c57d557c91634a30b32b"
}
2026 May 15, 07:41 UTC
2changes

MantleEngineeringMultisig: Two members rotated. No threshold or permission changes.

contract MantleEngineeringMultisig (eth:0x2F44BD2a54aC3fB20cd7783cF94334069641daC9) [GnosisSafe] {
+++ description: None
values.$members.3:
- "eth:0x00da2F87c56C3a19BD863613995705095F55b524"
+ "eth:0xAAc91F5766905cE034FE9f650d067a236E845c45"
values.$members.4:
- "eth:0xbE73dea9c8DcDdB6b03F7e5797b85982065fe34e"
+ "eth:0xE8Da2d2381500E863dE1d8396c86C947c8E3Fd3a"
}

The system has a centralized operator

The operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. is the only entity that can propose blocksAn 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.. A live and trustworthy operator is vital to the health of the system.

  • MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.

Users can force any transaction

Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.

  1. Sequencing Window - OP Mainnet Specs
  2. OptimismPortal.sol - source code, depositTransaction function

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. ZK proofs are required to settle blocks.

  • Funds can be frozen if the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production (CRITICAL).

  1. OptimismPortal.sol - source code, proveWithdrawalTransaction function
  2. OptimismPortal.sol - source code, finalizeWithdrawalTransaction function

Forced messaging

If the user experiences censorship from the operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. with regular 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. messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.

  1. Forced withdrawal from an OP Stack blockchain

EVM compatible smart contracts are supported

OP stack chains are pursuing the EVM EquivalenceA perfect degree of compatibility; where one system or concept is indistinguishable from another in the domain being compared. In the context of rollups, it generally refers to the proximity to the EVM and to Ethereum architecture. model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed 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. can be deployed on 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..

  1. Introducing EVM Equivalence
A dashboard to explore contracts and permissions
Go to Disco
Disco UI Banner

Ethereum

Actors:

MantleSecurityMultisig0x4e59…D40f

A Multisig with 6/14 threshold.

  • Can upgrade with no delay
    • OPSuccinctL2OutputOracle
    • SystemConfig
    • L1CrossDomainMessenger
    • L1StandardBridge
    • OptimismPortal
  • Can upgrade with 1d delay
    • L1MantleToken
  • Can interact with OPSuccinctL2OutputOracle
    • can toggle between the optimistic mode and not optimistic (ZK) mode, update the SP1 verification keys, the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. address, 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. config hashA fixed-length fingerprint of variable-size input, produced by a hash function., the submission interval and manage the approved 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. set
  • Can interact with L1MantleToken
    • can mint new MNT (up to 2% of supply per year as set by mintCapNumerator) and transfer token ownership
  • Can interact with SystemConfig
    • it can update the batch submitter (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.) address, the unsafe 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. signer, 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. gas limitThe maximum amount of gas a transaction or block may consume. (bounded by maximumGasLimit()), the resource metering config, and all fee/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. parameters: legacy setGasConfig(overhead, scalar), Arsia setGasConfigArsia(basefeeScalar, blobbasefeeScalar), setBaseFee, setEIP1559Params, setMinBaseFee, setDAFootprintGasScalar and setOperatorFeeScalars
  • Can interact with TimelockController
    • cancel queued transactions
    • execute transactions that are ready
    • manage all access control roles with 1d delay or with no delay
    • propose transactions
  • Can interact with AddressManager
    • set and change address mappings
MantleEngineeringMultisig0x2F44…daC9

A Multisig with 3/7 threshold.

  • Can interact with OPSuccinctL2OutputOracle
    • can delete proposed state rootsA cryptographic hash succinctly representing a state using a Merkle tree., enable/disable the optimistic (proof-less) mode and change the finalization period
  • Can interact with OptimismPortal
    • Allowed to pause withdrawals. In op stack systems with a 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., the Guardian can also blacklist dispute games and set the respected game type (permissioned / 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.)
SP1VerifierGatewayMultisig0xCafE…6878

A Multisig with 2/3 threshold.

  • Can interact with SP1VerifierGateway
    • affect the 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. and safety of the gateway - can transfer ownership, add and freeze verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. routes
Used in:
  • Can interact with SystemConfig
    • Allowed to commit transactions from the current layer to the host chain
  • Can interact with OPSuccinctL2OutputOracle
    • Allowed to post new state rootsA cryptographic hash succinctly representing a state using a Merkle tree. of the current layer to the host chain
A dashboard to explore contracts and permissions
Go to Disco
Disco UI Banner

Ethereum

Contains configuration parameters such as the batch submitter (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.) address, 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. gas limitThe maximum amount of gas a transaction or block may consume., the unsafe 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. signer address and the Arsia fee/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. mechanics (base/blobThe 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. scalars, EIP-1559 params, minimum base fee, DA footprint gas scalar and EIP-7706-style operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. fee).

  • Roles:
    • admin: ProxyAdmin; ultimately MantleSecurityMultisig
    • batcherHash: EOA 1
    • owner: MantleSecurityMultisig

The main entry point to deposit funds from host chain to this chain. It also allows to prove and finalize withdrawals.

  • Roles:
    • admin: ProxyAdmin; ultimately MantleSecurityMultisig
    • guardian: MantleEngineeringMultisig
The following tokens are included in the value secured calculation:
ETH token logoMNT token logo

Sends messages from host chain to this chain, and relays messages back onto host chain. In the event that a message sent from host chain to this chain is rejected for exceeding this chain’s epoch gas limitThe maximum amount of gas a transaction or block may consume., it can be resubmitted via this contract’s replay function.

  • Roles:
    • admin: ProxyAdmin; ultimately MantleSecurityMultisig

The main entry point to deposit ERC20 tokens from host chain to this chain.

  • Roles:
    • admin: ProxyAdmin; ultimately MantleSecurityMultisig

All supported tokens in this escrow are included in the value secured calculation.

MantleTokenProxyAdmin0x0cac…9ADd
  • Roles:
    • owner: TimelockController

Contains a list of proposed state rootsA cryptographic hash succinctly representing a state using a Merkle tree. which Proposers assert to be a result of 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. execution. The SuccinctL2OutputOracle modifies the L2OutputOracle to support whenNotOptimistic mode, in which a validity proofThe output of a cryptographic proving system attesting to correct computation. ZK-Rollups use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and blocks were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed. can be passed as input argument to the proposeL2Output function.

  • Roles:
    • admin: ProxyAdmin; ultimately MantleSecurityMultisig
    • challenger: MantleEngineeringMultisig
    • initialProposer: EOA 2
    • owner: MantleSecurityMultisig

MNT token contract: Mantle uses Mantle (MNT) as the designated 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. token, allowing users pay for gas in MNT.

  • Roles:
    • admin: MantleTokenProxyAdmin; ultimately MantleSecurityMultisig
    • owner: MantleSecurityMultisig
TimelockController0x6533…447F

A timelock with access control. The current minimum delay is 1d.

  • Roles:
    • canceller: MantleSecurityMultisig
    • defaultAdmin: MantleSecurityMultisig, TimelockController; ultimately MantleSecurityMultisig
    • executor: MantleSecurityMultisig
    • 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.: MantleSecurityMultisig
ProxyAdmin0xca35…7794
  • Roles:
    • owner: MantleSecurityMultisig
SP1Verifier0x0459…C459

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v5.0.0).

Implementation used in:
SP1VerifierGateway0x3B60…185e

This contract is the router for zk proof verification. It stores the mapping between identifiers and the address of onchain verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contracts, routing each identifier to the corresponding verifier contract.

  • Roles:
    • owner: SP1VerifierGatewayMultisig
Implementation used in:
SP1Verifier0x8a0f…Fc5C

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v6.0.0).

Implementation used in:
SP1Verifier0xc3c6…AF2A

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v6.1.0).

Implementation used in:

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
0x00fa...6bbf
Mantle logo
0x1e2b...8fdb
Mantle logo