Is Quack AI Token (Q) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Info

High

Centralized Unlimited Minting Authority

H-01The `PeerToken` contract grants an `onlyMinter` role the ability to mint an unlimited quantity of new tokens via the `mint(address _account, uint256 _amount)` function. While the `owner` (a Timelock) can change the `minter` address, the `minter` itself has unchecked power over the token supply. A compromise of the `minter`'s private key or a malicious `minter` could lead to arbitrary token inflation, severely devaluing existing tokens and impacting the protocol's economic stability (7.4 Economic, 7.3 Access Control).

IssueThe `PeerToken` contract grants an `onlyMinter` role the ability to mint an unlimited quantity of new tokens via the `mint(address _account, uint256 _amount)` function. While the `owner` (a Timelock) can change the `minter` address, the `minter` itself has unchecked power over the token supply. A compromise of the `minter`'s private key or a malicious `minter` could lead to arbitrary token inflation, severely devaluing existing tokens and impacting the protocol's economic stability (7.4 Economic, 7.3 Access Control).

FixImplement a more robust control mechanism for the `minter` role. Consider: 1) Using a multi-signature wallet for the `minter` address. 2) Implementing a minting cap (e.g., a maximum total supply or a rate limit for minting). 3) Introducing a time-locked minting approval process requiring multiple parties. 4) If unlimited minting is intended, ensure the `minter`'s operational security is paramount.

StatusUnresolved

Info

Non-Upgradeable Contract

I-01The `PeerToken` contract is deployed directly and does not utilize a proxy pattern, meaning it is not upgradeable (7.7 Upgrades). This implies that its logic cannot be modified or updated after deployment. While this eliminates upgrade-related security risks, it also means that any future bug fixes, feature enhancements, or changes to the token's economic model would require deploying an entirely new contract and migrating users/liquidity.

IssueThe `PeerToken` contract is deployed directly and does not utilize a proxy pattern, meaning it is not upgradeable (7.7 Upgrades). This implies that its logic cannot be modified or updated after deployment. While this eliminates upgrade-related security risks, it also means that any future bug fixes, feature enhancements, or changes to the token's economic model would require deploying an entirely new contract and migrating users/liquidity.

FixThis is an architectural decision. If future flexibility is desired, consider implementing an upgradeable proxy pattern (e.g., UUPS or Transparent Proxy) for future contracts. If immutability is the goal, ensure the current design is thoroughly reviewed and future-proofed.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical implementation of PeerToken is robust, leveraging battle-tested OpenZeppelin contracts for ERC-20, ERC-20Permit, ERC-20Burnable, and Ownable functionalities (7.2 Code Security). Custom logic for the `minter` role is minimal and correctly implements access control via `onlyMinter` and `onlyOwner` modifiers (7.3 Access Control). No common Solidity vulnerabilities such as reentrancy, integer overflows, or front-running opportunities were identified in the custom code (7.2 Code Security).

GovernanceHigh1/10

The contract implements a robust access control system with distinct `owner` and `minter` roles (7.3 Access Control). The `owner` is a Timelock with a 48-hour delay, which significantly enhances governance security by introducing a delay for critical actions like changing the `minter` or transferring ownership (7.5 Governance, 7.8 Operations). However, the `minter` role holds significant power, allowing for an unlimited supply of tokens, which presents a high economic risk if compromised, potentially leading to severe token devaluation (7.4 Economic).

UpgradesMedium5/10

The PeerToken contract is not designed as an upgradeable proxy (7.7 Upgrades). This eliminates upgrade-related risks such as proxy implementation mismatches or storage collisions. However, it also means that the contract's logic cannot be modified or updated after deployment, requiring a new deployment for any future changes or bug fixes.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Liquidity Depth

$1.04M across 4 pairs

Pancakeswap v3USDTanalysed$993.9K Pancakeswap v3USDT$45.4K UniswapUSDT$5.3K Pancakeswap v2WBNB$26

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.5%

Top-3 Unlocked100.0%

Key Addresses

4 addresses

Deployer

0x1a28…7af4

Unlocked LP Held By

0xf949…02980x0141…ba140x15bf…f86c

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

What Raised This Score

7 factors

Ownership NOT renounced — Timelock 48h delay (exit window)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 70% (154.3% total → 152.1% effective; 150.7% in EOAs, 3.6% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 97.5% (independent LP — depth risk, pool = 95% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
1 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

Is Quack AI Token Safe?