Quantum Audit Logo

Is Metis Token Safe?

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

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

Metis Token METIS
0x9e32…ed8e
Ethereum
Not verifiedThis record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked today 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers the ERC20 token contract, which appears to be a standard OpenZeppelin implementation. The contract utilizes SafeMath for arithmetic safety and adheres to the ERC20 standard. It is not upgradeable, and ownership has been renounced, contributing to decentralization. The primary risks identified are minor and informational, related to the use of an older Solidity version and the inherent front-running vulnerability in the ERC20 `approve` function, which is mitigated by alternative functions.

1 Low3 Informational
Volume 24h
$94.3K
Liquidity
$712.0K
Price
$3.5400
Token Age
5y
Top 10 Holders
84.1%

Security Findings

1 Low3 Info
Low

ERC20 `approve` Function Front-Running Vulnerability

L-01The standard ERC20 `approve` function is susceptible to a front-running attack. If a user approves an amount for a spender, and then decides to change that approved amount, a malicious actor could front-run the second `approve` transaction. This allows the attacker to spend the original allowance before the new allowance is set, and then spend the new allowance, effectively spending more than intended by the user. The contract includes `increaseAllowance` and `decreaseAllowance` as mitigations.
IssueThe standard ERC20 `approve` function is susceptible to a front-running attack. If a user approves an amount for a spender, and then decides to change that approved amount, a malicious actor could front-run the second `approve` transaction. This allows the attacker to spend the original allowance before the new allowance is set, and then spend the new allowance, effectively spending more than intended by the user. The contract includes `increaseAllowance` and `decreaseAllowance` as mitigations.
FixAdvise users to exclusively use `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` when modifying an existing allowance. Educate users on the risks associated with the direct `approve` function.
StatusUnresolved
Info

Use of Older Solidity Compiler Version

I-01The contract is compiled with Solidity version `^0.5.0` (specifically 0.5.16). While this version is stable, newer Solidity versions (e.g., 0.8.x) offer additional security features, gas optimizations, and clearer error handling (e.g., default checked arithmetic, custom errors).
IssueThe contract is compiled with Solidity version `^0.5.0` (specifically 0.5.16). While this version is stable, newer Solidity versions (e.g., 0.8.x) offer additional security features, gas optimizations, and clearer error handling (e.g., default checked arithmetic, custom errors).
FixFor new deployments or significant upgrades, consider migrating to a more recent Solidity compiler version (e.g., 0.8.x) to leverage improved security features and optimizations. Thorough testing would be required for any migration.
StatusUnresolved
Info

Non-Upgradeability of Contract

I-02The contract is not designed with upgradeability in mind, as indicated by `is_proxy: false`. This means that once deployed, the contract's logic cannot be modified. While this eliminates risks associated with upgrade mechanisms, it also prevents bug fixes, feature additions, or parameter changes without deploying an entirely new contract and migrating assets.
IssueThe contract is not designed with upgradeability in mind, as indicated by `is_proxy: false`. This means that once deployed, the contract's logic cannot be modified. While this eliminates risks associated with upgrade mechanisms, it also prevents bug fixes, feature additions, or parameter changes without deploying an entirely new contract and migrating assets.
FixAcknowledge the trade-offs of non-upgradeability. For contracts intended to be immutable, this is a desired feature. For projects requiring future flexibility, consider proxy patterns (e.g., UUPS, Transparent) in future contract designs.
StatusUnresolved
Info

Reliance on Derived Contract for Supply Mechanism

I-03The provided `ERC20.sol` contract serves as a base implementation and does not define the token's supply mechanism (minting/burning). These functionalities are expected to be implemented in a derived contract, such as `MToken`, using the internal `_mint` and `_burn` functions. The security and economic stability of the token heavily depend on the access control and logic within the derived contract's supply functions.
IssueThe provided `ERC20.sol` contract serves as a base implementation and does not define the token's supply mechanism (minting/burning). These functionalities are expected to be implemented in a derived contract, such as `MToken`, using the internal `_mint` and `_burn` functions. The security and economic stability of the token heavily depend on the access control and logic within the derived contract's supply functions.
FixEnsure that the derived `MToken` contract implements robust access control for `_mint` and `_burn` functions, restricting them to authorized entities or predefined conditions. A separate audit of the `MToken` contract's specific implementation is crucial.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1 Architecture) is robust, leveraging well-audited OpenZeppelin ERC20 and SafeMath libraries. Code security (7.2 Code Security) is strong, with SafeMath preventing integer overflows/underflows. Access control (7.3 Access Control) for core ERC20 functions relies on `_msgSender()`. A minor issue is the known front-running vulnerability in the `approve` function, though `increaseAllowance` and `decreaseAllowance` are provided as mitigations. The contract uses Solidity 0.5.x, which is an older version.

GovernanceMedium6/10

The economic model (7.4 Economic) of the base ERC20 contract is sound, relying on a derived contract (MToken) for supply mechanisms like minting and burning. The prefill indicates `ownership_renounced: true`, which is a positive aspect for decentralization, removing central governance (7.5 Governance) control over the contract post-deployment. External dependencies (7.6 External) are limited to SafeMath, which is a well-vetted library.

UpgradesMedium6/10

The contract is not designed to be upgradeable (7.7 Upgrades), as indicated by `is_proxy: false`. This eliminates upgrade-related risks such as proxy storage collisions or faulty implementation deployments. However, it also means that no future bug fixes or feature enhancements can be implemented without a new deployment. Operational aspects (7.8 Operations) are minimal due to renounced ownership.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

84.1% in top 10
15.0% in wallets69.1% in contracts
Effective Concentration42.6%

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

$716.8K across 3 pairs
Uniswap v3WETHanalysed$712.0K99.3%SushiswapWETH$2.9K0.4%Uniswap v2WETH$1.9K0.3%

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

6 addresses
Deployer
0x7532…5c44
Unlocked LP Held By
0xfa79…74d50x3689…6e2b0x8f59…bfec0xfbd9…18b50xfeae…d990

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

What Raised This Score

6 factors
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (84.1% total → 42.6% effective; 15.0% in EOAs, 69.1% in contracts — moderate)
  • 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 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
Chainlink (LINK)Medium RiskKiteMedium RiskKarratCoin (KARRAT)Medium RiskOctra (OCT)Medium RiskArtificial Superintelligence Alliance (FET)Medium RiskOndoMedium Risk

Would You Like a More Detailed Audit of Metis Token?

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

Get Detailed Audit