Quantum Audit Logo
Launch App

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

Is Strike Robot Safe?

SRBase
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
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed2 of 5Findings2 High · 1 Medium · 2 Low · 2 Info7
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.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
68.7%Contracts22.2%Wallets9.2%Everyone else
68.7%Contracts22.2%Wallets9.2%
ContractsWalletsEveryone elseBubble area = share of supply
90.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking68.7%
  • Walletsanonymous holders, free to sell22.2%
  • Everyone elsethe rest of the supply9.2%
Effective concentrationwhat the score reads49.6%
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$113.1K across 4 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$113.1KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xba2f…023f

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

Security Findings

2 High1 Medium2 Low2 Info
High

Centralized Control Over Critical Parameters

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

High

Denial of Service and Potential Loss of Funds in _swapTaxTokens

The _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…H-02

Issue

The _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…

Fix

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

Status

Unresolved

Medium

Unused _validCallerCodeHashes Mechanism

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Low

Lack of Emergency Withdrawal/Rescue Function

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Low

Risky setPairToken Function

The 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.L-02

Issue

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

Fix

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

Status

Unresolved

Info

_autoSwapInProgress Initial State

The _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.I-01

Issue

The _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.

Fix

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

Status

Unresolved

Info

Complex _transfer Function Logic

The _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.I-02

Issue

The _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.

Fix

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

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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.

Governance1/10High risk

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

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

Prioritize addressing the high-severity denial of service and potential loss of funds in the _swapTaxTokens function by implementing robust error handling and ensuring projectTaxPendingSwap is only reset upon successful fund transfer.

Evaluate the extent of centralized control and consider implementing multi-signature governance or time-locks for critical parameter changes to mitigate single points of failure. Additionally, implement an emergency withdrawal mechanism for accidentally sent tokens and clarify or remove unused code to reduce complexity and potential for future misuse.

Contract & Record

1 audit on record
TypeAgentTokenV3
NetworkBase
Token age4mo
Contract0x10c5…1ac9
Deployer0xa3eb…bebc
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Strike Robot 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. Sep 4, 202687Critical
  2. Aug 13, 202696Critical

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

Frequently Asked Questions

What is the SR contract address?

The Strike Robot (SR) contract on Base is 0x10c56f005a379f8eafc88ff5c3f40d30f0031ac9. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Strike Robot a scam?

Quantum Audit's risk score for Strike Robot is 87/100 (Critical risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is SR liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $113.1K.

Who holds SR?

As of Sep 4, 2026, the 10 largest holders own 90.8% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Crynux TokenCNX · Base87CriticalMineBeanBEAN · Base89CriticalFLock.ioFLOCK · Base85CriticalCoinbase Wrapped MEGACBMEGA · Base85Criticalbasedpad.funBPAD · Base85CriticalCysicCYS · Base84High

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 Is this your token? Publish your own audit on this page