Quantum Audit Logo

Is Mey Network Safe?

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

Mey Network MEY
0x8bfa…6789
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The MeyNetwork token contract is implemented using standard, battle-tested OpenZeppelin ERC20, ERC20Burnable, and ERC20Permit components. No custom logic was provided for analysis, so the assessment focuses on the inherent security of these foundational libraries. The contract benefits from robust security practices embedded in OpenZeppelin, including safe arithmetic and a secure permit mechanism. Potential risks primarily stem from design choices such as centralization of token supply control if minting is owner-controlled, and the immutability of the contract logic.

2 Low2 Informational
Volume 24h
$13.7K
Liquidity
$133.8K
Price
$0.05567
Token Age
10mo
Top 10 Holders
86.3%

Security Findings

2 Low2 Info
Low

Centralized Control over Token Supply (Potential)

L-01The underlying ERC20 contract includes internal `_mint` and `_burn` functions. If the `MeyNetwork` contract exposes the `_mint` function to an owner or a privileged role, this introduces a centralized point of control over the token's total supply. An attacker gaining control of this owner key could arbitrarily inflate the supply, devaluing existing tokens. While common for many tokens, this represents a centralization risk (7.3 Access Control, 7.5 Governance).
IssueThe underlying ERC20 contract includes internal `_mint` and `_burn` functions. If the `MeyNetwork` contract exposes the `_mint` function to an owner or a privileged role, this introduces a centralized point of control over the token's total supply. An attacker gaining control of this owner key could arbitrarily inflate the supply, devaluing existing tokens. While common for many tokens, this represents a centralization risk (7.3 Access Control, 7.5 Governance).
FixClearly document the role and responsibilities of any address capable of minting or burning tokens. If possible, consider implementing a timelock for minting operations or a multi-signature wallet for the controlling address to reduce single points of failure. If decentralization is a goal, consider removing or restricting minting capabilities after initial supply distribution.
StatusUnresolved
Low

Immutability of Contract Logic

L-02The contract is not implemented using an upgradeable proxy pattern (7.7 Upgrades). This means that once deployed, the contract's logic cannot be modified. While this provides certainty and removes upgrade-related risks, it also implies that any discovered bugs, vulnerabilities, or desired feature enhancements would necessitate a new contract deployment and a potentially complex token migration process for users (7.7 Upgrades).
IssueThe contract is not implemented using an upgradeable proxy pattern (7.7 Upgrades). This means that once deployed, the contract's logic cannot be modified. While this provides certainty and removes upgrade-related risks, it also implies that any discovered bugs, vulnerabilities, or desired feature enhancements would necessitate a new contract deployment and a potentially complex token migration process for users (7.7 Upgrades).
FixEnsure comprehensive testing, including unit, integration, and fuzz testing, is performed prior to deployment. Consider engaging in formal verification for critical components. Clearly communicate the immutable nature of the contract to users and stakeholders, emphasizing the importance of initial security audits.
StatusUnresolved
Info

Adherence to OpenZeppelin Standards

I-01The contract is built upon well-audited and widely adopted OpenZeppelin ERC20, ERC20Burnable, and ERC20Permit libraries. This significantly reduces the likelihood of common vulnerabilities such as reentrancy, integer overflows/underflows, and standard ERC20 compliance issues (7.2 Code Security). The use of these battle-tested components contributes to a strong security foundation.
IssueThe contract is built upon well-audited and widely adopted OpenZeppelin ERC20, ERC20Burnable, and ERC20Permit libraries. This significantly reduces the likelihood of common vulnerabilities such as reentrancy, integer overflows/underflows, and standard ERC20 compliance issues (7.2 Code Security). The use of these battle-tested components contributes to a strong security foundation.
FixContinue to monitor OpenZeppelin security advisories and updates. Ensure that any custom logic added to the `MeyNetwork` contract maintains the high security standards set by the inherited OpenZeppelin components.
StatusUnresolved
Info

Robust Permit Mechanism

I-02The `ERC20Permit` implementation correctly utilizes EIP-712 for structured data signing and incorporates nonces (`_useNonce`) to prevent signature replay attacks. This design ensures that each permit signature can only be used once, enhancing the security and usability of gasless approvals (7.2 Code Security).
IssueThe `ERC20Permit` implementation correctly utilizes EIP-712 for structured data signing and incorporates nonces (`_useNonce`) to prevent signature replay attacks. This design ensures that each permit signature can only be used once, enhancing the security and usability of gasless approvals (7.2 Code Security).
FixNo specific recommendation is needed for the `ERC20Permit` implementation itself, as it follows best practices. Users should be educated on how to safely interact with permit signatures and verify the details before signing.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages battle-tested OpenZeppelin libraries for its ERC20, Burnable, and Permit functionalities, ensuring a high degree of code security and adherence to standards (7.2 Code Security). The implementation correctly uses `unchecked` blocks where arithmetic safety is guaranteed by prior checks, preventing integer overflow/underflow vulnerabilities. The `ERC20Permit` mechanism is robust, utilizing EIP-712 and nonces to prevent signature replay attacks (7.2 Code Security). No significant technical vulnerabilities were identified within the provided OpenZeppelin components.

GovernanceMedium4/10

The token's economic model, based on the ERC20 standard, is straightforward and widely understood (7.4 Economic). The `ERC20Permit` functionality enhances user experience by allowing gasless approvals (7.4 Economic). If the `MeyNetwork` contract exposes the internal `_mint` function to an owner, it introduces a centralized point of control over the token supply, which could impact trust and economic stability (7.3 Access Control, 7.5 Governance). The absence of a pausable mechanism means that in case of an emergency, the contract cannot be halted (7.8 Operations).

UpgradesLow7/10

The contract is not designed to be upgradeable, which eliminates the complexities and potential risks associated with proxy patterns and upgrade mechanisms (7.7 Upgrades). This provides certainty regarding the immutability of the contract's logic. The non-upgradeable nature means that any future bug fixes, feature enhancements, or protocol changes would necessitate a new contract deployment and a token migration process, which can be costly and disruptive for users (7.7 Upgrades).

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

86.3% in top 10
58.9% in wallets27.3% in contracts
Effective Concentration69.9%

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

$264.8K across 5 pairs
Uniswap v3WETHanalysed$133.8K50.5%AerodromeWETH$126.6K47.8%AerodromeWETH$3.8K1.4%Uniswap v2WETH$3950.1%Uniswap v3USDT$1330.1%

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

LP Locked99.6% · TeamFinance
Top-1 Unlocked Holder0.4%

Key Addresses

6 addresses
Deployer
0x6133…a320
Unlocked LP Held By
0x1cbb…b1a40x7f42…98d80x8cf6…9cdf0x6313…1a600x774c…1a79

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

What Raised This Score

3 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 50% (86.3% total → 69.9% effective; 58.9% in EOAs, 27.3% in contracts — heavy)
  • 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
B3Medium RiskLienFi (LFI)Medium RiskDerive (DRV)Medium RiskVenice Deity (VVVEITY)Medium Risktokenbot (CLANKER)Medium RiskAerodrome Finance (AERO)Medium Risk

Would You Like a More Detailed Audit of Mey Network?

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

Get Detailed Audit