Is ANyONe Protocol (ANYONE) Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low1 Info

High

Centralized Control and Potential for Rug Pull

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

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

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

StatusUnresolved

Medium

Gas Limit Risk in Batch Operations

M-01Functions 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).

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

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

StatusUnresolved

Medium

`tx.origin` Usage for Anti-Bot Measures

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

IssueThe `_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…

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

StatusUnresolved

Low

Low-Level Call in `withdrawStuckTokens`

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

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

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

StatusUnresolved

Info

Hardcoded Address in Constructor

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceHigh1/10

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

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

48.8% in top 10

19.3% in wallets29.5% in contracts

Effective Concentration31.1%

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

$708.1K across 2 pairs

Uniswap v3WETHanalysed$707.1K Uniswap v4ETH$1.0K

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 Holder99.9%

Top-3 Unlocked100.0%

Key Addresses

5 addresses

Deployer

0xa2d4…a3d1

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.

What Raised This Score

8 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

Is ANyONe Protocol Safe?

Security Findings

Centralized Control and Potential for Rug Pull

Gas Limit Risk in Batch Operations

`tx.origin` Usage for Anti-Bot Measures

Low-Level Call in `withdrawStuckTokens`

Hardcoded Address in Constructor

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of ANyONe Protocol?