Quantum Audit Logo

Is I love puppies Safe?

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

Is this your token? Publish your own audit on this page →

I love puppies PUPPIES
0xcf91…6eb2
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

2 Critical2 High2 Medium1 Low1 Informational
Volume 24h
$119.3K
Liquidity
$907.9K
Price
$0.0000001934
Token Age
2y
Top 10 Holders
12.7%

Security Findings

2 Crit2 High2 Med1 Low1 Info
Critical

Excessive Centralized Control by Owner

C-01The 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.
IssueThe 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.
FixImplement 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.
StatusUnresolved
Critical

Tax Wallet Draining and Lack of Liquidity Growth

C-02The 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.
IssueThe 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.
FixModify 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.
StatusUnresolved
High

Abuse Potential of Anti-Bot/Anti-Whale Mechanisms

H-01The `_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.
IssueThe `_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.
FixIf 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.
StatusUnresolved
High

Initial Trading Restrictions and Manipulation Risk

H-02The 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.
IssueThe 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.
FixClearly 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.
StatusUnresolved
Medium

Sell Limit per Block Causes Denial of Service

M-01The `_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.
IssueThe `_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.
FixRe-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.
StatusUnresolved
Medium

Lack of Event Emission for Critical Parameter Changes

M-02Many `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.
IssueMany `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.
FixEmit 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.
StatusUnresolved
Low

Hardcoded Uniswap Router Address in `openTrading`

L-01The 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.
IssueThe 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.
FixConsider 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.
StatusUnresolved
Info

Redundant Use of SafeMath in Solidity 0.8.x

I-01The 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.
IssueThe 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.
FixFor 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceMedium6/10

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

UpgradesLow8/10

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.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

12.7% in top 10
6.2% in wallets6.6% in contracts
Effective Concentration8.8%

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

$907.9K

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

LP Burned97.1% · ≈ permanent lock
LP Locked97.1%

Key Addresses

10 addresses
Deployer
0x6e66…69cd
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.

What Raised This Score

4 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

Related Audits

6 more on the record
AliensMedium RiskwojakMedium RiskBalancer (BAL)Medium RiskCateMedium RiskPrometheusMedium RiskApeCoin (APE)Medium Risk

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