Quantum Audit Logo

Is Manyu Safe?

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

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

Manyu MANYU
0x95af…24ce
Ethereum Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

This audit was conducted on an incomplete set of Solidity source code. Only the `SafeMath` library and `IERC20` interface were provided. The core contract logic, identified as 'Manyu' in prefill data, is missing. Therefore, a comprehensive security assessment of the protocol's functionality, economic model, and access control mechanisms could not be performed. The overall risk is assessed as Critical due to this significant lack of information, as the actual deployed contract's behavior and security posture remain largely unknown.

1 Critical3 High1 Informational
Volume 24h
$117.5K
Liquidity
$606.7K
Price
$0.0000000049
Token Age
1y
Top 10 Holders
22.3%

Security Findings

Critical

Missing Core Contract Source Code

C-01The provided source code only includes the `SafeMath` library and `IERC20` interface. The main contract implementation (e.g., the 'Manyu' token contract) is entirely missing. This prevents any meaningful security analysis of the deployed contract's logic, state variables, functions, and interactions, making a comprehensive audit impossible.
IssueThe provided source code only includes the `SafeMath` library and `IERC20` interface. The main contract implementation (e.g., the 'Manyu' token contract) is entirely missing. This prevents any meaningful security analysis of the deployed contract's logic, state variables, functions, and interactions, making a comprehensive audit impossible.
FixProvide the complete and verified source code for the deployed contract () to allow for a comprehensive security audit. Without this, users cannot independently verify the contract's behavior or security, leading to a critical trust deficit.
StatusUnresolved
High

Inability to Assess Access Control Mechanisms

H-01Without the full source code, it is impossible to evaluate the contract's access control mechanisms. This includes identifying privileged roles (e.g., owner, admin), verifying proper authorization checks (e.g., `onlyOwner`), and assessing potential centralization risks or single points of failure (7.3 Access Control). This lack of visibility poses a high risk of unauthorized actions or control.
IssueWithout the full source code, it is impossible to evaluate the contract's access control mechanisms. This includes identifying privileged roles (e.g., owner, admin), verifying proper authorization checks (e.g., `onlyOwner`), and assessing potential centralization risks or single points of failure (7.3 Access Control). This lack of visibility poses a high risk of unauthorized actions or control.
FixProvide the complete source code to allow for a thorough review of all access control implementations and ensure they align with security best practices and the project's stated decentralization goals.
StatusUnresolved
High

Inability to Assess Economic Model and Tokenomics

H-02The absence of the main contract's source code prevents any analysis of the token's economic model, including supply mechanisms, minting/burning functions, fee structures, staking rewards, or other tokenomics features (7.4 Economic). This leaves potential vulnerabilities like uncontrolled inflation, deflationary spirals, or rug pull vectors unidentifiable, posing a high risk to token holders.
IssueThe absence of the main contract's source code prevents any analysis of the token's economic model, including supply mechanisms, minting/burning functions, fee structures, staking rewards, or other tokenomics features (7.4 Economic). This leaves potential vulnerabilities like uncontrolled inflation, deflationary spirals, or rug pull vectors unidentifiable, posing a high risk to token holders.
FixSubmit the full contract source code for review to enable a comprehensive assessment of the economic model, ensuring its stability, fairness, and resistance to manipulation.
StatusUnresolved
High

Inability to Assess Upgradeability and Operational Risks

H-03The provided code does not reveal any upgradeability patterns or operational controls. Consequently, it's impossible to determine if the contract is upgradeable, how upgrades are managed, or if emergency functions (e.g., pause, emergency withdrawal) exist and are properly secured (7.7 Upgrades, 7.8 Operations). This introduces significant unknown risks regarding future changes and emergency response capabilities.
IssueThe provided code does not reveal any upgradeability patterns or operational controls. Consequently, it's impossible to determine if the contract is upgradeable, how upgrades are managed, or if emergency functions (e.g., pause, emergency withdrawal) exist and are properly secured (7.7 Upgrades, 7.8 Operations). This introduces significant unknown risks regarding future changes and emergency response capabilities.
FixProvide the complete source code to allow for an assessment of any upgradeability patterns (e.g., proxy implementations) and operational controls, ensuring they are robust, transparent, and secure.
StatusUnresolved
Info

Redundant SafeMath Usage in Solidity 0.8.x

I-01The contract uses a `SafeMath` library. While `SafeMath` is crucial for preventing integer overflow/underflow in Solidity versions prior to 0.8.0, Solidity 0.8.0 and later versions (like 0.8.19 used here) include built-in overflow and underflow checks by default for all arithmetic operations. The `add`, `sub`, `mul`, `div`, `mod` functions in the provided `SafeMath` library that do not take an `errorMessage` parameter are effectively redundant as they simply wrap native operators that already revert on overflow/underflow. The `try*` functions and those with `errorMessage` parameters correctly use `unchecked` blocks and `require` statements, respectively.
IssueThe contract uses a `SafeMath` library. While `SafeMath` is crucial for preventing integer overflow/underflow in Solidity versions prior to 0.8.0, Solidity 0.8.0 and later versions (like 0.8.19 used here) include built-in overflow and underflow checks by default for all arithmetic operations. The `add`, `sub`, `mul`, `div`, `mod` functions in the provided `SafeMath` library that do not take an `errorMessage` parameter are effectively redundant as they simply wrap native operators that already revert on overflow/underflow. The `try*` functions and those with `errorMessage` parameters correctly use `unchecked` blocks and `require` statements, respectively.
FixConsider removing the `SafeMath` library for basic arithmetic operations in Solidity 0.8.x and above, relying on the native overflow/underflow checks. If custom error messages or explicit `unchecked` blocks are desired, ensure they are used judiciously where gas optimization is critical and safety is guaranteed by other means.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The provided source code consists only of a `SafeMath` library and an `IERC20` interface. The `SafeMath` library is a standard, well-tested component, correctly implementing arithmetic operations with overflow/underflow checks or `unchecked` blocks where appropriate (7.2 Code Security). However, the absence of the main contract's implementation (e.g., the 'Manyu' token contract) prevents any assessment of its architecture, specific vulnerabilities, or adherence to best practices (7.1 Architecture). Crucially, the contract's access control mechanisms (7.3 Access Control) cannot be evaluated, leaving potential centralization risks unknown. Therefore, the technical security of the actual deployed contract remains largely unknown.

GovernanceMedium6/10

Without the main contract's source code, it is impossible to assess any economic model, tokenomics, fee structures, or governance mechanisms (7.4 Economic, 7.5 Governance). This means potential risks related to inflation, deflation, rug pulls, or centralized control cannot be identified. Furthermore, any external interactions or dependencies (7.6 External) are also unknown, posing significant unquantifiable risks to the protocol's stability and user funds. The lack of visibility into these critical areas prevents a comprehensive economic and governance risk assessment.

UpgradesLow9/10

The provided code does not include any proxy or upgradeable contract patterns, nor does it reveal operational controls. Consequently, it is impossible to determine if the contract is upgradeable, what upgrade mechanisms are in place, or what risks might be associated with potential upgrades (7.7 Upgrades). Similarly, the operational aspects (7.8 Operations) such as pause functions, emergency shutdowns, or administrative privileges are entirely unknown. This introduces significant unquantifiable risks regarding future changes, emergency response capabilities, and the overall long-term maintainability of the contract.

Security Checklist

Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

12.6% in wallets9.7% in contracts
Effective Concentration16.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

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 Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

Deployer
0x6981…a6ae
Unlocked LP Held By
0xc1f2…a6d30x1502…8bba0xa0ac…8e830x2bf8…bd2f0x1f2f…f3870x6a21…96710x9b02…8ad2

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

What Raised This Score

  • 1 Critical finding(s) from audit
  • 3 High 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

RektLow RiskXEN Crypto (XEN)Low RiskWrapped liquid staked Ether 2.0 (WSTETH)Low RiskEthereumcat (ETHCAT)Low RiskHEXLow RiskPepes Dog (ZEUS)Low Risk

Would You Like a More Detailed Audit of Manyu?

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

Get Detailed Audit