As of 30 Oct 2026, Mantle Network has 9 audit reports by 4 security firms on Trustblock; the latest is by MixBytes, dated 28 May 2025. Those reports list no open critical findings.
Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Trustblock does not review code.
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Mantle Network fBTC Timelock security audit | Security firm: MixBytes | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Mantle Op-geth & Op-stack Diff Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| Mantle V2 Solidity Contracts Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | 1 critical finding, fixed | Open · blog.openzeppelin.com |
| Mantle OP-Geth Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | 3 critical findings, fixed | Open · blog.openzeppelin.com |
| Mantle Node, Batcher, Proposer, and Tooling Increm | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| Mantle Token and Bridge Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| Mantle Network (Bridge Contracts) | Security firm: Quantstamp | Date: | Scope: Repository at commit d627d24 | No open critical findings | Open · certificate.quantstamp.com |
| Mantle security review | Security firm: Sigma Prime | Date: | Scope: Not recorded (see the report) | 1 critical finding, fixed | Open · GitHub |
| Mantle Network (Token Migration) | Security firm: Quantstamp | Date: | Scope: Files named in the report | No open critical findings | Open · certificate.quantstamp.com |
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 5 |
| High | 0 | 4 | 3 |
| Medium | 0 | 5 | 13 |
| Low | 12 | 26 | 31 |
The accounting approach for deposits in `L1StandardBridge.sol` and burning and minting operations in `L2StandardBridge.sol` are not compatible with ERC-20 tokens that (but not limited to): - Have a transfer, minting, or burning fee - Are deflationary/inflationary (i.e. the balance of an account can change "arbitrarily", without a transfer operation) - Its L2 version unexpectedly reverts when minting, burning, or transferring - Its L2 version does not implement minting and burning operations properly (e.g. mints or burns more or fewer tokens than expected, leading to duplicate funds or issues when withdrawing from L2) - Implement blocklists <br> Currently, the system allows anyone to deploy a compatible token in L2 and link it to an L1 token. Users are responsible for ensuring that the ERC-20 L2 token is correct and that its behavior is not in the abovementioned list. **Interacting with a non-compatible token will block user funds in `L1StandardBridge.sol`.**
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportAlthough a test suite in the repository exists, it is from the original Optimism repository. The Mantle team stated that they do not have unit tests at this moment that cover the Mantle bridge contracts.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the report`defundContract()` can be used by the owner of the contract to transfer the funds from the migrator contract to the `treasury` address. However, the owner can just change the `treasury` variable with the same privileges and therefore transfer the funds to an arbitrary address.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the report`L1StandardBridge.initialize()` is a public function with no access control. If `L1StandardBridge` is deployed behind a proxy, anyone can initialize the implementation contract by calling `initialize()` with arbitrary values. Although this does not affect the functionality of the project, it may open possible phishing or social engineering attacks (e.g. an attacker can try to impersonate Mantle). If the contract is not deployed using a proxy, there is a possibility of front-running. After contract deployment, an attacker can call `initialize()`, needing to deploy the contract again.
Open the reportEvery Solidity file specifies in the header a version number of the format `pragma solidity (^)0.8.*`. The caret (`^`) before the version number implies an unlocked pragma, meaning that the compiler will use the specified version _and above_, hence the term "unlocked".
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportIf the owner renounces their ownership, or the ownership is transferred to the wrong address, all ownable contracts will be left without an owner. During the audit, the auditing team found the following issues: 1. `L1MantleToken`: - `OwnableUpgradeable` from OpenZeppelin implements `renounceOwnership()` function. If the contract owner calls this function, all the functions guarded by `onlyOwner` will no longer be able to be executed. - `OwnableUpgradeable` implements `transferOwnership()`. If the new owner address is wrong or not controlled by the team, access to privileged functions (`onlyOwner`) will be lost forever. 2. `MantleTokenMigrator`: - This contract implements a custom function for transferring the contract ownership: `transferOwnership()`. If the new `owner` address is wrong or not controlled by the team, access to privileged functions (`onlyOwner`) will be lost forever.
Open the reportThe reports name a repository or files. Open a report to see its scope.
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="mantle-network"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us