Quantum Audit Logo

Is MYX Safe?

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

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

MYX MYX
0xd825…3e16
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The MYX token contract is a straightforward ERC20 implementation leveraging battle-tested OpenZeppelin libraries for its core functionality and ERC20Permit extension. The primary security concern identified is the centralization of the entire token supply to a single distributor address, which presents a significant single point of failure. The contract is not upgradeable, eliminating upgrade-related risks but also limiting future flexibility. Overall, the technical implementation is robust due to OpenZeppelin's foundations, but the economic model introduces a notable centralization risk.

1 High1 Low2 Informational
Volume 24h
$167.1K
Liquidity
$240.5K
Price
$0.06831
Token Age
1y
Top 10 Holders
88.1%

Security Findings

1 High1 Low2 Info
High

Centralization of Token Supply

H-01The entire `MAX_SUPPLY` of MYX tokens (1,000,000,000 ether) is minted to a single `_DISTRIBUTOR` address (0x3E1D…b293) in the contract's constructor. This design choice creates a single point of failure for the entire token supply (7.4 Economic, 7.8 Operations). If the `_DISTRIBUTOR` address's private key is compromised, or if the address itself is a contract with a vulnerability, the entire token supply could be stolen or frozen, leading to a catastrophic loss for the project and its users.
IssueThe entire `MAX_SUPPLY` of MYX tokens (1,000,000,000 ether) is minted to a single `_DISTRIBUTOR` address () in the contract's constructor. This design choice creates a single point of failure for the entire token supply (7.4 Economic, 7.8 Operations). If the `_DISTRIBUTOR` address's private key is compromised, or if the address itself is a contract with a vulnerability, the entire token supply could be stolen or frozen, leading to a catastrophic loss for the project and its users.
FixImplement robust security measures for the `_DISTRIBUTOR` address. This could include using a hardware wallet, a multi-signature wallet (e.g., Gnosis Safe), or a time-locked contract for managing the token distribution. Consider distributing the initial supply across multiple secure addresses or implementing a more decentralized distribution mechanism if feasible for future token projects.
StatusUnresolved
Low

Front-running Risk for Permit Function

L-01The `permit` function, while a standard and useful feature from EIP-2612, can be susceptible to front-running (7.2 Code Security). A malicious actor could observe a user's signed `permit` message in the mempool and submit their own transaction with a higher gas price, effectively 'stealing' the user's intended approval or causing the legitimate transaction to fail and incur unnecessary gas costs. This is an inherent characteristic of the `permit` pattern and not a flaw in the contract's implementation itself.
IssueThe `permit` function, while a standard and useful feature from EIP-2612, can be susceptible to front-running (7.2 Code Security). A malicious actor could observe a user's signed `permit` message in the mempool and submit their own transaction with a higher gas price, effectively 'stealing' the user's intended approval or causing the legitimate transaction to fail and incur unnecessary gas costs. This is an inherent characteristic of the `permit` pattern and not a flaw in the contract's implementation itself.
FixEducate users about the potential for front-running when using the `permit` function. Advise them to be cautious when broadcasting signed messages and to consider using private transaction relays or services that offer front-running protection if available on the network.
StatusUnresolved
Info

Reliance on Battle-Tested OpenZeppelin Libraries

I-01The MYX contract extensively uses OpenZeppelin's `ERC20` and `ERC20Permit` implementations. These libraries are widely recognized as industry standards, have undergone numerous audits, and are battle-tested in production environments (7.2 Code Security). This significantly reduces the likelihood of common vulnerabilities such as reentrancy, integer overflows/underflows, or incorrect ERC20 behavior within the core token logic.
IssueThe MYX contract extensively uses OpenZeppelin's `ERC20` and `ERC20Permit` implementations. These libraries are widely recognized as industry standards, have undergone numerous audits, and are battle-tested in production environments (7.2 Code Security). This significantly reduces the likelihood of common vulnerabilities such as reentrancy, integer overflows/underflows, or incorrect ERC20 behavior within the core token logic.
FixContinue to monitor OpenZeppelin's security advisories and updates. Ensure that the specific versions of OpenZeppelin contracts used are up-to-date and free from known vulnerabilities.
StatusUnresolved
Info

Fixed Token Supply and Immutability

I-02The MYX token has a fixed `MAX_SUPPLY` of 1 billion tokens (with 18 decimals) and no additional minting or burning capabilities beyond the initial constructor mint (7.4 Economic). The contract is also not upgradeable (7.7 Upgrades). This design provides transparency and predictability regarding the total token supply and ensures that the contract's logic remains immutable post-deployment.
IssueThe MYX token has a fixed `MAX_SUPPLY` of 1 billion tokens (with 18 decimals) and no additional minting or burning capabilities beyond the initial constructor mint (7.4 Economic). The contract is also not upgradeable (7.7 Upgrades). This design provides transparency and predictability regarding the total token supply and ensures that the contract's logic remains immutable post-deployment.
FixThis is a design choice. Ensure that the fixed supply and immutability align with the long-term economic and operational goals of the MYX project. Clearly communicate these characteristics to the community.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The MYX token contract is simple and primarily relies on battle-tested OpenZeppelin ERC20 and ERC20Permit implementations (7.2 Code Security). This significantly reduces the risk of common token vulnerabilities like reentrancy or integer overflows, as OpenZeppelin contracts are rigorously audited. The implementation correctly handles ERC20 standard functions and the EIP-2612 permit mechanism. A minor technical consideration is the inherent front-running risk associated with the `permit` function (7.2 Code Security), where a signed message could be observed and exploited by a malicious actor.

GovernanceHigh3/10

The token has a fixed maximum supply, providing transparency and predictability regarding its total issuance (7.4 Economic). There are no complex economic models or governance mechanisms introduced by the contract itself, simplifying its economic profile. However, a significant economic and operational risk is the complete centralization of the token supply (7.4 Economic, 7.8 Operations). All `MAX_SUPPLY` tokens are minted to a single `_DISTRIBUTOR` address in the constructor, making this address a single point of failure. Compromise of this address would jeopardize the entire token supply.

UpgradesMedium6/10

The contract is not designed to be upgradeable, which eliminates all risks associated with upgrade mechanisms, such as proxy implementation bugs, storage collisions, or improper upgrade paths (7.7 Upgrades). This provides a fixed and immutable contract logic. As the contract is not upgradeable, any discovered vulnerabilities or desired feature enhancements would require a new deployment and migration, which can be a complex and costly process.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

88.1% in top 10
10.3% in wallets77.8% in contracts
Effective Concentration41.5%

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

$274.5K across 10 pairs
Pancakeswap v3WBNBanalysed$240.5K87.6%UniswapUSDT$27.4K10.0%UniswapUSDT$5.6K2.0%Pancakeswap v3USDT$8330.3%Pancakeswap v3WBNB$1570.1%UniswapUSDT$190.0%
Show 4 more pairsShow less
Pancakeswap v2Subject 3$30.0%Pancakeswap v2WBNB$20.0%Pancakeswap v3WBNB$00.0%Pancakeswap v2USDT$00.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 Holder28.1%
Top-3 Unlocked55.0%

Key Addresses

11 addresses
Deployer
0x8eeb…f45b
Unlocked LP Held By
0x0266…24130x467b…71320x7226…46bc0xd34d…c1ab0x7b0d…145c0xd601…ea770x0ae4…103b0x3262…f28a0xa86d…dfc30xef7c…22c2

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

What Raised This Score

5 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (88.1% total → 41.5% effective; 10.3% in EOAs, 77.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 High finding(s) from audit
  • 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
AsterMedium RiskBluwhale AI (BLUAI)Medium RiskTaleX (X)Medium RiskPeaqOFT (PEAQ)Medium Risk施工猫 (SUE)Medium RiskmubarakMedium Risk

Would You Like a More Detailed Audit of MYX?

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

Get Detailed Audit