Quantum Audit Logo
Launch App

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

Is ANyONe Protocol Safe?

ANYONEEthereum
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 5, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance1/10Upgrades6/10Checks passed5 of 7Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The AnyoneProtocolToken contract is an ERC20 token with Ownable access control, incorporating anti-bot mechanisms and a launch sequence.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 30% (48.8% total → 31.1% effective; 19.3% in EOAs, 29.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 1 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 55 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 5, 2026
29.5%Contracts19.3%Wallets51.2%Everyone else
29.5%Contracts19.3%Wallets51.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
48.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking29.5%
  • Walletsanonymous holders, free to sell19.3%
  • Everyone elsethe rest of the supply51.2%
Effective concentrationwhat the score reads31.1%
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 5, 2026

Liquidity

as of audit · Sep 5$708.1K across 2 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$707.1KShare of depth99.9%
Top-1 Unlocked Holder99.9%
Top-3 Unlocked100.0%
Unlocked LP held by
0x5dce…6faa0x329b…067c0xa1e4…efb10x243a…ad99

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

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized Control and Potential for Rug Pull

The contract grants significant power to the owner, including the ability to excludeFromLimits for any address, set/unset bots, and control the token launch. While these features are intended for project management and anti-bot measures, they also introduce a high degree of centralization. A malicious owner could exploit these privileges, for example, by excluding their own addresses from trading limits while others are subject to them, or by manipulating the AMM pair setup, potentially leading to a rug pull if liquidity is not adequately secured. This poses a significant economic risk (7.3 Access Control, 7.4 Economic).H-01

Issue

The contract grants significant power to the owner, including the ability to excludeFromLimits for any address, set/unset bots, and control the token launch. While these features are intended for project management and anti-bot measures, they also introduce a high degree of centralization. A malicious owner could exploit these privileges, for example, by excluding their own addresses from trading limits while others are subject to them, or by manipulating the AMM pair setup, potentially leading to a rug pull if liquidity is not adequately secured. This poses a significant economic risk (7.3 Access Control, 7.4 Economic).

Fix

Consider implementing a multi-signature wallet for ownership of critical functions or introducing a time-lock mechanism for sensitive operations. Explore options to decentralize control over key parameters, such as AMM pair settings or limit exclusions, possibly through a community governance model or by hardcoding immutable parameters post-launch. Ensure liquidity is locked or burned to prevent rug pull scenarios.

Status

Unresolved

Medium

Gas Limit Risk in Batch Operations

Functions like excludeFromLimits and setBots iterate through an array of addresses. If the accounts array contains a large number of addresses, these operations could exceed the block gas limit, leading to a denial of service for these specific functions. While the owner controls the input, this design pattern can be problematic in high-volume scenarios or if the owner needs to process many addresses at once (7.2 Code Security).M-01

Issue

Functions like excludeFromLimits and setBots iterate through an array of addresses. If the accounts array contains a large number of addresses, these operations could exceed the block gas limit, leading to a denial of service for these specific functions. While the owner controls the input, this design pattern can be problematic in high-volume scenarios or if the owner needs to process many addresses at once (7.2 Code Security).

Fix

Implement pagination for batch operations, allowing the owner to process addresses in smaller, manageable chunks. Alternatively, introduce a maximum array size limit to prevent transactions from exceeding the block gas limit. Consider an event-driven or pull-based mechanism for large-scale updates if feasible.

Status

Unresolved

Medium

tx.origin Usage for Anti-Bot Measures

The _beforeTokenTransfer function uses tx.origin as part of its anti-bot logic (`require(tx.origin == from || tx.origin == sender || !isBot[tx.origin], "AnyoneProtocolToken: Bot detected.");`). While this specific use case aims to prevent bots initiated by an EOA marked as a bot, tx.origin is generally discouraged due to potential phishing vulnerabilities where a user might interact with a malicious contract that then calls this contract, making the tx.origin check pass even if the intermediate contract is malicious. In this context, it's less about phishing and more about the robustness of the anti-bot mechanism against sophisticated bot setups that might use intermediate contracts…M-02

Issue

The _beforeTokenTransfer function uses tx.origin as part of its anti-bot logic (`require(tx.origin == from || tx.origin == sender || !isBot[tx.origin], "AnyoneProtocolToken: Bot detected.");`). While this specific use case aims to prevent bots initiated by an EOA marked as a bot, tx.origin is generally discouraged due to potential phishing vulnerabilities where a user might interact with a malicious contract that then calls this contract, making the tx.origin check pass even if the intermediate contract is malicious. In this context, it's less about phishing and more about the robustness of the anti-bot mechanism against sophisticated bot setups that might use intermediate contracts…

Fix

While the current usage is for anti-bot, consider if msg.sender checks alone or a more sophisticated bot detection mechanism would be sufficient and more robust. If tx.origin is deemed critical for the current anti-bot strategy, ensure the limitations are understood and accepted, and consider adding additional layers of bot detection.

Status

Unresolved

Low

Low-Level Call in withdrawStuckTokens

The withdrawStuckTokens function uses a low-level call{value: amount}("") for native token withdrawals. While a require(success) check is present, and the recipient is the owner (an EOA), generally, interactions with external contracts should be handled with reentrancy guards if state changes occur after the call. In this specific case, no critical state changes occur after the call, making the reentrancy risk low, but it's a pattern worth noting (7.2 Code Security).L-01

Issue

The withdrawStuckTokens function uses a low-level call{value: amount}("") for native token withdrawals. While a require(success) check is present, and the recipient is the owner (an EOA), generally, interactions with external contracts should be handled with reentrancy guards if state changes occur after the call. In this specific case, no critical state changes occur after the call, making the reentrancy risk low, but it's a pattern worth noting (7.2 Code Security).

Fix

For simple native token transfers to an EOA, transfer() or send() are generally preferred as they have a fixed gas stipend, reducing reentrancy attack surface. If call is necessary for specific reasons (e.g., forwarding more gas), ensure no critical state changes occur after the call, or implement a reentrancy guard (e.g., OpenZeppelin's ReentrancyGuard).

Status

Unresolved

Info

Hardcoded Address in Constructor

The constructor hardcodes a specific address (0x61fF…B21e) to be excluded from limits. While this might be intentional for a specific operational address, hardcoding addresses can reduce flexibility and make future changes or deployments to different environments more cumbersome. It also requires careful verification that the hardcoded address is correct and intended (7.1 Architecture).I-01

Issue

The constructor hardcodes a specific address () to be excluded from limits. While this might be intentional for a specific operational address, hardcoding addresses can reduce flexibility and make future changes or deployments to different environments more cumbersome. It also requires careful verification that the hardcoded address is correct and intended (7.1 Architecture).

Fix

If the hardcoded address is intended to be a fixed protocol address, document its purpose clearly. For greater flexibility, consider passing such addresses as constructor arguments or allowing the owner to set them post-deployment via an onlyOwner function, if appropriate for the protocol's design.

Status

Unresolved

Analysis

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

The AnyoneProtocolToken contract is an ERC20 token with Ownable access control, incorporating anti-bot mechanisms and a launch sequence. The contract utilizes OpenZeppelin libraries for standard functionalities, enhancing code security. However, significant centralization of control under the owner introduces a high economic risk, particularly regarding potential for rug pull or manipulation. Technical risks include gas limit concerns for batch operations and the use of tx.origin for bot detection. The contract is not upgradeable.

Technical8/10Low risk

The contract demonstrates good technical practices by inheriting from OpenZeppelin's ERC20 and Ownable contracts and utilizing SafeERC20 for external token interactions (7.2 Code Security). The _beforeTokenTransfer hook implements custom logic for launch checks and bot detection, which is a robust approach. However, batch operations like excludeFromLimits and setBots could face gas limit issues with large input arrays (7.2 Code Security). Additionally, the use of tx.origin for bot detection, while intentional, can have limitations against sophisticated bot strategies (7.2 Code Security). The withdrawStuckTokens function includes a low-level call for native token withdrawal, which is generally safe in this context but noted for reentrancy pattern (7.2 Code Security).

Governance1/10High risk

The contract exhibits a high degree of centralization, with the Ownable pattern granting the deployer extensive control over critical functions (7.3 Access Control, 7.5 Governance). The owner can launch the token, set AMM pairs, exclude addresses from trading limits, and mark addresses as bots. While these features are intended for project management and anti-bot measures, they also introduce a significant economic risk (7.4 Economic). For instance, the owner's ability to excludeFromLimits for any address, combined with control over the initial token supply, creates a potential for a rug pull if the owner acts maliciously. There is no decentralized governance mechanism in place, making the protocol entirely reliant on the owner's integrity (7.5 Governance).

Upgrades6/10Medium risk

The contract is not designed to be upgradeable, as it does not implement any proxy pattern (7.7 Upgrades). This means its logic is immutable once deployed. Consequently, there are no upgrade-specific risks, but any future changes would require a new deployment and migration of assets.

Final RecommendationWhat to do about this score

To enhance the security and decentralization of the ANyONe Protocol, consider implementing mechanisms to reduce the single point of failure associated with the owner's extensive privileges.

Explore options for multi-signature ownership or time-locked control for critical functions to mitigate rug pull risks. For batch operations, implement pagination or size limits to prevent potential gas limit issues. Review the tx.origin usage for bot detection and consider more robust, contract-based anti-bot strategies.

Contract & Record

1 audit on record
TypeAnyoneProtocolToken
NetworkEthereum
Token age2y
Contract0xfeac…c0f9
Deployer0xa2d4…a3d1
Badge for your website
ANyONe Protocol 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 5, 202661Medium

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

Related Audits

6 more on the recordAll audits
HarryPotterObamaSonic10InuBITCOIN · Ethereum61MediumLego PepeLEPE · Ethereum61MediumGraph TokenGRT · Ethereum61MediumGnosis TokenGNO · Ethereum61MediumInterfoldFOLD · Ethereum61MediumTokenFiTOKEN · Ethereum61Medium

Would You Like a More Detailed Audit of ANyONe Protocol?

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