Quantum Audit Logo

Is Olivia AI 2.0 Safe?

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

Olivia AI 2.0 $OLIVIA2.0
0x8185…38f6
Base Not verifiedLast checked 3d ago 1 audit on record
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The OliviaAI2 contract implements a standard ERC-20 token with burnable and permit functionalities, leveraging battle-tested OpenZeppelin libraries. The contract exhibits high code quality and minimal custom logic, leading to a low technical risk profile. Identified issues are primarily informational or low severity, related to standard ERC-20 design patterns and best practices rather than critical vulnerabilities.

1 Low3 Informational
Volume 24h
$40.8K
Liquidity
$1.02M
Price
$0.04689
Token Age
3mo
Top 10 Holders
98.4%

Security Findings

Low

Standard ERC-20 `approve` Race Condition

L-01The standard ERC-20 `approve` function is susceptible to a known race condition. If a user increases an allowance, a malicious actor could front-run the transaction, spend the original allowance, and then the user's new `approve` transaction would grant an allowance on top of the already spent amount, potentially leading to a double-spend of the allowance. While `ERC20Permit` offers an alternative, the `approve` function remains vulnerable.
IssueThe standard ERC-20 `approve` function is susceptible to a known race condition. If a user increases an allowance, a malicious actor could front-run the transaction, spend the original allowance, and then the user's new `approve` transaction would grant an allowance on top of the already spent amount, potentially leading to a double-spend of the allowance. While `ERC20Permit` offers an alternative, the `approve` function remains vulnerable.
FixUsers should be advised to set allowances to zero before increasing them, or to use the `increaseAllowance` and `decreaseAllowance` functions (if available in a `ERC20` variant, though not directly in this specific OpenZeppelin version) to mitigate this risk. For new approvals, `ERC20Permit` can be used as a safer alternative.
StatusUnresolved
Info

Centralized Ownership

I-01The contract utilizes the `Ownable` pattern, which grants a single external address (the owner) exclusive control over certain administrative functions, specifically `transferOwnership` and `renounceOwnership`. While standard for many tokens, this introduces a single point of control.
IssueThe contract utilizes the `Ownable` pattern, which grants a single external address (the owner) exclusive control over certain administrative functions, specifically `transferOwnership` and `renounceOwnership`. While standard for many tokens, this introduces a single point of control.
FixFor enhanced security and decentralization, consider transitioning ownership to a multi-signature wallet or a decentralized autonomous organization (DAO) if the project's roadmap allows for it. If a single owner is intended, ensure robust security practices for the owner's private key.
StatusUnresolved
Info

Initial Supply Centralization

I-02The constructor mints the entire `initialSupply` to a single `initialHolder` address. This design choice centralizes the initial token distribution to one entity, which could have significant control over the token's early market dynamics.
IssueThe constructor mints the entire `initialSupply` to a single `initialHolder` address. This design choice centralizes the initial token distribution to one entity, which could have significant control over the token's early market dynamics.
FixEnsure that the implications of this initial distribution are clearly communicated to the community. If a more decentralized distribution is desired, consider implementing a vesting schedule, airdrop mechanism, or a public sale contract for future token distribution.
StatusUnresolved
Info

No Emergency Withdrawal for Accidental ETH/Token Transfers

I-03The contract does not include a mechanism for the owner to recover accidentally sent ETH or other ERC-20 tokens that are not the contract's native token. Funds sent directly to the contract address, other than the intended token, would be permanently locked.
IssueThe contract does not include a mechanism for the owner to recover accidentally sent ETH or other ERC-20 tokens that are not the contract's native token. Funds sent directly to the contract address, other than the intended token, would be permanently locked.
FixConsider adding a function, callable only by the owner, to withdraw arbitrary ERC-20 tokens or native blockchain currency (ETH/MATIC/BNB etc.) that might be accidentally sent to the contract. This improves operational resilience and prevents loss of funds.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is robust, relying on well-audited OpenZeppelin contracts for ERC-20, ERC-20Burnable, ERC-20Permit, and Ownable functionalities. Code security (7.2) is strong, with Solidity 0.8.x providing default overflow/underflow checks and OpenZeppelin's careful use of `unchecked` blocks. Access control (7.3) is managed via the standard Ownable pattern, limiting owner privileges to ownership transfer and renunciation. No complex external interactions (7.6) are present, minimizing attack surface.

GovernanceHigh3/10

The economic model (7.4) is that of a simple ERC-20 token with an initial supply minted to a single holder. Governance (7.5) is centralized through the `Ownable` pattern, where a single address controls the ability to transfer or renounce ownership. While this grants some control, the owner does not possess privileged functions like arbitrary minting, burning of others' tokens, or blacklisting, thus limiting potential economic manipulation. The initial distribution to a single holder is a design choice that should be transparently communicated.

UpgradesLow9/10

The contract is not designed with an upgrade mechanism (7.7) and is not deployed as a proxy. Therefore, there are no upgrade-related risks. Any changes to the contract's logic would require a new deployment.

Security Checklist

Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

96.0% in wallets2.4% in contracts
Effective Concentration97.0%

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

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 Holder98.2%
Top-3 Unlocked99.7%

Key Addresses

Deployer
0x874d…b1c7
Unlocked LP Held By
0x6728…04220x5a01…a6920xe1f6…806f0x6c94…80160xd0f5…48170xb79c…3b14

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

What Raised This Score

  • Top-10 concentration > 70% (98.4% total → 97.0% effective; 96.0% in EOAs, 2.4% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.2% (independent LP — depth risk)
  • LP top3 unlocked holders = 99.7% (independent LP — depth risk)
  • 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

Meta Platforms Inc. (METAC)Medium RiskVibestarter (VIBES)Medium RiskPORTALMedium RiskBaselineMedium RiskSurplus Intelligence (SURPLUS)Medium RiskCoinbase Man (BRIAN)Medium Risk

Would You Like a More Detailed Audit of Olivia AI 2.0?

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

Get Detailed Audit