Quantum Audit Logo

Is Strike Robot Safe?

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

Strike Robot SR
0x10c5…1ac9
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The AgentTokenV3 contract implements an upgradeable ERC-20 token with custom tax mechanisms, bot protection, and integration with Uniswap V2. The audit identified significant centralization risks due to extensive owner control over critical parameters, and a high-severity denial of service vulnerability in the tax swap mechanism that could also lead to loss of accumulated tax funds. Several medium and low-severity issues were also found, primarily related to unused code, lack of emergency fund recovery, and potential for unexpected behavior with critical parameter changes. The contract utilizes OpenZeppelin's upgradeable patterns and includes a reentrancy guard for the tax swap, which are positive security practices.

2 High1 Medium2 Low2 Informational
Volume 24h
$21.5K
Liquidity
$113.1K
Price
$0.001296
Token Age
4mo
Top 10 Holders
90.8%

Security Findings

2 High1 Med2 Low2 Info
High

Centralized Control Over Critical Parameters

H-01The contract owner (and in some cases, the factory) has extensive control over critical parameters, including `projectBuyTaxBasisPoints`, `projectSellTaxBasisPoints`, `projectTaxRecipient`, `botProtectionDurationInSeconds`, `blacklists`, and `pairToken`. This level of centralization introduces a single point of failure, allowing a malicious or compromised owner to significantly alter the token's economics, block users, or disrupt liquidity pools. For example, changing `pairToken` after initial liquidity is added could lead to unexpected behavior or loss of funds.
IssueThe contract owner (and in some cases, the factory) has extensive control over critical parameters, including `projectBuyTaxBasisPoints`, `projectSellTaxBasisPoints`, `projectTaxRecipient`, `botProtectionDurationInSeconds`, `blacklists`, and `pairToken`. This level of centralization introduces a single point of failure, allowing a malicious or compromised owner to significantly alter the token's economics, block users, or disrupt liquidity pools. For example, changing `pairToken` after initial liquidity is added could lead to unexpected behavior or loss of funds.
FixConsider decentralizing control over critical parameters by implementing multi-signature governance for sensitive functions or introducing time-locks for changes to allow users to react. For `setPairToken`, evaluate if this function is truly necessary post-deployment, or if it should be restricted to only be callable before initial liquidity is added.
StatusUnresolved
High

Denial of Service and Potential Loss of Funds in `_swapTaxTokens`

H-02The `_swapTaxTokens` function performs an external call to `IAgentTaxForToken(projectTaxRecipient).depositTax`. If this call reverts for any reason (e.g., `projectTaxRecipient` is a malicious contract, or it runs out of gas), the entire `_swapTaxTokens` transaction will revert. Since `_swapTaxTokens` is called within `_update` (which is part of `_transfer`), this can block all token transfers when the tax swap threshold is met, leading to a denial of service. Furthermore, `projectTaxPendingSwap` is zeroed out *before* the Uniswap swap attempt. If the swap fails (even with the `try/catch` block) and the `catch` path is taken, the tokens intended for tax remain in the contract but are no long…
IssueThe `_swapTaxTokens` function performs an external call to `IAgentTaxForToken(projectTaxRecipient).depositTax`. If this call reverts for any reason (e.g., `projectTaxRecipient` is a malicious contract, or it runs out of gas), the entire `_swapTaxTokens` transaction will revert. Since `_swapTaxTokens` is called within `_update` (which is part of `_transfer`), this can block all token transfers when the tax swap threshold is met, leading to a denial of service. Furthermore, `projectTaxPendingSwap` is zeroed out *before* the Uniswap swap attempt. If the swap fails (even with the `try/catch` block) and the `catch` path is taken, the tokens intended for tax remain in the contract but are no long…
FixImplement robust error handling for the `depositTax` call, potentially by wrapping it in a `try/catch` block and logging failures, or by allowing the owner to manually retry or recover funds. Crucially, `projectTaxPendingSwap` should only be reset *after* the successful completion of both the Uniswap swap and the `depositTax` call to prevent loss of funds. Consider adding a mechanism for the owner to recover 'stuck' tax tokens if swaps consistently fail.
StatusUnresolved
Medium

Unused `_validCallerCodeHashes` Mechanism

M-01The contract includes `_validCallerCodeHashes` and functions to manage it (`addValidCaller`, `removeValidCaller`), but the provided code does not show any usage of this mechanism. This could be dead code, an incomplete feature, or a placeholder for future functionality. Unused code adds unnecessary complexity, increases the contract's attack surface, and can lead to confusion during audits or future development.
IssueThe contract includes `_validCallerCodeHashes` and functions to manage it (`addValidCaller`, `removeValidCaller`), but the provided code does not show any usage of this mechanism. This could be dead code, an incomplete feature, or a placeholder for future functionality. Unused code adds unnecessary complexity, increases the contract's attack surface, and can lead to confusion during audits or future development.
FixEither integrate the `_validCallerCodeHashes` mechanism into the contract's logic with a clear purpose, or remove it entirely to reduce complexity and potential for misuse. If it's intended for future use, document its purpose clearly.
StatusUnresolved
Low

Lack of Emergency Withdrawal/Rescue Function

L-01The contract lacks a mechanism to recover ERC-20 tokens (other than its own token or the `pairToken` used for liquidity) that might be accidentally sent to the contract address. If any arbitrary ERC-20 token is sent to the contract, it will be permanently locked and inaccessible.
IssueThe contract lacks a mechanism to recover ERC-20 tokens (other than its own token or the `pairToken` used for liquidity) that might be accidentally sent to the contract address. If any arbitrary ERC-20 token is sent to the contract, it will be permanently locked and inaccessible.
FixImplement a generic `rescueERC20` function, callable only by the owner, that allows withdrawing arbitrary ERC-20 tokens from the contract. Ensure this function cannot be used to drain the contract's own token or the `pairToken` essential for its operation.
StatusUnresolved
Low

Risky `setPairToken` Function

L-02The `setPairToken` function allows the owner to change the `pairToken` after deployment. While this might be intended for flexibility, changing this critical parameter after initial liquidity has been added could break existing liquidity pools, disrupt the tax mechanism, and potentially lead to loss of funds or unexpected behavior if not handled carefully. There are no checks to prevent setting an invalid or malicious `pairToken`.
IssueThe `setPairToken` function allows the owner to change the `pairToken` after deployment. While this might be intended for flexibility, changing this critical parameter after initial liquidity has been added could break existing liquidity pools, disrupt the tax mechanism, and potentially lead to loss of funds or unexpected behavior if not handled carefully. There are no checks to prevent setting an invalid or malicious `pairToken`.
FixIf `setPairToken` is truly necessary, add robust validation for the new `pairToken` address. Consider adding a time-lock or multi-signature requirement for this function due to its critical impact. Alternatively, restrict its callable window to only before initial liquidity is added or make it immutable after deployment.
StatusUnresolved
Info

`_autoSwapInProgress` Initial State

I-01The `_autoSwapInProgress` flag is initialized to `true` in the `initialize` function and then set to `false` in `_addInitialLiquidity`. This means that any token transfers occurring between the contract's initialization and the addition of initial liquidity would attempt to trigger `_swapTaxTokens`. As there would be no Uniswap pair or liquidity at that stage, these early transfers would likely fail, potentially blocking early operations.
IssueThe `_autoSwapInProgress` flag is initialized to `true` in the `initialize` function and then set to `false` in `_addInitialLiquidity`. This means that any token transfers occurring between the contract's initialization and the addition of initial liquidity would attempt to trigger `_swapTaxTokens`. As there would be no Uniswap pair or liquidity at that stage, these early transfers would likely fail, potentially blocking early operations.
FixConsider initializing `_autoSwapInProgress` to `false` if transfers are expected before initial liquidity is added, or clearly document this behavior and its implications for early token operations.
StatusUnresolved
Info

Complex `_transfer` Function Logic

I-02The `_update` function, which forms the core of the `_transfer` and `_transferFrom` logic, is quite complex. It incorporates checks for blacklisted addresses, bot protection, tax calculation, tax accumulation, and conditional tax swapping. While these features are integral to the token's design, the combined logic within a single function increases its cognitive load and the potential for subtle bugs.
IssueThe `_update` function, which forms the core of the `_transfer` and `_transferFrom` logic, is quite complex. It incorporates checks for blacklisted addresses, bot protection, tax calculation, tax accumulation, and conditional tax swapping. While these features are integral to the token's design, the combined logic within a single function increases its cognitive load and the potential for subtle bugs.
FixConsider refactoring the `_update` function to separate concerns where possible, perhaps by extracting specific checks or calculations into smaller, more focused internal functions. This can improve readability, maintainability, and reduce the risk of errors.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract demonstrates good architectural practices by leveraging OpenZeppelin's upgradeable contracts and implementing a reentrancy guard (`_autoSwapInProgress`) for the tax swap mechanism (7.1 Architecture, 7.2 Code Security). However, the `_swapTaxTokens` function presents a high technical risk due to potential denial of service if the `depositTax` external call reverts, and a risk of losing accumulated tax funds if the Uniswap swap fails after `projectTaxPendingSwap` is zeroed out (7.2 Code Security, 7.8 Operations). The `_transfer` logic is complex, combining blacklisting, bot protection, and tax calculations, increasing the surface area for bugs.

GovernanceHigh1/10

The contract's economic model includes configurable buy/sell taxes and bot protection, which are positive features (7.4 Economic). However, the owner (and factory) retains extensive control over critical parameters such as tax rates, tax recipient, bot protection duration, blacklisting, and even the `pairToken` (7.3 Access Control, 7.5 Governance). This high degree of centralization introduces a single point of failure and significant trust assumptions, as a malicious or compromised owner could alter token economics or block users. The `setPairToken` function, in particular, poses a risk if changed after initial liquidity is established (7.4 Economic).

UpgradesHigh1/10

The contract is designed for upgradeability using OpenZeppelin's `Initializable` and `Ownable2StepUpgradeable` patterns, ensuring a secure and controlled upgrade path (7.7 Upgrades). The `_disableInitializers()` in the constructor prevents re-initialization attacks. While no explicit storage gap is defined, OpenZeppelin's upgradeable base contracts typically handle this to prevent storage collisions in future versions.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

90.8% in top 10
22.2% in wallets68.7% in contracts
Effective Concentration49.6%

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

$113.1K across 4 pairs
Uniswap v2VIRTUALanalysed$113.1K100.0%Uniswap v4USDT$70.0%Uniswap v4ETH$10.0%Uniswap v2WETH$00.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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xa3eb…bebc
Unlocked LP Held By
0xba2f…023f

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

What Raised This Score

10 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 30% (90.8% total → 49.6% effective; 22.2% in EOAs, 68.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 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

Related Audits

6 more on the record
MineBean (BEAN)Critical RiskFLock.io (FLOCK)Critical RiskCoinbase Wrapped MEGA (CBMEGA)Critical Riskbasedpad.fun (BPAD)Critical RiskCysic (CYS)Critical RiskValtherix AI (VLTX)Critical Risk

Would You Like a More Detailed Audit of Strike Robot?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit