Search
Search for projects by name or address
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... user-friendly experience, provide developers with a simpler and more flexible development environment, and deliver a comprehensive set of infrastructure for the next wave of mass-adopted dApps.
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... user-friendly experience, provide developers with a simpler and more flexible development environment, and deliver a comprehensive set of infrastructure for the next wave of mass-adopted dApps.
2025 Apr 25 — 2026 Apr 25
The section shows the operating costs that L2s pay to Ethereum.
2025 Apr 25 — 2026 Apr 25
This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data to
Ethereum.
2025 May 08 — 2026 Apr 25
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.
Last 30 day anomalies
All liveness anomalies detected for this project in the last 30 days, helping you review recent downtime and availability issues.
No State updates were performed for 7h 28m (from 2026 Apr 22, 07:44 UTC until 2026 Apr 22, 15:12 UTC). These typically occur every 59min 59s on average.
Arsia upgrade: full Ethereum DA
2026 Apr 16th
EigenDA code path removed; DA is Ethereum only. Mantle reclassified as a rollup.
Upgrade to OP Succinct
2025 Sep 16th
Mantle upgrades to OP Succinct, integrating ZK proofs for state validation.
Funds can be stolen if
Funds can be frozen if
MEV can be extracted if
STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.
All of the data needed for proof construction is published on Ethereum L1.
There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
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 blobs or calldata. This ensures that it will be available for enough time.
- Derivation: Batch submission - OP Mainnet specs
- BatchInbox - address
- OptimismPortal.sol - source code, depositTransaction function
EthereumEach 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 root 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 frozen if the permissioned proposer fails to publish state roots to the L1.
Trusted Setups
Onchain verifier
Used in
Projects used in
Search for projects used in
Onchain verifier | Used in Projects used inSearch for projects used in |
Past upgrades
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
The system has a centralized operator
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.
Regular messaging
Funds can be frozen if the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production (CRITICAL).
Forced messaging
If the user experiences censorship from the operator with regular L2->L1 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.
EVM compatible smart contracts are supported
OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.
Ethereum
Roles:
Allowed to pause withdrawals. In op stack systems with a proof system, the Guardian can also blacklist dispute games and set the respected game type (permissioned / permissionless).
Allowed to post new state roots of the current layer to the host chain.
Allowed to commit transactions from the current layer to the host chain.
Actors:
A Multisig with 6/14 threshold.
- Can upgrade with no delay
- OPSuccinctL2OutputOracle ProxyAdmin
- SystemConfig ProxyAdmin
- L1CrossDomainMessenger ProxyAdmin
- L1StandardBridge ProxyAdmin
- OptimismPortal ProxyAdmin
- Can upgrade with 1d delay
- L1MantleToken TimelockController with 1d delay → MantleTokenProxyAdmin
- Can interact with OPSuccinctL2OutputOracle
- can toggle between the optimistic mode and not optimistic (ZK) mode
- Can interact with SystemConfig
- it can update the batch submitter (Sequencer) address, the unsafe block signer, the L2 gas limit (bounded by
maximumGasLimit()), the resource metering config, and all fee/gas parameters: legacysetGasConfig(overhead, scalar), ArsiasetGasConfigArsia(basefeeScalar, blobbasefeeScalar),setBaseFee,setEIP1559Params,setMinBaseFee,setDAFootprintGasScalarandsetOperatorFeeScalars
- it can update the batch submitter (Sequencer) address, the unsafe block signer, the L2 gas limit (bounded by
- Can interact with TimelockController
- cancel queued transactions
- execute transactions that are ready
- manage all access control roles with 1d delay or with no delay TimelockController with 1d delay - or - acting directly
- propose transactions
- Can interact with AddressManager
- set and change address mappings ProxyAdmin
A Multisig with 3/7 threshold.
- A Guardian - acting directly
- A Sequencer - acting directly
- A Proposer - acting directly
Ethereum
Contains configuration parameters such as the batch submitter (Sequencer) address, the L2 gas limit, the unsafe block signer address and the Arsia fee/gas mechanics (base/blob scalars, EIP-1559 params, minimum base fee, DA footprint gas scalar and EIP-7706-style operator 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
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 limit, 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.
- Roles:
- owner: TimelockController
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.
- Roles:
- admin: ProxyAdmin; ultimately MantleSecurityMultisig
- initialProposer: EOA 2
- owner: MantleSecurityMultisig
A timelock with access control. The current minimum delay is 1d.
- Roles:
- canceller: MantleSecurityMultisig
- defaultAdmin: MantleSecurityMultisig, TimelockController; ultimately MantleSecurityMultisig
- executor: MantleSecurityMultisig
- proposer: MantleSecurityMultisig
- Roles:
- owner: MantleSecurityMultisig
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).