Quantum Audit Logo
Launch App

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

Is Monkey Safe?

MONKEYBNB Chain
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades4/10Checks passed5 of 5Findings2 Critical · 1 High · 2 Low · 2 Info7
SummaryAI Copilot

The audit of the Monkey Token contract identified critical vulnerabilities that prevent proper deployment and functionality.

Read the full analysis
What raised the score
  • Top-10 concentration > 70%
  • LP top1 unlocked holder = 97.0%
  • LP top3 unlocked holders = 99.5%
  • LP claimed locked but only 0.0% actually locked
  • Token age < 30 days
  • 2 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 70% (100.0% total → 100.0% effective; 100.0% in EOAs, 0.0% in contracts — extreme)
  • LP top1 unlocked holder = 97.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 99.5% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP claimed locked but only 0.0% actually locked
  • Token age < 30 days (still settling)
  • 2 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
100.0%Wallets
100.0%Wallets
WalletsBubble area = share of supply
100.0%of supply sits with the top 10 holders
  • Walletsanonymous holders, free to sell100.0%
Effective concentrationwhat the score reads100.0%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$74.1K across 6 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$73.3KShare of depth98.9%
Top-1 Unlocked Holder97.0%
Top-3 Unlocked99.5%
Unlocked LP held by
0x565e…fc550x1c1f…12dc0x06a0…c0a80x0ed9…97060xa43f…438e

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

Security Findings

2 Critical1 High2 Low2 Info
Critical

Uninitialized Owner in Ownable Contract

The _owner variable in the Ownable contract is not initialized in the constructor of the Token contract. As a result, _owner defaults to address(0). This renders all functions protected by the onlyOwner modifier, such as transferOwnership and waiveOwnership, permanently inaccessible to any legitimate owner.C-01

Issue

The _owner variable in the Ownable contract is not initialized in the constructor of the Token contract. As a result, _owner defaults to address(0). This renders all functions protected by the onlyOwner modifier, such as transferOwnership and waiveOwnership, permanently inaccessible to any legitimate owner.

Fix

Initialize the _owner variable in the Token contract's constructor to a trusted address, for example: constructor() Ownable(msg.sender) { ... } (if Ownable supports constructor initialization) or _owner = msg.sender;.

Status

Unresolved

Critical

Total Supply Value Exceeds uint256 Maximum

The _totalSupply is set to 10000000000000000000000000000000000000000000000000000000000000000000000000000 (10^80). This value exceeds the maximum capacity of a uint256 variable, which is approximately 1.15 * 10^77. Attempting to deploy the contract with this value will cause the transaction to revert due to an integer overflow during assignment.C-02

Issue

The _totalSupply is set to 10000000000000000000000000000000000000000000000000000000000000000000000000000 (10^80). This value exceeds the maximum capacity of a uint256 variable, which is approximately 1.15 * 10^77. Attempting to deploy the contract with this value will cause the transaction to revert due to an integer overflow during assignment.

Fix

Adjust the _totalSupply value to be within the valid range for uint256. Ensure the chosen supply aligns with the project's intended tokenomics and consider the impact of _decimals being 0.

Status

Unresolved

High

Ether Locked in Contract

The contract includes a receive() function, allowing it to accept Ether. However, there is no corresponding function to withdraw this Ether. Due to the critical issue of the uninitialized _owner (C-01), no administrative functions can be called, meaning any Ether sent to the contract will be permanently locked and inaccessible.H-01

Issue

The contract includes a receive() function, allowing it to accept Ether. However, there is no corresponding function to withdraw this Ether. Due to the critical issue of the uninitialized _owner (C-01), no administrative functions can be called, meaning any Ether sent to the contract will be permanently locked and inaccessible.

Fix

Implement a withdrawEther function, protected by the onlyOwner modifier, to allow the owner to retrieve any Ether sent to the contract. This requires first resolving the uninitialized owner issue (C-01).

Status

Unresolved

Low

Redundant Public Getter for _owner

The _owner state variable is declared as public, which automatically creates a public getter function. The contract also explicitly defines a owner() public view function that returns the same _owner value. This creates a redundant getter.L-01

Issue

The _owner state variable is declared as public, which automatically creates a public getter function. The contract also explicitly defines a owner() public view function that returns the same _owner value. This creates a redundant getter.

Fix

Remove the explicit owner() function as the compiler-generated getter for the public _owner variable is sufficient.

Status

Unresolved

Low

Unnecessary this; Statement

The _msgData() function in the Context abstract contract contains the statement this;. This statement has no functional effect and can be removed without altering the contract's behavior.L-02

Issue

The _msgData() function in the Context abstract contract contains the statement this;. This statement has no functional effect and can be removed without altering the contract's behavior.

Fix

Remove the this; statement from the _msgData() function to improve code clarity.

Status

Unresolved

Info

Hardcoded Developer Address

The _dev address, which receives the initial token supply, is hardcoded in the constructor. This means the address cannot be changed after deployment without redeploying the contract.I-01

Issue

The _dev address, which receives the initial token supply, is hardcoded in the constructor. This means the address cannot be changed after deployment without redeploying the contract.

Fix

Consider making the initial recipient address configurable via a constructor argument to allow for more flexibility and easier deployment to different environments or with different initial distributions.

Status

Unresolved

Info

Zero Decimals for ERC-20 Token

The _decimals variable is set to 0. This means the token is non-divisible, and all transfers must be in whole token units. While a valid design choice, it is unusual for most ERC-20 tokens and may lead to unexpected behavior or integration challenges with wallets, exchanges, or DeFi protocols that expect tokens to have at least 18 decimals.I-02

Issue

The _decimals variable is set to 0. This means the token is non-divisible, and all transfers must be in whole token units. While a valid design choice, it is unusual for most ERC-20 tokens and may lead to unexpected behavior or integration challenges with wallets, exchanges, or DeFi protocols that expect tokens to have at least 18 decimals.

Fix

Ensure that the decision to use zero decimals is intentional and clearly communicated to users and integrators. If divisibility is desired, adjust the _decimals value accordingly (e.g., to 18).

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The audit of the Monkey Token contract identified critical vulnerabilities that prevent proper deployment and functionality. The _totalSupply value exceeds the maximum capacity of uint256, causing deployment failure. Additionally, the contract owner is not initialized, rendering all onlyOwner functions inaccessible and leading to permanently locked Ether if sent to the contract. Several minor code quality issues and unusual token parameters were also noted.

Technical4/10Medium risk

The contract utilizes standard libraries like SafeMath and Address, which generally contribute to robust code security (7.2). However, two critical flaws severely impact the contract's integrity. Firstly, the _totalSupply value (10^80) exceeds the maximum capacity of uint256, which will cause the contract deployment to revert (7.2). Secondly, the _owner variable in the Ownable implementation is not initialized in the constructor, defaulting to address(0), rendering all onlyOwner functions permanently inaccessible (7.3). This also leads to Ether sent to the contract being permanently locked due to the lack of a callable withdrawal mechanism (7.2).

Governance1/10High risk

The token's economic model (7.4) features an intended extremely large total supply combined with zero decimals. While the _totalSupply value itself is critically flawed, this design choice, if corrected, could lead to display issues or integration challenges with platforms expecting typical ERC-20 divisibility. The initial token distribution is hardcoded to a specific development address (7.5). The critical uninitialized owner issue severely impacts any potential governance or administrative control over the contract (7.5).

Upgrades4/10Medium risk

The contract is not designed with upgradeability in mind (7.7), meaning its logic cannot be modified after deployment. This eliminates upgrade-related risks but also prevents future bug fixes or feature enhancements without a new deployment.

Final RecommendationWhat to do about this score

It is critical to correct the _totalSupply value to be within the uint256 range and ensure it aligns with the intended tokenomics.

The _owner variable must be initialized in the constructor to a trusted address to enable proper access control for Ownable functions. A withdrawal function should be implemented, accessible only by the owner, to manage any Ether sent to the contract. Additionally, carefully review the chosen _decimals value to ensure it aligns with the project's intended economic model and avoids potential integration issues.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age9d
Contract0x684a…c276
Deployer0x6713…6d73
Badge for your website
Monkey security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202690Critical
  2. Aug 14, 202689Critical

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the MONKEY contract address?

The Monkey contract on BNB Chain is 0x684a1768c8d0098811017b7812c23978dd58c276. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Monkey a scam?

Quantum Audit's risk score for Monkey is 90/100 (Critical risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is MONKEY liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $74.1K.

Who holds MONKEY?

As of Sep 4, 2026, the 10 largest holders own 100.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
MonkeyBNB Chain90CriticalInvesqo QQQQQQB · BNB Chain89CriticalCircle Internet Group Inc.CRCLB · BNB Chain91CriticalWIKI CATWKC · BNB Chain87CriticalTether GoldXAUT · BNB Chain87CriticalETHGasGWEI · BNB Chain94Critical

Would You Like a More Detailed Audit of Monkey?

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

Get Detailed Audit Is this your token? Publish your own audit on this page