Quantum Audit Logo
Launch App

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

Is I love puppies Safe?

PUPPIESEthereum
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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance6/10Upgrades8/10Checks passed5 of 5Findings2 Critical · 2 High · 2 Medium · 1 Low · 1 Info8
SummaryAI Copilot

The puppies token contract implements a standard ERC-20 interface with custom tax mechanisms, anti-bot features, and liquidity management.

Read the full analysis
What raised the score
  • 2 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • 2 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 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

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
6.6%6.2%87.3%Everyone else
6.6%6.2%87.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
12.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking6.6%
  • Walletsanonymous holders, free to sell6.2%
  • Everyone elsethe rest of the supply87.3%
Effective concentrationwhat the score reads8.8%
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$907.9K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$907.9KShare of depth100.0%
LP Burned97.1% · ≈ permanent lock
LP Locked97.1%
Unlocked LP held by
0x6c7a…458c0x8f3c…79350x62b3…fcce0x1dd7…055c0xb884…1b230x72dc…ef140xfc14…791b0x5df0…19ed0x89aa…f529

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

Security Findings

2 Critical2 High2 Medium1 Low1 Info
Critical

Excessive Centralized Control by Owner

The contract owner possesses extensive privileges, including the ability to set initial and final buy/sell taxes, reduce tax thresholds, modify maximum transaction and wallet sizes, exclude/include addresses from fees, and manage a 'bots' blacklist. This level of control allows the owner to unilaterally alter the token's economics and restrict user interactions, posing a significant risk of manipulation or a 'rug pull' scenario. For example, the owner can set taxes to 100% or blacklist all users, effectively trapping funds.C-01

Issue

The contract owner possesses extensive privileges, including the ability to set initial and final buy/sell taxes, reduce tax thresholds, modify maximum transaction and wallet sizes, exclude/include addresses from fees, and manage a 'bots' blacklist. This level of control allows the owner to unilaterally alter the token's economics and restrict user interactions, posing a significant risk of manipulation or a 'rug pull' scenario. For example, the owner can set taxes to 100% or blacklist all users, effectively trapping funds.

Fix

Implement a timelock for all critical owner-controlled functions to introduce a delay before changes take effect, allowing users to react. Consider decentralizing control over key parameters through a multi-signature wallet or a community governance mechanism. Clearly document all owner privileges and their intended use.

Status

Unresolved

Critical

Tax Wallet Draining and Lack of Liquidity Growth

The contract's tax mechanism swaps collected tokens for ETH and then sends this ETH directly to the _taxWallet (controlled by the owner) via sendETHToFee. There is no provision to add this ETH back to the liquidity pool. This design means that all collected taxes are effectively siphoned off to the owner's wallet, leading to a gradual drain of value from the token's liquidity pool over time. This can severely impact the token's price stability and is a common pattern in 'rug pull' schemes.C-02

Issue

The contract's tax mechanism swaps collected tokens for ETH and then sends this ETH directly to the _taxWallet (controlled by the owner) via sendETHToFee. There is no provision to add this ETH back to the liquidity pool. This design means that all collected taxes are effectively siphoned off to the owner's wallet, leading to a gradual drain of value from the token's liquidity pool over time. This can severely impact the token's price stability and is a common pattern in 'rug pull' schemes.

Fix

Modify the tax mechanism to allocate a portion or all of the collected ETH to reinforce the liquidity pool (e.g., by pairing it with tokens and adding it to Uniswap). Alternatively, if the ETH is intended for project development, it should be sent to a transparent, multi-signature treasury with clear spending policies and public reporting.

Status

Unresolved

High

Abuse Potential of Anti-Bot/Anti-Whale Mechanisms

The _maxTxAmount, _maxWalletSize, and bots mapping are intended to prevent malicious bot activity and whale manipulation. However, these parameters are fully controllable by the owner. The owner can arbitrarily set these limits to extremely low values or add legitimate user addresses to the bots list, effectively preventing users from buying, selling, or holding tokens, thereby trapping their funds or manipulating market dynamics.H-01

Issue

The _maxTxAmount, _maxWalletSize, and bots mapping are intended to prevent malicious bot activity and whale manipulation. However, these parameters are fully controllable by the owner. The owner can arbitrarily set these limits to extremely low values or add legitimate user addresses to the bots list, effectively preventing users from buying, selling, or holding tokens, thereby trapping their funds or manipulating market dynamics.

Fix

If these mechanisms are deemed necessary, consider making the _maxTxAmount and _maxWalletSize immutable after a certain period or subject to a timelock. The bots mapping should be managed with extreme caution and transparency, ideally with a multi-signature wallet or community oversight, and clear criteria for inclusion/exclusion.

Status

Unresolved

High

Initial Trading Restrictions and Manipulation Risk

The contract includes _preventSwapBefore, _buyCount, tradingOpen, and swapEnabled flags, all controlled by the owner. Trading is initially closed and must be opened by the owner. This gives the owner significant control over the initial trading phase, allowing for potential manipulation such as front-running the openTrading call or controlling early price action by selectively enabling/disabling swaps and adjusting taxes.H-02

Issue

The contract includes _preventSwapBefore, _buyCount, tradingOpen, and swapEnabled flags, all controlled by the owner. Trading is initially closed and must be opened by the owner. This gives the owner significant control over the initial trading phase, allowing for potential manipulation such as front-running the openTrading call or controlling early price action by selectively enabling/disabling swaps and adjusting taxes.

Fix

Clearly communicate the intended use and timeline for these initial trading restrictions. Consider making the openTrading function callable only once and making _preventSwapBefore immutable after a certain block number or timestamp. Ensure transparency around the activation of trading and swap functionalities.

Status

Unresolved

Medium

Sell Limit per Block Causes Denial of Service

The _transfer function implements a require(sellCount < 3, "Only 3 sells per block!") restriction. This limits the number of sell transactions that can occur within a single block. While intended to prevent rapid price drops, this mechanism can lead to a denial of service for legitimate users, especially during periods of high market volatility or when many users attempt to sell simultaneously, potentially trapping their tokens.M-01

Issue

The _transfer function implements a require(sellCount < 3, "Only 3 sells per block!") restriction. This limits the number of sell transactions that can occur within a single block. While intended to prevent rapid price drops, this mechanism can lead to a denial of service for legitimate users, especially during periods of high market volatility or when many users attempt to sell simultaneously, potentially trapping their tokens.

Fix

Re-evaluate the necessity and impact of the 'sells per block' limit. If a limit is critical, consider alternative mechanisms that are less prone to denial of service, such as a cooldown period per wallet or a dynamic limit based on liquidity. Ensure that any such mechanism does not disproportionately affect smaller holders or create an unfair selling environment.

Status

Unresolved

Medium

Lack of Event Emission for Critical Parameter Changes

Many onlyOwner functions that modify critical contract parameters, such as setInitialBuyTax, setMaxTxAmount, setMaxWalletSize, and setBots, do not emit corresponding events. This lack of event emission makes it difficult for external parties (e.g., users, block explorers, monitoring tools) to track changes to the contract's operational parameters on-chain, reducing transparency and auditability.M-02

Issue

Many onlyOwner functions that modify critical contract parameters, such as setInitialBuyTax, setMaxTxAmount, setMaxWalletSize, and setBots, do not emit corresponding events. This lack of event emission makes it difficult for external parties (e.g., users, block explorers, monitoring tools) to track changes to the contract's operational parameters on-chain, reducing transparency and auditability.

Fix

Emit specific events for every function that modifies a critical contract parameter. These events should include the old and new values of the parameter, along with the address of the caller and a timestamp, to provide a clear and auditable history of changes.

Status

Unresolved

Low

Hardcoded Uniswap Router Address in openTrading

The Uniswap V2 Router address (0x7a25…488D) is hardcoded within the openTrading function. While this is a common and stable address for Uniswap V2 on Ethereum mainnet, hardcoding can be inflexible if the router address ever changes or if the contract were to be deployed on a different network where this address is invalid.L-01

Issue

The Uniswap V2 Router address () is hardcoded within the openTrading function. While this is a common and stable address for Uniswap V2 on Ethereum mainnet, hardcoding can be inflexible if the router address ever changes or if the contract were to be deployed on a different network where this address is invalid.

Fix

Consider making the Uniswap router address configurable by the owner (e.g., via a setRouter function) or setting it in the constructor. If the contract is intended for a single network, ensure the hardcoded address is correct for that network. For multi-chain deployments, a configurable address is essential.

Status

Unresolved

Info

Redundant Use of SafeMath in Solidity 0.8.x

The contract explicitly uses the SafeMath library for arithmetic operations. While SafeMath is crucial for preventing integer overflow/underflow in older Solidity versions (prior to 0.8.0), Solidity 0.8.x and later versions include native overflow and underflow checks by default. Therefore, the explicit use of SafeMath for basic operations like add, sub, mul, and div is largely redundant and adds unnecessary gas cost and code complexity.I-01

Issue

The contract explicitly uses the SafeMath library for arithmetic operations. While SafeMath is crucial for preventing integer overflow/underflow in older Solidity versions (prior to 0.8.0), Solidity 0.8.x and later versions include native overflow and underflow checks by default. Therefore, the explicit use of SafeMath for basic operations like add, sub, mul, and div is largely redundant and adds unnecessary gas cost and code complexity.

Fix

For Solidity 0.8.x and above, consider removing the SafeMath library and relying on the compiler's native overflow/underflow checks. This can reduce gas costs and simplify the codebase without compromising security for standard arithmetic. Ensure all custom or complex arithmetic logic is still thoroughly reviewed for potential edge cases.

Status

Unresolved

Analysis

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

The puppies token contract implements a standard ERC-20 interface with custom tax mechanisms, anti-bot features, and liquidity management. The contract exhibits a high degree of centralization, with the owner possessing extensive control over critical parameters such as tax rates, transaction limits, and the ability to blacklist addresses. A significant concern is the mechanism for handling collected taxes, where ETH is sent directly to a designated wallet rather than being used to bolster liquidity, posing a substantial economic risk. While some security patterns like SafeMath and reentrancy guards are present, the overarching centralized control introduces critical vulnerabilities.

Technical4/10Medium risk

The contract utilizes SafeMath for arithmetic operations, which is a good practice, although less critical in Solidity 0.8.x. A lockTheSwap modifier is implemented to prevent reentrancy during token swaps (7.2 Code Security). However, the contract includes mechanisms like a 'sell limit per block' and 'initial trading restrictions' that can lead to denial of service for legitimate users (7.2 Code Security). The sendETHToFee function directly transfers the contract's ETH balance to the tax wallet, which could fail if the recipient is a contract without a payable fallback, though it's declared as payable address.

Governance6/10Medium risk

The contract exhibits extreme centralization, with the owner having full control over all critical economic parameters, including tax rates, transaction limits, and wallet size limits (7.3 Access Control, 7.4 Economic). The owner can modify buy and sell taxes, potentially manipulating the token's value and discouraging trading. Crucially, ETH collected from taxes is sent directly to the _taxWallet rather than being added to the liquidity pool, which presents a significant risk of liquidity drain or 'rug pull' (7.4 Economic). The bots mapping and other anti-whale features can be abused by the owner to blacklist legitimate users (7.3 Access Control).

Upgrades8/10Low risk

The contract is not designed with an upgrade mechanism (e.g., proxy pattern), meaning its logic cannot be changed after deployment (7.7 Upgrades). This eliminates upgrade-specific risks but also prevents future bug fixes or feature enhancements without a full redeployment and migration.

Final RecommendationWhat to do about this score

Given the high degree of centralized control and the potential for economic manipulation, it is strongly recommended that potential users exercise extreme caution.

The project team should consider implementing a timelock for critical owner-controlled functions to provide users with a window to react to impending changes. Additionally, a clear and transparent mechanism for managing collected taxes, ideally involving adding them back to the liquidity pool or a community-controlled treasury, would significantly mitigate the current economic risks. All critical parameter changes should emit events for transparency.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age2y
Contract0xcf91…6eb2
Deployer0x6e66…69cd
Badge for your website
I love puppies 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. Aug 6, 202631Low

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

Related Audits

6 more on the recordAll audits
AliensEthereum31LowShiba Inu TreatTREAT · Ethereum31LowSolaxySOLX · Ethereum31LowTAU FATAUFA · Ethereum31LowwojakEthereum30LowBalancerBAL · Ethereum30Low

Would You Like a More Detailed Audit of I love puppies?

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