Quantum Audit Logo

Is MOO DENG Safe?

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

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

MOO DENG MOODENG
0x2856…bcad
Ethereum Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The `token` contract implements an ERC-20 standard with custom taxation, anti-bot, and anti-whale mechanisms. While it uses `SafeMath` for arithmetic safety, it exhibits critical centralization risks. The owner possesses extensive control over vital parameters, including the ability to halt trading or manipulate token economics, posing a severe risk to user funds and the token's utility. The anti-bot features, while intended for protection, are also centrally controlled and can be misused.

1 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$47.4K
Liquidity
$523.9K
Price
$0.000004189
Token Age
1y
Top 10 Holders
41.7%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Owner Privileges and Centralization Risk

C-01The contract owner possesses extensive control over critical token parameters, including the ability to set taxes (`setInitialBuyTax`, `setFinalSellTax`), transaction limits (`setMaxTxAmount`, `setMaxWalletSize`), manage bot lists (`addBot`, `delBot`), and enable/disable trading and swapping (`openTrading`, `setSwapEnabled`). This high degree of centralization allows the owner to manipulate the token's economy, halt trading by setting `_maxTxAmount` or `_maxWalletSize` to zero, or even redirect collected taxes by changing `_taxWallet`. A compromised owner key or a malicious owner could lead to a complete loss of user funds or render the token untradable.
IssueThe contract owner possesses extensive control over critical token parameters, including the ability to set taxes (`setInitialBuyTax`, `setFinalSellTax`), transaction limits (`setMaxTxAmount`, `setMaxWalletSize`), manage bot lists (`addBot`, `delBot`), and enable/disable trading and swapping (`openTrading`, `setSwapEnabled`). This high degree of centralization allows the owner to manipulate the token's economy, halt trading by setting `_maxTxAmount` or `_maxWalletSize` to zero, or even redirect collected taxes by changing `_taxWallet`. A compromised owner key or a malicious owner could lead to a complete loss of user funds or render the token untradable.
FixImplement a multi-signature wallet for ownership or transition to a decentralized governance model. For highly sensitive functions, consider adding a time-lock mechanism to allow users to react to pending changes. Clearly communicate the extent of owner privileges to the community.
StatusUnresolved
High

Anti-Bot/Anti-Whale Mechanisms with Centralized Control

H-01The contract includes anti-bot (`bots` mapping) and anti-whale (`_maxTxAmount`, `_maxWalletSize`, `sellCount` per block) mechanisms. While intended to protect against manipulation, these features are centrally controlled by the owner. The owner can arbitrarily add or remove addresses from the `bots` list, potentially blocking legitimate users. The `sellCount` limit per block can restrict users' ability to sell their desired amount, and can be circumvented by using multiple addresses. These mechanisms introduce subjective control and potential for abuse, impacting fair market operations and user liquidity.
IssueThe contract includes anti-bot (`bots` mapping) and anti-whale (`_maxTxAmount`, `_maxWalletSize`, `sellCount` per block) mechanisms. While intended to protect against manipulation, these features are centrally controlled by the owner. The owner can arbitrarily add or remove addresses from the `bots` list, potentially blocking legitimate users. The `sellCount` limit per block can restrict users' ability to sell their desired amount, and can be circumvented by using multiple addresses. These mechanisms introduce subjective control and potential for abuse, impacting fair market operations and user liquidity.
FixRe-evaluate the necessity and implementation of these mechanisms. If retained, consider decentralizing control over the `bots` list through a community vote or a transparent, auditable process. Ensure that `_maxTxAmount` and `_maxWalletSize` are set to reasonable values that do not unduly restrict legitimate trading. Clearly document the behavior and limitations of these features.
StatusUnresolved
Medium

High Initial Transaction Taxes

M-01The contract is configured with high initial buy and sell taxes of 21% (`_initialBuyTax`, `_initialSellTax`). While these taxes are designed to reduce after certain `_buyCount` thresholds (`_reduceBuyTaxAt`, `_reduceSellTaxAt`), such high initial rates can deter early adoption, reduce trading volume, and create a perception of a 'honeypot' or an unsustainable economic model. This could negatively impact the token's liquidity and overall market health.
IssueThe contract is configured with high initial buy and sell taxes of 21% (`_initialBuyTax`, `_initialSellTax`). While these taxes are designed to reduce after certain `_buyCount` thresholds (`_reduceBuyTaxAt`, `_reduceSellTaxAt`), such high initial rates can deter early adoption, reduce trading volume, and create a perception of a 'honeypot' or an unsustainable economic model. This could negatively impact the token's liquidity and overall market health.
FixConsider lowering the initial tax rates to more standard levels (e.g., 5-10%) to encourage early trading and adoption. Clearly communicate the tax structure, including initial rates and reduction thresholds, to potential investors. Monitor the impact of tax rates on trading volume and adjust as necessary through a controlled governance process.
StatusUnresolved
Low

Front-running of `openTrading` Function

L-01The `openTrading()` function, which enables transfers by setting `tradingOpen = true`, can be front-run. Malicious actors or bots can monitor the transaction pool for the `openTrading()` call and submit their own buy transactions with a higher gas price to be among the first to trade the token. This allows them to gain an unfair advantage in early trading, potentially buying at a lower price before wider market participation.
IssueThe `openTrading()` function, which enables transfers by setting `tradingOpen = true`, can be front-run. Malicious actors or bots can monitor the transaction pool for the `openTrading()` call and submit their own buy transactions with a higher gas price to be among the first to trade the token. This allows them to gain an unfair advantage in early trading, potentially buying at a lower price before wider market participation.
FixWhile this is a common characteristic of new token launches and not a direct vulnerability in the contract's logic, projects should be aware of this risk. Consider alternative launch mechanisms or clearly communicate the launch strategy to manage community expectations. No direct code change is typically required for this inherent market dynamic.
StatusUnresolved
Info

Implications of Renouncing Ownership

I-01The contract includes a `renounceOwnership()` function, which allows the current owner to transfer ownership to the zero address. If ownership is renounced, all functions protected by the `onlyOwner` modifier become permanently inaccessible. This means that critical parameters such as tax rates, transaction limits, wallet limits, and the bot list can never be changed, and any potential issues or desired updates cannot be addressed. While this increases decentralization, it also removes any ability to adapt or mitigate future problems.
IssueThe contract includes a `renounceOwnership()` function, which allows the current owner to transfer ownership to the zero address. If ownership is renounced, all functions protected by the `onlyOwner` modifier become permanently inaccessible. This means that critical parameters such as tax rates, transaction limits, wallet limits, and the bot list can never be changed, and any potential issues or desired updates cannot be addressed. While this increases decentralization, it also removes any ability to adapt or mitigate future problems.
FixIf the intention is to renounce ownership, ensure that all critical parameters are set to their final, desired state before renunciation. Clearly communicate the implications of renouncing ownership to the community, emphasizing that the contract will become immutable and unmanageable by any single entity.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract utilizes `SafeMath` to prevent integer overflows/underflows, which is a strong security practice (7.2 Code Security). However, the architecture grants the owner highly centralized control over critical functions and parameters, such as `setMaxTxAmount` and `setInitialBuyTax` (7.1 Architecture, 7.3 Access Control). This extensive control introduces a high technical risk, as a compromised owner key could lead to severe operational issues or fund manipulation.

GovernanceLow8/10

The economic model incorporates initial buy and sell taxes (21%) which can be reduced based on `_buyCount` thresholds (7.4 Economic). While this provides flexibility, the initial high taxes could deter legitimate trading. The governance model is highly centralized, with the owner having unilateral control over all key economic parameters, including `_maxTxAmount`, `_maxWalletSize`, and the `bots` list (7.5 Governance). This centralization, coupled with the ability to arbitrarily block users or halt trading, presents a significant economic and governance risk.

UpgradesLow9/10

The contract is not designed with an upgrade mechanism (e.g., proxy pattern) (7.7 Upgrades). This means the contract's logic is immutable once deployed. While this eliminates risks associated with upgradeability (like proxy misconfigurations or malicious upgrades), it also means that any discovered vulnerabilities or desired feature changes cannot be implemented without a new deployment and migration.

Security Checklist

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

Holder Composition

41.7% in top 10
19.7% in wallets22.0% in contracts
Effective Concentration28.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

$525.0K across 3 pairs
Uniswap v2WETHanalysed$523.9K99.8%Uniswap v3WETH$1.0K0.2%

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 Burned99.4% · ≈ permanent lock
LP Locked99.4% · Null Address

Key Addresses

7 addresses
Deployer
0xed06…491a
Unlocked LP Held By
0x3f3b…05140x826f…1e650xb3ac…68a00x0000…8a900xaeff…db9a0x1f2f…f387

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

What Raised This Score

5 factors
  • Top-10 concentration > 20% (41.7% total → 28.5% effective; 19.7% in EOAs, 22.0% in contracts — mild)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium 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
4CHANLow RiskUnity Software (UNITY)Low RiskHEXLow RiskWrapped liquid staked Ether 2.0 (WSTETH)Low RiskManyuLow RiskRektLow Risk

Would You Like a More Detailed Audit of MOO DENG?

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

Get Detailed Audit