Mantle

Website	www.mantle.xyz
App	bridge.mantle.xyz
Documentation	docs.mantle.xyz
Explorer	explorer.mantle.xyz
Repository	github.com/mantlenetworkio
Social	discord.gg @0xMantle 0xmantle mantlenetwork

Milestones

Mainnet launch

2023 Jul 14th

Mantle is live on mainnet.

Description

Fraud proof system is currently disabled. Slashing conditions for MantleDA are currently disabled. Users need to trust block Proposer to submit correct L1 state roots.

Mantle is an EVM compatible Optimium that has been designed for use on the Ethereum network, based on the Optimism OVM architecture. It has a modular architecture trying to leverage EigenDA as Data Availability layer and Specular Network fraud proof system for fraud proofs. Note that as currently both of these technologies are yet to be fully launched on mainnet, Mantle needs to be considered “under development”. Additionally Mantle uses a set of nodes that are required to co-sign state roots via TSS (Threshold Signature Scheme). This component is intended to be eventually run by third parties, and act as an independent check on state validity prior to batch submission.

If you find something wrong on this page you can submit an issue or edit the information.

Risk Analysis

Sequencer failureState validationData availabilityUpgradeabilityProposer failure

Enqueue via L1Users can submit transactions to an L1 queue, but can't force them. The sequencer cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencer censors or is down, it is so for everyone. The operators can also reset the batch index, effectively removing transactions from the chain from a certain point onwards.

State validation

In development

Currently the system permits invalid state roots. More details in project overview.

Data availability

External

Proof construction and state derivation rely fully on data that is NOT published on chain. MantleDA contracts are forked from EigenDA with significant modifications, most importantly removal of slashing conditions. DA fraud proof mechanism is not live yet.

Upgradeability

Yes

The code that secures the system can be changed arbitrarily and without notice.

Sequencer failure

Enqueue via L1

Users can submit transactions to an L1 queue, but can’t force them. The sequencer cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencer censors or is down, it is so for everyone. The operators can also reset the batch index, effectively removing transactions from the chain from a certain point onwards.

Proposer failure

Cannot withdraw

Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.

Technology

Fraud proofs are in development

Ultimately Mantle will use fraud proofs to enforce state correctness. This feature is currently in development and the system permits invalid state roots. Deriving the chain is based on data held externally by team, so it might not be possible to detect frauds, even offchain.

Funds can be stolen if an invalid state root is submitted to the system (CRITICAL).

Data is not stored on chain

The transaction data is not recorded on the Ethereum main chain.

Funds can be lost if the external data becomes unavailable (CRITICAL).

Operator

The system has a centralized operator

The operator is the only entity that can propose blocks. 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 enqueue transactions

Users can be censored if the operator is offline or refuses to process the queue.

Withdrawals

Regular exit

The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. The process of block finalization usually takes several days to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.

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

BondManager.sol#L31 - Etherscan source code, dummy isCollateralized function

Other considerations

EVM compatible smart contracts are supported

Mantle is EVM compatible. 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 Mantle. Some opcodes behave differently.

Solidity support - Mantle documentation

Permissions

The system uses the following set of permissioned addresses:

OwnerMultisig 0x4e59…D40f

This address can upgrade the following contracts: L1CrossDomainMessenger, L1StandardBridge, AddressManager, L1MantleToken, TssGroupManager, TssStakingSlashing, TssDelegationSlasher, TssDelegationManager, TssDelegation, EigenDataLayerChain, Rollup, AssertionMap, VerifierEntry. This is a Gnosis Safe with 6 / 13 threshold.

OwnerMultisig participants 0xf735…5089 0x61Af…5fE3 0x422f…A9FC 0x207E…82f8 0xbE73…e34e 0x5a02…B317 0x7735…635A 0x3Dc5…8eB8 0xf5b1…9070 0xe75D…2d2B 0x3000…eCeb 0xc414…2A93 0x915d…172a

Those are the participants of the OwnerMultisig.

Owner2Multisig 0x2F44…daC9

This address is the owner of the following contracts: TssGroupManager, VerifierEntry, EigenDataLayerChain, L1CrossDomainMessenger, TssStakingSlashing, TssDelegationSlasher, TssDelegationManager, TssDelegation. It is also designated as the FraudVerifier, meaning it can delete state roots. This is a Gnosis Safe with 3 / 7 threshold.

Owner2Multisig participants 0x207E…82f8 0x5a02…B317 0x8955…bDEE 0x66f1…f639 0xbE73…e34e 0x3Dc5…8eB8 0x915d…172a

Those are the participants of the Owner2Multisig.

Sequencer 0x2F6A…8376

Central actor allowed to commit Mantle transactions to L1.

Tss group

Group of addresses that sign state updates usign a threshold signature scheme. Members of the group can be slashed by the group itself. It is managed by the TssGroupManager contract. It is equivalent to a 2 / 10 multisig.

Rollup operators 0x6667…d77D 0x4c5E…9994

Addresses that can initiate a state root update and challenge them. They currently sit behind a whitelist.

Rollup stakers 0x4733…8f8E 0x84A6…887a

Addresses that stake on the Rollup contract. They are not in use yet.

Smart Contracts

A diagram of the smart contract architecture

The system consists of the following smart contracts:

CanonicalTransactionChain 0x291d…aE93

The Canonical Transaction Chain (CTC) contract is an append-only log of transactions which must be applied to the OVM state. It defines the ordering of transactions by writing them to the batches instance of the ChainStorageContainerCTC. CTC batches can only be submitted by OVM_Sequencer. The CTC also allows any account to enqueue a transaction, which the Sequencer must eventually append to the rollup state.