Quantum Audit Logo

Is REPPO Safe?

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

REPPO REPPO
0xff81…83d6
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 High2 Medium1 Low2 Informational
Volume 24h
$633.1K
Liquidity
$896.2K
Price
$0.01864
Token Age
2mo
Top 10 Holders
72.5%

Security Findings

1 High2 Med1 Low2 Info
High

High Centralization Risk via Owner/Factory Control

H-01The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Medium

Potential for MEV/Front-running in Initial Liquidity Provision

M-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Medium

Unclear Purpose and Usage of `_validCallerCodeHashes` Mechanism

M-02The 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.
IssueThe 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.
FixClearly 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.
StatusUnresolved
Low

Unused `CALL_GAS_LIMIT` Constant

L-01The 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.
IssueThe 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.
FixEither 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.
StatusUnresolved
Info

Reentrancy Guard `_autoSwapInProgress` Implemented

I-01The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Info

Initial Ownership Transfer via `initialize` Function

I-02The `_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.
IssueThe `_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.
FixEnsure 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.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh1/10

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

UpgradesHigh1/10

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.

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

72.5% in top 10
15.5% in wallets57.0% in contracts
Effective Concentration38.3%

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

$1.23M across 16 pairs
BaselineVIRTUALanalysed$896.2K72.6%Uniswap v3USDC$237.4K19.2%AerodromeWETH$44.4K3.6%Uniswap v3WETH$25.0K2.0%Hydrex CLAMMWETH$24.3K2.0%Uniswap v4USDC$3.8K0.3%
Show 4 more pairsShow less
PancakeswapUSDC$3.1K0.2%Uniswap v3WETH$2420.0%Uniswap v4ETH$920.0%Uniswap v2VIRTUAL$860.0%

The 6 remaining pairs hold $32 between them and are not listed.

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 Holder74.1%
Top-3 Unlocked99.4%

Key Addresses

9 addresses
Deployer
0x5996…f39e
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.

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% (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

Related Audits

6 more on the record
The White Wolf (WOLF)Critical RiskSport.fun (FUN)Critical RiskRecallCritical RiskVANRYCritical RiskChipCritical Riskdefi-nativeCritical Risk

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