Quantum Audit Logo

Is HarryPotterObamaSonic10Inu a Scam?

Honeypot, rug-pull and ownership checks

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

HarryPotterObamaSonic10Inu BITCOIN
0x72e4…eea9
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The HarryPotterObamaSonic10Inu (BITCOIN) token contract exhibits severe centralization risks and potential for malicious actions by the owner. While standard ERC-20 functionality is present, the extensive administrative control over taxes, trading, and user blacklisting poses critical security and economic threats to token holders. The contract is not upgradeable, making these risks permanent.

3 Critical2 High1 Medium1 Low
i Our automated scanner reviewed HarryPotterObamaSonic10Inu (BITCOIN) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.
Volume 24h
$182.5K
Liquidity
$1.18M
Price
$0.01986
Age
3y
Top 10 Holders
23.8%

Security Findings

3 Crit2 High1 Med1 Low
Critical

Owner Can Set Taxes to 100% (Rug Pull Vector)

C-01The `setTaxes` function allows the contract owner to set `_initialBuyTax`, `_initialSellTax`, `_finalBuyTax`, and `_finalSellTax` to arbitrary values. This includes the ability to set taxes to 100%, which would effectively prevent users from selling their tokens (100% sell tax) or buying new tokens (100% buy tax). This constitutes a direct rug pull vector, allowing the owner to drain liquidity or freeze user funds.
IssueThe `setTaxes` function allows the contract owner to set `_initialBuyTax`, `_initialSellTax`, `_finalBuyTax`, and `_finalSellTax` to arbitrary values. This includes the ability to set taxes to 100%, which would effectively prevent users from selling their tokens (100% sell tax) or buying new tokens (100% buy tax). This constitutes a direct rug pull vector, allowing the owner to drain liquidity or freeze user funds.
FixRemove or significantly restrict the owner's ability to modify tax percentages. If taxes are a core part of the tokenomics, they should be immutable or subject to a decentralized governance mechanism with a timelock. If mutable, implement strict upper bounds (e.g., max 25%) to prevent malicious exploitation.
StatusUnresolved
Critical

Owner Can Blacklist/Whitelist Any Address

C-02The `setBots` function allows the contract owner to add or remove any address from the `bots` mapping. Addresses marked as 'bots' are prevented from transferring tokens in the `_transfer` function. This grants the owner the power to arbitrarily blacklist any user, effectively freezing their tokens and preventing them from participating in trading. This is a severe centralization and censorship risk.
IssueThe `setBots` function allows the contract owner to add or remove any address from the `bots` mapping. Addresses marked as 'bots' are prevented from transferring tokens in the `_transfer` function. This grants the owner the power to arbitrarily blacklist any user, effectively freezing their tokens and preventing them from participating in trading. This is a severe centralization and censorship risk.
FixRemove the `setBots` function entirely. Decentralized tokens should not have the ability to arbitrarily freeze user funds or prevent transfers. If anti-bot measures are desired, they should be implemented in a non-custodial and transparent manner, ideally without direct owner intervention on individual addresses.
StatusUnresolved
Critical

Owner Can Manipulate Trading and Liquidity

C-03The `openTrading` function, callable only by the owner, initializes the Uniswap router and pair, and enables trading. This gives the owner complete control over when trading starts. Furthermore, the owner can update `_maxTxAmount`, `_maxWalletSize`, `_taxSwapThreshold`, and `_maxTaxSwap` at any time. This allows the owner to manipulate market conditions, prevent large transactions, or even halt trading by setting prohibitive limits, leading to potential market manipulation and denial of service for users.
IssueThe `openTrading` function, callable only by the owner, initializes the Uniswap router and pair, and enables trading. This gives the owner complete control over when trading starts. Furthermore, the owner can update `_maxTxAmount`, `_maxWalletSize`, `_taxSwapThreshold`, and `_maxTaxSwap` at any time. This allows the owner to manipulate market conditions, prevent large transactions, or even halt trading by setting prohibitive limits, leading to potential market manipulation and denial of service for users.
FixDecentralize or remove the `openTrading` function. Once trading is enabled, critical parameters like transaction limits and swap thresholds should be immutable or controlled by a decentralized governance mechanism with a timelock. If mutable, implement reasonable bounds and timelocks for changes.
StatusUnresolved
High

Centralized Control Over Fee Exclusions

H-01The `excludeFromFee` function allows the owner to exempt any address from paying transaction fees. While the owner, contract, and tax wallet are initially excluded, the ability to add arbitrary addresses to this exclusion list introduces a significant centralization risk. The owner could exclude favored addresses or even themselves from all taxes, creating an unfair advantage or enabling further manipulation.
IssueThe `excludeFromFee` function allows the owner to exempt any address from paying transaction fees. While the owner, contract, and tax wallet are initially excluded, the ability to add arbitrary addresses to this exclusion list introduces a significant centralization risk. The owner could exclude favored addresses or even themselves from all taxes, creating an unfair advantage or enabling further manipulation.
FixLimit fee exclusion to essential protocol addresses (e.g., the contract itself, the liquidity pair). If other exclusions are necessary, they should be immutable or subject to a transparent, decentralized governance process.
StatusUnresolved
High

Transfer Delay Can Be Arbitrarily Enabled/Disabled

H-02The `setTransferDelayEnabled` function allows the owner to enable or disable the `transferDelayEnabled` mechanism at will. This mechanism, when active, prevents holders from transferring tokens within a certain timeframe after their last transfer. While intended as an anti-dump measure, the owner's unilateral control over its activation/deactivation can be used to selectively hinder trading for certain periods, potentially impacting market stability or user liquidity without warning.
IssueThe `setTransferDelayEnabled` function allows the owner to enable or disable the `transferDelayEnabled` mechanism at will. This mechanism, when active, prevents holders from transferring tokens within a certain timeframe after their last transfer. While intended as an anti-dump measure, the owner's unilateral control over its activation/deactivation can be used to selectively hinder trading for certain periods, potentially impacting market stability or user liquidity without warning.
FixIf a transfer delay is a core feature, its activation and deactivation should be immutable or controlled by a decentralized governance mechanism with a timelock. Arbitrary owner control over such a significant trading restriction is a high risk.
StatusUnresolved
Medium

Potential for Stuck ETH in `swapAndLiquify`

M-01In the `swapAndLiquify` function, after `swapTokensForEth` is called, the contract attempts to add liquidity and then transfer the remaining ETH to `_taxWallet`. If the `addLiquidity` call fails (e.g., due to slippage, insufficient ETH, or external router issues), the remaining ETH might not be fully utilized for liquidity. While `_taxWallet.transfer` attempts to send the remaining balance, if `_taxWallet` is a contract that rejects ETH, or if there's an unexpected revert, some ETH could become stuck in the contract, requiring manual `rescueETH` by the owner.
IssueIn the `swapAndLiquify` function, after `swapTokensForEth` is called, the contract attempts to add liquidity and then transfer the remaining ETH to `_taxWallet`. If the `addLiquidity` call fails (e.g., due to slippage, insufficient ETH, or external router issues), the remaining ETH might not be fully utilized for liquidity. While `_taxWallet.transfer` attempts to send the remaining balance, if `_taxWallet` is a contract that rejects ETH, or if there's an unexpected revert, some ETH could become stuck in the contract, requiring manual `rescueETH` by the owner.
FixImplement more robust error handling or fallback mechanisms within `swapAndLiquify`. Consider adding checks for successful liquidity addition and potentially a retry mechanism or a more explicit way to handle leftover ETH if `addLiquidity` fails. Ensure `_taxWallet` is capable of receiving ETH or add a fallback for rejected transfers.
StatusUnresolved
Low

Missing SPDX License Identifier

L-01The contract uses `// SPDX-License-Identifier: NONE`. While technically valid, it's generally recommended to use a standard SPDX license identifier (e.g., MIT, GPL-3.0) to clarify the licensing terms of the code. Using 'NONE' can lead to ambiguity regarding intellectual property rights and usage permissions.
IssueThe contract uses `// SPDX-License-Identifier: NONE`. While technically valid, it's generally recommended to use a standard SPDX license identifier (e.g., MIT, GPL-3.0) to clarify the licensing terms of the code. Using 'NONE' can lead to ambiguity regarding intellectual property rights and usage permissions.
FixReplace `// SPDX-License-Identifier: NONE` with a standard and appropriate SPDX license identifier, such as `// SPDX-License-Identifier: MIT`.
StatusUnresolved

Category Ratings

TechnicalHigh2/10

The contract implements a standard ERC-20 token with additional features like transaction taxes, anti-whale limits, and anti-bot mechanisms (7.2 Code Security). It utilizes SafeMath for arithmetic operations, mitigating basic integer overflow/underflow risks. A reentrancy guard (`lockTheSwap`) is present for the `swapAndLiquify` function, which is a good practice. However, the extensive use of owner-controlled parameters, such as the ability to set arbitrary taxes and blacklist users, introduces significant technical risks (7.3 Access Control). The `swapAndLiquify` mechanism, while common, could face issues if external calls fail, potentially leaving funds stuck or preventing liquidity additions.

GovernanceMedium5/10

The contract's economic model is highly centralized and vulnerable to owner manipulation (7.4 Economic). The owner has absolute control over critical parameters, including the ability to set buy and sell taxes to any value, including 100%, effectively enabling a rug pull. The owner can also update `_maxTxAmount` and `_maxWalletSize` at will, potentially freezing user funds or preventing trading. Furthermore, the owner can blacklist any address using the `setBots` function, leading to arbitrary fund freezing (7.3 Access Control). The `openTrading` function, controlled solely by the owner, dictates when trading can commence, creating a single point of failure and potential for market manipulation (7.5 Governance).

UpgradesLow7/10

The contract is not designed with an upgrade mechanism (7.7 Upgrades). This means that once deployed, its logic cannot be altered. While this eliminates upgrade-related risks, it also means that any identified vulnerabilities or design flaws, particularly the severe centralization issues, are permanent and cannot be patched without a new deployment and migration.

Security Checklist

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

Holder Composition

23.8% in top 10
17.4% in wallets6.4% in contracts
Effective Concentration19.9%

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

$1.76M across 9 pairs
Uniswap v3WETHanalysed$1.18M67.2%Uniswap v2SPX$375.1K21.4%Uniswap v3WETH$178.7K10.2%Uniswap v3USDC$16.2K0.9%Uniswap v2WETH$3.6K0.2%Uniswap v3DAI$1.5K0.1%
Show 3 more pairsShow less
0x95D9…1C13WETH$7080.0%Uniswap v3CULT$1110.0%Uniswap v2PEPE$90.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

LP Locked99.7% · TeamFinance
Top-1 Unlocked Holder0.2%

Key Addresses

6 addresses
Deployer
0x41bc…fa88
Unlocked LP Held By
0x74a7…f26e0xb52f…0af10x41ae…94550x443f…fcf70x0a6b…5286

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

What Raised This Score

4 factors
  • 3 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 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
Lego Pepe (LEPE)High RiskGraph Token (GRT)High RiskGnosis Token (GNO)High RiskInterfold (FOLD)High RiskTokenFi (TOKEN)High RiskANyONe Protocol (ANYONE)High Risk

Would You Like a More Detailed Audit of HarryPotterObamaSonic10Inu?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit