Quantum Audit Logo

Is SIBYL by Virtuals Safe?

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

SIBYL by Virtuals SIBYL
0x797f…4714
Base
Not verifiedThis 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.
Last checked 10d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The AgentToken contract implements an ERC20-like token with custom tax mechanisms, bot protection, and Uniswap V2 integration for liquidity. It utilizes OpenZeppelin's upgradeable patterns for robust architecture. The audit identified high-severity issues related to slippage control in tax-swapping mechanisms and significant centralization risk in critical administrative functions. Medium-severity concerns include the complexity of bot protection logic and the use of unlimited approvals. Several informational findings were also noted.

2 High2 Medium2 Informational
Volume 24h
$74.1K
Liquidity
$226.9K
Price
$0.002647
Token Age
5mo
Top 10 Holders
52.3%

Security Findings

2 High2 Med2 Info
High

Lack of Slippage Control in `_swapAndLiquify`

H-01The `_swapAndLiquify` function, responsible for swapping collected tax tokens for ETH, uses `IUniswapV2Router02.swapExactTokensForETHSupportingFeeOnTransferTokens` without specifying a `minAmountOut` parameter. This omission exposes the swap to significant slippage, front-running, and sandwich attacks, potentially leading to a substantial loss of value for the protocol's collected taxes.
IssueThe `_swapAndLiquify` function, responsible for swapping collected tax tokens for ETH, uses `IUniswapV2Router02.swapExactTokensForETHSupportingFeeOnTransferTokens` without specifying a `minAmountOut` parameter. This omission exposes the swap to significant slippage, front-running, and sandwich attacks, potentially leading to a substantial loss of value for the protocol's collected taxes.
FixImplement a `minAmountOut` parameter for the `swapExactTokensForETHSupportingFeeOnTransferTokens` call. This value should be calculated based on a reasonable slippage tolerance (e.g., 0.5% - 1%) at the time of the transaction. Consider using a price oracle or a time-weighted average price (TWAP) to determine a safe `minAmountOut` if precise control is needed, or allow the owner to set a dynamic slippage tolerance.
StatusUnresolved
High

Centralization Risk with `setUniswapRouter`

H-02The `setUniswapRouter` function allows the contract `owner` to change the `_uniswapRouter` address to any arbitrary address. If the owner's private key is compromised or the owner acts maliciously, they could set a rogue router contract. This rogue router could then be used to drain tokens from the `AgentToken` contract during subsequent `_swapAndLiquify` operations or other interactions, leading to a complete loss of funds.
IssueThe `setUniswapRouter` function allows the contract `owner` to change the `_uniswapRouter` address to any arbitrary address. If the owner's private key is compromised or the owner acts maliciously, they could set a rogue router contract. This rogue router could then be used to drain tokens from the `AgentToken` contract during subsequent `_swapAndLiquify` operations or other interactions, leading to a complete loss of funds.
FixImplement a multi-signature wallet for the `owner` address to control critical functions like `setUniswapRouter`. Additionally, consider a time-lock mechanism for such sensitive changes, allowing users to react to a potentially malicious update. Restrict the `_uniswapRouter` to a whitelist of trusted router addresses if possible.
StatusUnresolved
Medium

Complex Bot Protection Logic with `keccak256(address.code)`

M-01The `_checkBotProtection` function utilizes `keccak256(address.code)` to identify valid callers. While `addLiquidityPool` checks for `code.length`, `addValidCaller` does not. If `keccak256("")` (the hash for an empty code, typical of an EOA) is added to `_validCallerCodeHashes`, EOAs could potentially bypass bot protection. Furthermore, relying on `address.code` can be complex and potentially lead to unexpected behavior, especially with contracts deployed within the same transaction or during specific contract lifecycle stages.
IssueThe `_checkBotProtection` function utilizes `keccak256(address.code)` to identify valid callers. While `addLiquidityPool` checks for `code.length`, `addValidCaller` does not. If `keccak256("")` (the hash for an empty code, typical of an EOA) is added to `_validCallerCodeHashes`, EOAs could potentially bypass bot protection. Furthermore, relying on `address.code` can be complex and potentially lead to unexpected behavior, especially with contracts deployed within the same transaction or during specific contract lifecycle stages.
FixReview the bot protection logic carefully. Ensure that `_validCallerCodeHashes` cannot contain `keccak256("")` unless EOAs are explicitly intended to bypass protection. Consider alternative, more robust methods for bot detection or whitelisting, such as role-based access control or specific contract interfaces, rather than relying solely on code hashes, which can be brittle.
StatusUnresolved
Medium

`type(uint256).max` Approvals for Uniswap Router

M-02The `_addInitialLiquidity` and `_swapAndLiquify` functions grant `type(uint256).max` (unlimited) approval to the `_uniswapRouter` for `AgentToken` and `pairToken`. While `_uniswapRouter` is expected to be a trusted Uniswap V2 router, unlimited approvals are generally discouraged as a security best practice. If the `_uniswapRouter` contract were ever compromised or replaced with a malicious one (as per H-02), it could potentially drain all approved tokens from the `AgentToken` contract.
IssueThe `_addInitialLiquidity` and `_swapAndLiquify` functions grant `type(uint256).max` (unlimited) approval to the `_uniswapRouter` for `AgentToken` and `pairToken`. While `_uniswapRouter` is expected to be a trusted Uniswap V2 router, unlimited approvals are generally discouraged as a security best practice. If the `_uniswapRouter` contract were ever compromised or replaced with a malicious one (as per H-02), it could potentially drain all approved tokens from the `AgentToken` contract.
FixWhere possible, use specific, limited approvals instead of `type(uint256).max`. For `_swapAndLiquify`, approve only the exact `amountToSwap`. For initial liquidity, if `type(uint256).max` is deemed necessary for ongoing operations, ensure robust access control and monitoring for the `_uniswapRouter` address.
StatusUnresolved
Info

Missing Events for Critical State Changes

I-01Several administrative functions that modify critical contract parameters, such as `setProjectTaxRecipient`, `setProjectBuyTaxBasisPoints`, `setProjectSellTaxBasisPoints`, `setSwapThresholdBasisPoints`, `setUniswapRouter`, and `setBotProtectionDurationInSeconds`, do not emit corresponding events. This lack of event emission hinders transparency, makes off-chain monitoring and auditing of administrative actions difficult, and can obscure important changes to the contract's behavior.
IssueSeveral administrative functions that modify critical contract parameters, such as `setProjectTaxRecipient`, `setProjectBuyTaxBasisPoints`, `setProjectSellTaxBasisPoints`, `setSwapThresholdBasisPoints`, `setUniswapRouter`, and `setBotProtectionDurationInSeconds`, do not emit corresponding events. This lack of event emission hinders transparency, makes off-chain monitoring and auditing of administrative actions difficult, and can obscure important changes to the contract's behavior.
FixEmit events for all administrative actions that modify critical state variables. This provides a clear, immutable log of changes, improving transparency and enabling better monitoring and accountability.
StatusUnresolved
Info

Unused `CALL_GAS_LIMIT` Constant

I-02The constant `CALL_GAS_LIMIT` is declared in the contract but is not utilized anywhere within the provided source code. This might indicate leftover code from previous iterations, a planned feature that was not implemented, or an oversight.
IssueThe constant `CALL_GAS_LIMIT` is declared in the contract but is not utilized anywhere within the provided source code. This might indicate leftover code from previous iterations, a planned feature that was not implemented, or an oversight.
FixRemove unused code to reduce contract size and improve readability. If it's intended for a future feature, consider adding a comment explaining its purpose.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates a solid architectural foundation by leveraging OpenZeppelin's upgradeable contracts (7.1 Architecture). Code security (7.2 Code Security) benefits from standard ERC20 implementations and a reentrancy guard for the swap function. However, the lack of slippage control in the `_swapAndLiquify` function (H-01) exposes collected taxes to significant value loss. The bot protection logic (M-01) is complex and relies on `keccak256(address.code)`, which can be brittle. Access control (7.3 Access Control) is generally well-managed with `Ownable2StepUpgradeable` and `onlyOwnerOrFactory` modifiers.

GovernanceHigh1/10

The contract includes economic mechanisms for project taxes on buys and sells, with an automated swap-and-liquify feature (7.4 Economic). This design aims to sustain the project's treasury. However, the absence of slippage protection in the automated swap (H-01) directly impacts the economic stability by potentially reducing the value of collected taxes. Governance (7.5 Governance) is centralized with an `owner` and `_factory` role, which is common for initial phases. The `setUniswapRouter` function (H-02) presents a significant centralization risk, allowing the owner to change a critical external dependency to a potentially malicious address. External interactions (7.6 External) with Uniswap V2 are standard but lack robust error handling for slippage.

UpgradesMedium6/10

The contract is designed as an upgradeable proxy using OpenZeppelin's `Initializable` and `Ownable2StepUpgradeable` patterns (7.7 Upgrades). The `_disableInitializers()` in the constructor and the `initialize` function adhere to best practices for upgradeable contracts, minimizing common upgrade-related risks. The use of `Ownable2StepUpgradeable` for ownership transfers further enhances upgrade safety. No immediate upgrade safety issues were identified.

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

52.3% in top 10
15.0% in wallets37.3% in contracts
Effective Concentration29.9%

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

$240.5K across 4 pairs
Uniswap v2VIRTUALanalysed$226.9K94.3%Uniswap v4DIEM$10.6K4.4%Uniswap v4WETH$2.1K0.9%EqualizerWETH$9000.4%

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x4069…9fbe
Unlocked LP Held By
0x31e8…8130

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

What Raised This Score

7 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 20% (52.3% total → 29.9% effective; 15.0% in EOAs, 37.3% in contracts — mild)
  • 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, pool = 94% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 94% of DEX liquidity)
  • 2 High finding(s) from audit
  • 2 Medium 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 RiskREPPOCritical Risk1claw AI (1CLAWAI)Critical RiskRecallCritical RiskVANRYCritical Risk

Would You Like a More Detailed Audit of SIBYL by Virtuals?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit