On-chain security analysis — is it a scam or legit?
The OliviaAI2 contract implements a standard ERC-20 token with burnable and permit functionalities, leveraging battle-tested OpenZeppelin libraries.
Read the full analysisEach 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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x6728…04220x5a01…a6920xe1f6…806f0x6c94…80160xd0f5…48170xb79c…3b14No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
approve Race Conditionapprove 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.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.
Users 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.
Unresolved
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.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.
For 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.
Unresolved
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.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.
Ensure 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.
Unresolved
The 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.
Consider 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.
Unresolved
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.
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.
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.
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.
It is recommended to carefully manage the private key associated with the contract owner address, considering a multi-signature wallet for enhanced security.
For transparency, clearly communicate the initial token distribution strategy and the implications of the Ownable pattern to the community. While the contract is robust, consider implementing an emergency withdrawal function for accidentally sent tokens to improve operational resilience.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Olivia AI 2.0 ($OLIVIA2.0) contract on Base is 0x8185eaf46136a3f095c60facd97eca1bfc2f38f6. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Olivia AI 2.0 is 28/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.02M.
As of Sep 4, 2026, the 10 largest holders own 98.4% of the supply. The Holders section on this page shows who they are by holder type.
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
