Is ApeCoin (APE) Safe? Smart Contract Security Analysis

Security Findings

2 Low2 Info

Low

Centralized Initial Token Supply

L-01The `SimpleToken` contract's constructor mints the entire `totalSupply_` to `msg.sender`. This means the deployer address holds 100% of the token supply immediately after deployment. This centralization creates a single point of failure for the token's distribution and control, as a compromise of the deployer's private key would put the entire token supply at risk. (7.3 Access Control, 7.4 Economic)

IssueThe `SimpleToken` contract's constructor mints the entire `totalSupply_` to `msg.sender`. This means the deployer address holds 100% of the token supply immediately after deployment. This centralization creates a single point of failure for the token's distribution and control, as a compromise of the deployer's private key would put the entire token supply at risk. (7.3 Access Control, 7.4 Economic)

FixWhile acceptable for a 'simple' token, for projects requiring broader distribution or enhanced security, consider implementing a more decentralized initial distribution mechanism. This could involve vesting contracts, airdrops, or a multi-signature wallet to hold the initial supply.

StatusUnresolved

Low

Immutability of Token Parameters and Supply

L-02The `SimpleToken` contract sets its name, symbol, decimals, and total supply only during construction. There are no functions for further minting, burning (beyond standard ERC20 transfers), pausing transfers, or modifying any token parameters post-deployment. This design choice makes the token highly predictable and immutable but lacks flexibility for future adjustments, emergency measures, or supply management. (7.1 Architecture, 7.4 Economic)

IssueThe `SimpleToken` contract sets its name, symbol, decimals, and total supply only during construction. There are no functions for further minting, burning (beyond standard ERC20 transfers), pausing transfers, or modifying any token parameters post-deployment. This design choice makes the token highly predictable and immutable but lacks flexibility for future adjustments, emergency measures, or supply management. (7.1 Architecture, 7.4 Economic)

FixUnderstand that this is a design choice for a 'simple' token. If future flexibility (e.g., ability to mint more tokens, implement a burn mechanism, or pause transfers) is desired, the contract would need to be redesigned to include such administrative functions, typically protected by an owner or governance mechanism.

StatusUnresolved

Info

Standard ERC-20 Implementation

I-01The `SimpleToken` contract is a straightforward implementation of the ERC-20 standard, inheriting directly from OpenZeppelin's `ERC20` contract. This adherence to a widely adopted and audited standard ensures compatibility with existing infrastructure and reduces the likelihood of common ERC-20 specific vulnerabilities. (7.1 Architecture)

IssueThe `SimpleToken` contract is a straightforward implementation of the ERC-20 standard, inheriting directly from OpenZeppelin's `ERC20` contract. This adherence to a widely adopted and audited standard ensures compatibility with existing infrastructure and reduces the likelihood of common ERC-20 specific vulnerabilities. (7.1 Architecture)

FixNo recommendation needed. This is a strength of the implementation.

StatusResolved

Info

Safe Use of Unchecked Blocks in OpenZeppelin ERC20

I-02The inherited OpenZeppelin `ERC20` contract correctly utilizes `unchecked` blocks for arithmetic operations (e.g., `_balances[sender] = senderBalance - amount;`) that are preceded by `require` statements ensuring the conditions for safe subtraction (e.g., `require(senderBalance >= amount, ...);`). This pattern is a best practice in Solidity 0.8+ for optimizing gas costs while maintaining safety against integer underflows. (7.2 Code Security)

IssueThe inherited OpenZeppelin `ERC20` contract correctly utilizes `unchecked` blocks for arithmetic operations (e.g., `_balances[sender] = senderBalance - amount;`) that are preceded by `require` statements ensuring the conditions for safe subtraction (e.g., `require(senderBalance >= amount, ...);`). This pattern is a best practice in Solidity 0.8+ for optimizing gas costs while maintaining safety against integer underflows. (7.2 Code Security)

FixNo recommendation needed. This demonstrates good security practices within the inherited library.

StatusResolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is straightforward, extending the robust OpenZeppelin ERC20 contract. Code security (7.2) is high, benefiting from OpenZeppelin's audited implementation which mitigates common vulnerabilities like reentrancy and integer overflows, as seen with safe `unchecked` blocks following `require` checks in `_transfer` and `_burn`. The custom logic in `SimpleToken` is minimal, limited to the constructor, which reduces the attack surface. There are no complex external interactions (7.6) or intricate state transitions that could introduce new technical risks.

GovernanceHigh2/10

The economic model (7.4) of SimpleToken is very basic: a fixed supply minted entirely to the deployer. This design choice makes the token predictable but introduces a single point of failure if the deployer's private key is compromised (L-01). There are no governance mechanisms (7.5) or administrative roles beyond the initial deployment, meaning no functions for pausing, burning, or further minting. This immutability (L-02) ensures stability but removes flexibility for future adjustments or emergency responses, which could be a limitation depending on the project's long-term goals.

UpgradesMedium6/10

The SimpleToken contract is not designed to be upgradeable (7.7). It is deployed as a standard, immutable contract without any proxy patterns (e.g., UUPS, Transparent). This design choice eliminates all risks associated with upgrade mechanisms, such as proxy misconfigurations, storage collisions, or insecure upgrade paths. While it offers no flexibility for future modifications, it ensures the contract's logic remains fixed and predictable post-deployment.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

47.4% in top 10

31.9% in wallets15.5% in contracts

Effective Concentration38.1%

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

$494.9K across 8 pairs

Uniswap v4ETHanalysed$359.8K Uniswap v3WETH$97.5K Uniswap v4USDC$15.0K Uniswap v2WETH$11.1K SushiswapUSDT$5.4K Uniswap v3WETH$4.1K

Show 2 more pairsShow less

SushiswapWETH$1.2K VerseWETH$628

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 Holder66.2%

Top-3 Unlocked98.3%

Key Addresses

11 addresses

Deployer

0x295d…a195

Unlocked LP Held By

0x14f0…54de0x9446…a0d40xb432…c1a00x8b30…adf30xf1cb…9e7e0xb0f9…d61e0x59df…c53a0x2394…37290x8990…d0350x036c…db14

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

What Raised This Score

6 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (47.4% total → 38.1% effective; 31.9% in EOAs, 15.5% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 66.2% (independent LP — depth risk, pool = 73% of DEX liquidity)
LP top3 unlocked holders = 98.3% (independent LP — depth risk, pool = 73% of DEX liquidity)
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 ApeCoin Safe?