Quantum Audit Logo

Is Mantle Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

Mantle MNT
0x3c3a…f354
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The L1MantleToken contract implements an upgradeable ERC-20 token with burnable, permit, and voting functionalities. It features a controlled minting mechanism with a time interval and a dynamic cap. The contract leverages OpenZeppelin's battle-tested libraries and follows best practices for upgradeability and access control, with critical functions protected by a robust multisig ownership structure. While the technical implementation is strong, the centralized control over minting and mint cap adjustments by the owner multisig introduces a notable economic risk.

1 High1 Medium2 Low
Volume 24h
$216.0K
Liquidity
$3.52M
Price
$0.5692
Token Age
1y
Top 10 Holders
86.7%

Security Findings

1 High1 Med2 Low
High

Centralized Minting Authority

H-01The `mint` function is protected by the `onlyOwner` modifier, meaning only the contract owner can mint new tokens. While the owner is a robust 6/14 multisig, this design centralizes the control over the token's supply, giving the multisig significant power to inflate the token supply. This is a fundamental design choice but represents a high-impact point of control (7.3 Access Control, 7.4 Economic).
IssueThe `mint` function is protected by the `onlyOwner` modifier, meaning only the contract owner can mint new tokens. While the owner is a robust 6/14 multisig, this design centralizes the control over the token's supply, giving the multisig significant power to inflate the token supply. This is a fundamental design choice but represents a high-impact point of control (7.3 Access Control, 7.4 Economic).
FixAcknowledge this as a design decision. Ensure the multisig governance process for minting is transparent, well-documented, and subject to community oversight. Consider implementing a timelock for minting operations or a more decentralized minting mechanism if future protocol evolution allows.
StatusUnresolved
Medium

Owner's Control Over Mint Cap Numerator

M-01The `setMintCapNumerator` function, which determines the maximum percentage of total supply that can be minted in an interval, is callable only by the owner (multisig). Although there's an upper bound (`MINT_CAP_MAX_NUMERATOR`), the owner can adjust this value at any time. Frequent or unexpected changes to this parameter could impact market perception and token economics (7.5 Governance, 7.4 Economic).
IssueThe `setMintCapNumerator` function, which determines the maximum percentage of total supply that can be minted in an interval, is callable only by the owner (multisig). Although there's an upper bound (`MINT_CAP_MAX_NUMERATOR`), the owner can adjust this value at any time. Frequent or unexpected changes to this parameter could impact market perception and token economics (7.5 Governance, 7.4 Economic).
FixImplement a timelock for changes to `mintCapNumerator` to provide transparency and allow stakeholders to react. Clearly communicate any proposed changes to this parameter well in advance. Consider a more decentralized governance mechanism for such critical parameter adjustments in the future.
StatusUnresolved
Low

Reliance on `block.timestamp` for `nextMint`

L-01The `nextMint` timestamp is calculated and updated using `block.timestamp`. While `block.timestamp` is generally reliable, miners can manipulate it within a small range (up to 900 seconds on Ethereum). For a `MIN_MINT_INTERVAL` of 365 days, this manipulation is negligible and does not pose a significant risk of accelerating the minting schedule (7.2 Code Security).
IssueThe `nextMint` timestamp is calculated and updated using `block.timestamp`. While `block.timestamp` is generally reliable, miners can manipulate it within a small range (up to 900 seconds on Ethereum). For a `MIN_MINT_INTERVAL` of 365 days, this manipulation is negligible and does not pose a significant risk of accelerating the minting schedule (7.2 Code Security).
FixGiven the very long `MIN_MINT_INTERVAL`, the impact of `block.timestamp` manipulation is minimal. No immediate action is required, but for future designs involving shorter time intervals, `block.number` or an oracle-based timestamp might be considered for greater robustness.
StatusUnresolved
Low

Missing Zero Address Check for `_recipient` in `mint`

L-02The `mint` function does not explicitly check if the `_recipient` address is `address(0)`. While OpenZeppelin's underlying `_mint` function would revert if `to` is `address(0)`, an explicit check in the `mint` function would provide clearer intent and a more specific error message, preventing accidental burning of tokens to the zero address (7.2 Code Security).
IssueThe `mint` function does not explicitly check if the `_recipient` address is `address(0)`. While OpenZeppelin's underlying `_mint` function would revert if `to` is `address(0)`, an explicit check in the `mint` function would provide clearer intent and a more specific error message, preventing accidental burning of tokens to the zero address (7.2 Code Security).
FixAdd an explicit check at the beginning of the `mint` function: `if (_recipient == address(0)) revert MantleToken_ImproperlyInitialized();` or a custom error for zero address recipients.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The L1MantleToken contract is built upon well-audited OpenZeppelin libraries, ensuring a strong foundation for ERC-20 functionality, burning, and access control (7.3 Access Control). Solidity version 0.8.15 mitigates common integer overflow/underflow risks (7.2 Code Security). The minting logic correctly implements time-based intervals and a dynamic cap, preventing excessive inflation. Minor improvements could include explicit zero-address checks for recipient parameters in the `mint` function.

GovernanceHigh2/10

The contract's economic model centers around a controlled minting mechanism, where new tokens can be minted by the owner, which is a robust 6/14 multisig (7.4 Economic). This centralization of minting (7.5 Governance) and the ability to adjust the mint cap via `setMintCapNumerator` are significant points of control. While secured by a multisig, these powers could lead to supply inflation if not managed transparently and responsibly, impacting token value.

UpgradesHigh1/10

The contract utilizes the TransparentUpgradeableProxy pattern, with the implementation logic residing in L1MantleToken. The upgrade process is secured by an OpenZeppelin ProxyAdmin, which is owned by a Timelock (7.7 Upgrades). This Timelock is, in turn, controlled by a multisig, providing a robust and decentralized upgrade path with a time delay. This setup significantly reduces the risk of malicious or hasty upgrades, ensuring operational safety (7.8 Operations).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

86.7% in top 10
34.4% in wallets52.3% in contracts
Effective Concentration55.3%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$3.54M across 4 pairs
Uniswap v3USDeanalysed$3.52M99.3%Uniswap v3WETH$16.4K0.5%Uniswap v4ETH$7.2K0.2%Uniswap v3USDC$3970.0%

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xc22d…bb9f
Unlocked LP Held By
0x3e2a…7eea

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

10 factors
  • Ownership NOT renounced — strong Multisig (6-of-14)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 50% (86.7% total → 55.3% effective; 34.4% in EOAs, 52.3% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Related Audits

6 more on the record
DeXeHigh RiskRadicle (RAD)High RiskOcean Token (OCEAN)High RiskToken Prometeus Network (PROM)High RiskFake World Assets (FWA)High RiskHarryPotterObamaSonic10Inu (BITCOIN)High Risk

Would You Like a More Detailed Audit of Mantle?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit