Quantum Audit Logo
Launch App

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

Is REPPO Safe?

Base
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades1/10Checks passed2 of 5Findings1 High · 2 Medium · 1 Low · 2 Info6
SummaryAI Copilot

This audit covers the provided snippet of the AgentTokenV2 contract.

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 = 74.1%
  • LP top3 unlocked holders = 99.4%
  • 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)
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 30% (72.5% total → 38.3% effective; 15.5% in EOAs, 57.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 74.1% (independent LP — depth risk, pool = 73% of DEX liquidity)
  • LP top3 unlocked holders = 99.4% (independent LP — depth risk, pool = 73% 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
57.0%Contracts15.5%Wallets27.5%Everyone else
57.0%Contracts15.5%Wallets27.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
72.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking57.0%
  • Walletsanonymous holders, free to sell15.5%
  • Everyone elsethe rest of the supply27.5%
Effective concentrationwhat the score reads38.3%
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$1.23M across 16 pairs
Show 4 more pairs

The 6 remaining pairs hold $32 between them and are not listed. 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$896.2KShare of depth72.6%
Top-1 Unlocked Holder74.1%
Top-3 Unlocked99.4%
Unlocked LP held by
0x1413…41ea0xd847…d6800x73e3…93d50xef28…73420x424e…d73e0x6313…1a600x774c…1a790x33cd…3aa6

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

Security Findings

1 High2 Medium1 Low2 Info
High

High Centralization Risk via Owner/Factory Control

The onlyOwnerOrFactory modifier grants significant control to the contract owner and the designated factory address. Functions such as addBlacklistAddress, removeBlacklistAddress, addLiquidityPool, removeLiquidityPool, addValidCaller, and removeValidCaller are protected by this modifier. This level of control allows a single entity (or two, if factory is distinct) to significantly impact token operations, including censoring users, manipulating liquidity pools, and controlling whitelisted callers. A compromise of the owner's or factory's private key could lead to severe consequences.H-01

Issue

The onlyOwnerOrFactory modifier grants significant control to the contract owner and the designated factory address. Functions such as addBlacklistAddress, removeBlacklistAddress, addLiquidityPool, removeLiquidityPool, addValidCaller, and removeValidCaller are protected by this modifier. This level of control allows a single entity (or two, if factory is distinct) to significantly impact token operations, including censoring users, manipulating liquidity pools, and controlling whitelisted callers. A compromise of the owner's or factory's private key could lead to severe consequences.

Fix

Implement a multi-signature wallet for the owner and factory addresses to distribute control and reduce the risk of a single point of failure. Consider implementing a time-lock for critical administrative actions to allow users to react to potentially malicious changes. Clearly communicate the extent of centralized control to users.

Status

Unresolved

Medium

Potential for MEV/Front-running in Initial Liquidity Provision

The addInitialLiquidity function, while protected by onlyOwnerOrFactory, involves transferring tokens and creating LP tokens. If the lpOwner is a publicly known address or the timing of this transaction is predictable, MEV bots could potentially front-run or sandwich the liquidity addition, especially if the pairToken is volatile. This could lead to unfavorable pricing for the initial liquidity provider or exploit opportunities.M-01

Issue

The addInitialLiquidity function, while protected by onlyOwnerOrFactory, involves transferring tokens and creating LP tokens. If the lpOwner is a publicly known address or the timing of this transaction is predictable, MEV bots could potentially front-run or sandwich the liquidity addition, especially if the pairToken is volatile. This could lead to unfavorable pricing for the initial liquidity provider or exploit opportunities.

Fix

Consider using a private transaction relay or a trusted third-party service for the addInitialLiquidity transaction to mitigate front-running risks. Ensure the lpOwner address is secure and the transaction is executed at an unpredictable time.

Status

Unresolved

Medium

Unclear Purpose and Usage of _validCallerCodeHashes Mechanism

The contract includes a mechanism to manage _validCallerCodeHashes via addValidCaller and removeValidCaller functions. The purpose of this whitelist (i.e., which functions check isValidCaller) is not evident from the provided snippet. If this mechanism is used to restrict who can call certain critical functions (e.g., _transfer or _swapAndLiquify), it could introduce an unusual access control pattern that might be difficult to understand, audit, or manage, potentially leading to unintended restrictions or vulnerabilities if the whitelisted contracts are compromised or have their own flaws.M-02

Issue

The contract includes a mechanism to manage _validCallerCodeHashes via addValidCaller and removeValidCaller functions. The purpose of this whitelist (i.e., which functions check isValidCaller) is not evident from the provided snippet. If this mechanism is used to restrict who can call certain critical functions (e.g., _transfer or _swapAndLiquify), it could introduce an unusual access control pattern that might be difficult to understand, audit, or manage, potentially leading to unintended restrictions or vulnerabilities if the whitelisted contracts are compromised or have their own flaws.

Fix

Clearly document the intended use cases and security implications of the _validCallerCodeHashes mechanism. Ensure that any functions relying on isValidCaller are thoroughly reviewed for potential bypasses or unintended consequences. If possible, consider if a more standard access control pattern (e.g., role-based access control) would achieve the same goal with greater clarity and auditability.

Status

Unresolved

Low

Unused CALL_GAS_LIMIT Constant

The constant CALL_GAS_LIMIT is defined with a value of 50000, but it is not utilized anywhere in the provided contract snippet. This suggests either an incomplete implementation, a feature that was planned but not implemented, or dead code. If it was intended for external calls (e.g., in _swapAndLiquify), its absence could lead to out-of-gas errors for complex transactions or reentrancy vulnerabilities if external calls are not properly guarded.L-01

Issue

The constant CALL_GAS_LIMIT is defined with a value of 50000, but it is not utilized anywhere in the provided contract snippet. This suggests either an incomplete implementation, a feature that was planned but not implemented, or dead code. If it was intended for external calls (e.g., in _swapAndLiquify), its absence could lead to out-of-gas errors for complex transactions or reentrancy vulnerabilities if external calls are not properly guarded.

Fix

Either remove the unused constant to improve code clarity and reduce bytecode size, or implement its intended functionality, ensuring it is applied correctly to external calls to prevent gas-related issues or reentrancy.

Status

Unresolved

Info

Reentrancy Guard _autoSwapInProgress Implemented

The contract utilizes an _autoSwapInProgress boolean flag, which is set to true during initialization and false after initial liquidity is added. This pattern is commonly used as a reentrancy guard for functions involving external calls, particularly in _swapAndLiquify operations. This is a good practice to prevent reentrant calls during sensitive operations.I-01

Issue

The contract utilizes an _autoSwapInProgress boolean flag, which is set to true during initialization and false after initial liquidity is added. This pattern is commonly used as a reentrancy guard for functions involving external calls, particularly in _swapAndLiquify operations. This is a good practice to prevent reentrant calls during sensitive operations.

Fix

Ensure that all external calls that could potentially lead to reentrancy are properly guarded by this flag or other appropriate mechanisms. Verify that the flag's state transitions are correctly managed throughout the contract's lifecycle, especially in the missing _swapAndLiquify function.

Status

Unresolved

Info

Initial Ownership Transfer via initialize Function

The _transferOwnership(projectOwner_) function is called within the _decodeBaseParams function, which is part of the initialize function. This sets the initial owner of the contract based on the projectOwner_ parameter provided during initialization. This is a standard and secure way to establish ownership for upgradeable contracts deployed via a factory or proxy.I-02

Issue

The _transferOwnership(projectOwner_) function is called within the _decodeBaseParams function, which is part of the initialize function. This sets the initial owner of the contract based on the projectOwner_ parameter provided during initialization. This is a standard and secure way to establish ownership for upgradeable contracts deployed via a factory or proxy.

Fix

Ensure that the projectOwner_ address provided during the contract's initialization is a secure, controlled address, preferably a multi-signature wallet, to maintain robust access control from the outset.

Status

Unresolved

Analysis

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

This audit covers the provided snippet of the AgentTokenV2 contract. The contract implements an upgradeable ERC-20 token with tax mechanisms, bot protection, and Uniswap V2 integration. While utilizing standard OpenZeppelin patterns for upgradeability and access control, significant centralization risk exists due to extensive owner/factory privileges. A full security assessment is limited by the absence of critical functions like _transfer and _swapAndLiquify, which are essential for evaluating core token logic and tax collection mechanisms.

Technical6/10Medium risk

The contract utilizes standard OpenZeppelin upgradeable patterns and SafeERC20 for external token interactions, contributing to robust code security (7.2). A reentrancy guard (_autoSwapInProgress) is implemented for critical operations (7.2). However, the purpose and usage of the _validCallerCodeHashes mechanism are not fully clear, potentially introducing an unusual access control pattern (7.3). The CALL_GAS_LIMIT constant is defined but unused, suggesting incomplete implementation or a potential oversight (7.2). A comprehensive review of the missing _transfer and _swapAndLiquify functions is crucial for a complete technical assessment.

Governance1/10High risk

The contract exhibits a high degree of centralization, with the owner and factory having significant control over critical functions (7.3, 7.5). This includes the ability to blacklist addresses, manage liquidity pools, and add/remove valid callers, posing a substantial governance risk if the controlling keys are compromised. The initial liquidity provision, while protected by onlyOwnerOrFactory, could be susceptible to MEV or front-running during its execution (7.4). Tax parameters are configurable, allowing flexibility but also requiring careful management (7.4). The botProtectionDurationInSeconds is a positive economic control (7.4).

Upgrades1/10High risk

The contract correctly implements the Initializable and Ownable2StepUpgradeable patterns from OpenZeppelin, providing a secure and well-understood framework for future upgrades (7.7). The constructor disables initializers, preventing re-initialization attacks. Proper use of internal for state variables and _disableInitializers ensures upgrade safety, assuming no storage collisions with future implementations.

Final RecommendationWhat to do about this score

It is recommended to thoroughly review the full contract code, especially the _transfer and _swapAndLiquify functions, to ensure all security best practices are followed and no hidden vulnerabilities exist.

Implement a robust multi-signature wallet for the owner and factory addresses to mitigate the high centralization risk. Clearly document the intended use and security implications of the _validCallerCodeHashes mechanism.

Contract & Record

1 audit on record
TypeAgentTokenV2
NetworkBase
Token age2mo
Contract0xff81…83d6
Deployer0x5996…f39e
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
REPPO 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, 202674High
  2. Aug 11, 202677High

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

Related Audits

6 more on the recordAll audits
The White WolfWOLF · Base74HighSport.funFUN · Base74HighSIBYL by VirtualsSIBYL · Base74High1claw AI1CLAWAI · Base74HighPRXVTBase73HighGachaPadGACHA · Base75High

Would You Like a More Detailed Audit of REPPO?

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