Is Monkey Safe? Smart Contract Security Analysis

Security Findings

2 Crit1 High2 Low2 Info

Critical

Uninitialized Owner in Ownable Contract

C-01The `_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.

IssueThe `_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.

FixInitialize 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;`.

StatusUnresolved

Critical

Total Supply Value Exceeds uint256 Maximum

C-02The `_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.

IssueThe `_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.

FixAdjust 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.

StatusUnresolved

High

Ether Locked in Contract

H-01The 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.

IssueThe 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.

FixImplement 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).

StatusUnresolved

Low

Redundant Public Getter for _owner

L-01The `_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.

IssueThe `_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.

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

StatusUnresolved

Low

Unnecessary `this;` Statement

L-02The `_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.

IssueThe `_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.

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

StatusUnresolved

Info

Hardcoded Developer Address

I-01The `_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.

IssueThe `_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.

FixConsider 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.

StatusUnresolved

Info

Zero Decimals for ERC-20 Token

I-02The `_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.

IssueThe `_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.

FixEnsure 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).

StatusUnresolved

Category Ratings

TechnicalMedium4/10

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).

GovernanceHigh1/10

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).

UpgradesMedium4/10

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.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

100.0% in top 10

100.0% in wallets0.0% in contracts

Effective Concentration100.0%

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

$74.1K across 6 pairs

Pancakeswap v2XAUtanalysed$73.3K Pancakeswap v2WBNB$566 Pancakeswap v3USDT$144 Pancakeswap v3WBNB$95 Pancakeswap v2SPCXB$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 Holder97.0%

Top-3 Unlocked99.5%

Key Addresses

6 addresses

Deployer

0x6713…6d73

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.

What Raised This Score

8 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

Is Monkey Safe?

Security Findings

Uninitialized Owner in Ownable Contract

Total Supply Value Exceeds uint256 Maximum

Ether Locked in Contract

Redundant Public Getter for _owner

Unnecessary `this;` Statement

Hardcoded Developer Address

Zero Decimals for ERC-20 Token

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Monkey?