Quantum Audit Logo
Launch App

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

Is Ribbita by Virtuals Safe?

TIBBIRBase
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
SummaryAI Copilot

The AgentToken contract is an upgradeable ERC20-like token with integrated tax mechanisms, liquidity management via Uniswap V2, and a custom access control model involving a factory contract.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Proxy contract
  • Non-standard proxy storage
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.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)
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.9% (independent LP — depth risk, pool = 86% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 86% 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
16.0%Wallets83.0%Everyone else
16.0%Wallets83.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
17.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking0.9%
  • Walletsanonymous holders, free to sell16.0%
  • Everyone elsethe rest of the supply83.0%
Effective concentrationwhat the score reads16.4%
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$3.85M across 11 pairs
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$3.30MShare of depth85.6%
Top-1 Unlocked Holder98.9%
Top-3 Unlocked100.0%
Unlocked LP held by
0x4188…eb4a0x92d0…e5150x6313…1a60

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

Centralization Risk via Factory Address

The _factory address, set during initialization, is granted extensive administrative control through the onlyOwnerOrFactory modifier. This includes the ability to add/remove liquidity pools, manage valid callers, and set critical tax parameters. If the factory contract is compromised or poorly secured (e.g., a single EOA), it could lead to a complete compromise of the token's configurable parameters, allowing an attacker to manipulate taxes, liquidity, or block legitimate callers.H-01

Issue

The _factory address, set during initialization, is granted extensive administrative control through the onlyOwnerOrFactory modifier. This includes the ability to add/remove liquidity pools, manage valid callers, and set critical tax parameters. If the factory contract is compromised or poorly secured (e.g., a single EOA), it could lead to a complete compromise of the token's configurable parameters, allowing an attacker to manipulate taxes, liquidity, or block legitimate callers.

Fix

Implement robust security measures for the _factory address. Consider using a multi-signature wallet or a well-audited governance contract for the factory to distribute control and reduce the risk of a single point of failure. Clearly document the responsibilities and security requirements for the factory address.

Status

Unresolved

Medium

Potential for High Tax Rates

The projectBuyTaxBasisPoints and projectSellTaxBasisPoints can be set by the owner or factory. While MAX_SWAP_THRESHOLD_MULTIPLE is defined, the provided code snippet does not show any explicit upper bounds or validation checks on the tax basis points themselves. Without such limits, an authorized entity could set excessively high tax rates, effectively rendering the token illiquid or unusable, leading to a loss of user funds or project failure.M-01

Issue

The projectBuyTaxBasisPoints and projectSellTaxBasisPoints can be set by the owner or factory. While MAX_SWAP_THRESHOLD_MULTIPLE is defined, the provided code snippet does not show any explicit upper bounds or validation checks on the tax basis points themselves. Without such limits, an authorized entity could set excessively high tax rates, effectively rendering the token illiquid or unusable, leading to a loss of user funds or project failure.

Fix

Implement explicit upper limits for projectBuyTaxBasisPoints and projectSellTaxBasisPoints to prevent economically destructive configurations. These limits should be carefully chosen to maintain token utility and liquidity, and ideally, any changes to these limits should be subject to a time-lock or governance vote.

Status

Unresolved

Medium

Reliance on Uniswap V2 Price for Tax Swaps

The contract relies on Uniswap V2 for price discovery when performing tax swaps (implied by _uniswapRouter and swapThresholdBasisPoints). Uniswap V2's spot price is susceptible to manipulation, especially for low-liquidity pairs, through flash loans or large trades. If the pairToken is easily manipulable, the automated tax swap mechanism could be exploited to execute swaps at unfavorable rates, leading to value loss for the protocol or its users.M-02

Issue

The contract relies on Uniswap V2 for price discovery when performing tax swaps (implied by _uniswapRouter and swapThresholdBasisPoints). Uniswap V2's spot price is susceptible to manipulation, especially for low-liquidity pairs, through flash loans or large trades. If the pairToken is easily manipulable, the automated tax swap mechanism could be exploited to execute swaps at unfavorable rates, leading to value loss for the protocol or its users.

Fix

For critical operations involving price-sensitive logic, consider integrating more robust and decentralized oracle solutions (e.g., Chainlink) or implementing a time-weighted average price (TWAP) mechanism from Uniswap V2 to mitigate flash loan and price manipulation risks. Ensure sufficient liquidity for the token's pair on Uniswap V2.

Status

Unresolved

Low

Unused CALL_GAS_LIMIT Constant

The constant CALL_GAS_LIMIT is defined within the contract but is not utilized in the provided code snippet. While not a direct vulnerability, unused code can increase contract size, potentially leading to higher deployment costs, and may indicate incomplete or abandoned functionality.L-01

Issue

The constant CALL_GAS_LIMIT is defined within the contract but is not utilized in the provided code snippet. While not a direct vulnerability, unused code can increase contract size, potentially leading to higher deployment costs, and may indicate incomplete or abandoned functionality.

Fix

Review the purpose of CALL_GAS_LIMIT. If it is intended for future functionality, ensure its value is appropriate for the intended external calls. If it is no longer needed, consider removing it to optimize contract size and clarity.

Status

Unresolved

Info

_autoSwapInProgress Reentrancy Guard

The contract utilizes a private boolean flag _autoSwapInProgress which is set to true during initialization and false after initial liquidity is added. This pattern is commonly used as a reentrancy guard to prevent reentrant calls during critical, multi-step operations, likely related to the automated tax swap mechanism (not fully shown in the snippet). This is a good security practice.I-01

Issue

The contract utilizes a private boolean flag _autoSwapInProgress which is set to true during initialization and false after initial liquidity is added. This pattern is commonly used as a reentrancy guard to prevent reentrant calls during critical, multi-step operations, likely related to the automated tax swap mechanism (not fully shown in the snippet). This is a good security practice.

Fix

Ensure that all functions that modify or depend on the state protected by _autoSwapInProgress correctly set and reset the flag to maintain its effectiveness as a reentrancy guard.

Status

Unresolved

Info

Use of EnumerableSet for Dynamic Sets

The contract effectively uses OpenZeppelin's EnumerableSet for managing dynamic collections of addresses (_liquidityPools) and bytes32 hashes (_validCallerCodeHashes). This library provides efficient and secure ways to store and retrieve unique elements, which is a good practice for managing whitelists or lists of external contracts.I-02

Issue

The contract effectively uses OpenZeppelin's EnumerableSet for managing dynamic collections of addresses (_liquidityPools) and bytes32 hashes (_validCallerCodeHashes). This library provides efficient and secure ways to store and retrieve unique elements, which is a good practice for managing whitelists or lists of external contracts.

Fix

Continue to leverage EnumerableSet for managing dynamic sets where efficient iteration and membership checks are required. Ensure that access control for adding and removing elements from these sets remains robust.

Status

Unresolved

Analysis

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

The AgentToken contract is an upgradeable ERC20-like token with integrated tax mechanisms, liquidity management via Uniswap V2, and a custom access control model involving a factory contract. The contract utilizes OpenZeppelin's upgradeable patterns and libraries, contributing to a robust foundation. However, significant centralization risks associated with the factory address's extensive control and potential economic vulnerabilities related to tax parameters and Uniswap V2 price reliance have been identified, leading to an overall 'High' risk level.

Technical8/10Low risk

The contract demonstrates good architectural practices by leveraging OpenZeppelin's upgradeable contracts and using custom error types (7.1 Architecture, 7.2 Code Security). The _autoSwapInProgress flag serves as an effective reentrancy guard for critical operations, enhancing code security. However, the reliance on the _factory address for extensive administrative control introduces a significant centralization risk, as a compromise of this address could lead to unauthorized modifications of token parameters (7.3 Access Control). Additionally, the contract's internal logic for tax swaps depends on Uniswap V2 pricing, which is susceptible to manipulation, especially for low-liquidity pairs (7.6 External).

Governance2/10High risk

The contract's economic model includes configurable buy and sell taxes, which can be adjusted by the owner or factory (7.4 Economic). While this offers flexibility, the absence of explicit upper bounds on these tax rates in the provided snippet could allow for economically destructive configurations, potentially rendering the token illiquid. The onlyOwnerOrFactory modifier grants substantial power to the factory address, which is set during initialization, creating a centralized point of control over critical economic and operational parameters (7.5 Governance, 7.8 Operations). The projectTaxRecipient and vault addresses are also critical operational points that require robust security measures.

Upgrades1/10High risk

The contract correctly implements the UUPS proxy pattern by inheriting from Initializable and calling _disableInitializers() in the constructor, along with using the initializer modifier for setup functions (7.7 Upgrades). Storage variables are declared appropriately, with private variables like _autoSwapInProgress ensuring upgrade safety by preventing accidental overwrites in derived contracts. The use of OpenZeppelin's upgradeable versions of Context and Ownable2Step further strengthens the upgradeability architecture.

Final RecommendationWhat to do about this score

It is crucial to ensure the security and robustness of the _factory address, as it holds significant control over the token's parameters.

Consider implementing a multi-signature wallet or a well-audited governance contract for the factory to mitigate centralization risks. Additionally, establish and enforce reasonable upper limits for tax rates to prevent potential economic instability. For critical operations relying on external price feeds, explore integrating more robust, decentralized oracle solutions or implementing time-weighted average price (TWAP) mechanisms to reduce susceptibility to price manipulation.

Contract & Record

1 audit on record
TypeAgentToken
NetworkBase
Token age1y
Contract0xa4a2…6e00
Deployer0xdb2e…c398
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Ribbita by Virtuals 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, 202656Medium
  2. Aug 11, 202657Medium

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

Frequently Asked Questions

What is the TIBBIR contract address?

The Ribbita by Virtuals (TIBBIR) contract on Base is 0xa4a2e2ca3fbfe21aed83471d28b6f65a233c6e00. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Ribbita by Virtuals a scam?

Quantum Audit's risk score for Ribbita by Virtuals is 56/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is TIBBIR liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $3.85M.

Who holds TIBBIR?

As of Sep 4, 2026, the 10 largest holders own 17.0% of the supply. The Holders section on this page shows who they are by holder type.

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

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