Project Introduction

Mantle Network is dedicated to building an EVM-compatible scaling solution for Ethereum. This means that all contracts and tools running on Ethereum can operate on the Mantle Network with minimal modifications. Taking advantage of its modular architecture, Mantle Network combines an optimistic rollup with various innovative data availability solutions, providing cheaper and more accessible data availability while inheriting the security of Ethereum.

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

Key Features of Mantle Network

• Built as a Rollup
  Utilizes Ethereum validators and consensus protocols to significantly reduce gas fees, decrease latency, and increase throughput. Users can customize transaction confirmation requirements to provide near real-time confirmation latency with minimal security settings.

• Modular Architecture
  Unlike traditional monolithic chains that execute transaction execution, consensus, settlement, and storage at the same network layer, Mantle separates these functions into individual modules as a modular chain. These include an EVM-compatible execution layer developed by Mantle for transaction execution, a consensus layer and settlement layer completed on Ethereum, and an external DA component (currently Mantle DA powered by EigenDA technology; we will switch to EigenDA upon its mainnet stable launch).

• Secured by Ethereum
  L2 state transitions are verified by Ethereum validators, undergoing the same consensus and settlement processes as L1 transactions.

• Modular Data Availability
  Independent DA modules, such as Mantle DA powered by EigenLayer’s EigenDA technology. According to internal assessments, this translates to potential cost savings of more than 90% compared to on-chain L1.

Below are the project websites and docs

• https://twitter.com/0xMantle
• https://www.mantle.xyz/

Prize distribution and scoring

• The prize distribution has 2 possible triggers:
  • If one or more valid medium severity findings are found, the total pot size for medium issues is $35,000
  • If one or more valid critical severity findings are found, the total pot size for critical issues is $135,000
• Given that the codebase has gone through multiple reviews before, and due to the large number of participants, we’ll NOT accept any trivial low / info findings (these are typically findings generated from a static-analyzer). Please see our definition of severity here: https://docs.secure3.io/rewards/severity-standard

Scope

• mantle-v2
  • https://github.com/mantlenetworkio/mantle-v2/tree/audits
  • commit - https://github.com/mantlenetworkio/mantle-v2/commit/7040d029eefc7a2d5a33e03bc15d6815e4a25fd6
• op-geth
  • https://github.com/mantlenetworkio/op-geth/tree/audits
  • commit - https://github.com/mantlenetworkio/op-geth/commit/64996df634fbd58d9eea82cd4cf7bf3a782c2e03

Out-of-scope issues

Any issues reported in the previous audit report - https://secure3.io/audit/Mantle_V2

What is the project’s general architectural structure and system design?

• https://docs-v2.mantle.xyz/intro/system-components/architecture

What are the roles in the product and the use cases and workflow for each role?

• https://docs-v2.mantle.xyz/intro/system-components/architecture The content in this link depicts the transaction processing process to better understand the functioning of each module
• https://docs-v2.mantle.xyz/intro/system-components/on-chain-system
• https://docs-v2.mantle.xyz/intro/system-components/off-chain-system

Which function’s or module’s attack vector do you have the most concern about?

Blockchain/DLT

• Direct loss of funds
• Permanent freezing of funds (fix requires hardfork)
• Network not being able to confirm new transactions (Total network shutdown)
• Transient consensus failures

Smart Contract

• Loss of user funds by permanent freezing or direct theft, other than unclaimed yield
• Permanent freezing of funds
• Protocol Insolvency
• Temporary freezing of funds

Which parts of the system that you want the auditors to focus on?

• Bridge-related contracts on L1 & L2, especially MNT & ETH lock and mint. Security of assets locked in Bridge.
• The sequencer （should not be attacked or crashed）
• Modification on op-geth，including gas fee collection mechanism and meta transaction protocol
• Mantle DA, driving blocks from unsafe to safe, and finalized.

What is the trust setup of the system? Should all centralized roles and components be trusted?

No specific trust setup for this system. Mantle v2 will upgrade from mantle v1, which is running. All centralized roles and components can be trusted.
List all the vulnerabilities that are not accepted or already known to the team.

Known issues:

• There appears to be an obvious bug which would allow an attacker to withdraw a fake ERC20 token from L2 in exchange for a real ERC20 (such as WBTC) token on L1. There is no check in the L2StandardBridge, however the withdrawal is prevented from finalizing by a check in the L1StandardBridge. Naturally, if you do find a way to circumvent our protections, then we would reward you.
• The fact that our contracts are upgradable via a multisig.
• The fact that fault proofs are not yet running.
• A bug in ResolvedDelegateProxy.sol which could result in a storage slot key collision overwriting the address of the implementation. This bug is dependent on the layout of the implementation contract, and Optimism is not affected.
• The OpenZeppelin Defender scan results at https://github.com/mantlenetworkio/mantle-v2/pull/72
  Known issues for the Bedrock system:
• There is an edge case in which ETH deposited to the OptimismPortal by a contract can be irrecoverably stranded:
  • When a deposit transaction fails to execute, the sender’s account balance is still credited with the mint value. However, if the deposit’s L1 sender is a contract, the tx.origin on L2 will be aliased, and this aliased address will receive the minted on L2. In general, the contract on L1 will not be able to recover these funds. We have documented this risk and encourage users to take advantage of our CrossDomainMessenger contracts, which provide additional safety measures.
• Deposit transactions can be grieffed at a cost to the attacker, by filling up the MAX_RESOURCE_LIMIT. This issue is mitigated by PR 5064, which does not completely resolve the issue but does increase the cost of a sustained grief attack. A more complete fix will require architectural changes.
• There are various ‘foot guns’ in the bridge which may arise from misconfiguration of a token. To minimize complexity, our bridge design does not try to prevent all forms of developer and user error. Examples of such foot guns include:
  • Having both (or neither of) the local and remote tokens be OptimismMintabl
  • Tokens which dynamically alter the amount of a token held by an account, such as fee-on-transfer and rebasing token.
• When running in non-archive mode, op-geth has difficulty executing deep reorgs. We are working on a fix.

Is there any other information or docs the auditor should know?

https://docs-v2.mantle.xyz/