Quantum Audit Logo

Is ChainOpera AI Safe?

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

Is this your token? Publish your own audit on this page →

ChainOpera AI COAI
0x0a8d…6ea5
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

The contract at 0x0a8d6c86e1bce73fe4d0bd531e1a567306836ea5 is an ERC-1967 UUPS proxy. While the proxy itself utilizes well-audited OpenZeppelin libraries, its implementation contract (0xa9d0b1770ad65cbc4f5dffc0f24f42c57933a877) is not source verified on BSCScan. This lack of transparency poses a critical security risk, as the actual logic, access control, and upgrade mechanisms are entirely unknown and could be malicious.

1 Critical2 High1 Informational
Volume 24h
$3.96M
Liquidity
$1.91M
Price
$0.3212
Token Age
10mo
Top 10 Holders
84.0%

Security Findings

Critical

Unverified Implementation Contract

C-01The proxy contract at 0x0a8d…6ea5 delegates all calls to its implementation contract at 0xa9d0…a877. However, the source code for this implementation contract is not verified on BSCScan. This means the actual logic, state variables, and security mechanisms of the contract are unknown, making it impossible to assess its safety or functionality. This is a fundamental security flaw (7.2 Code Security).
IssueThe proxy contract at delegates all calls to its implementation contract at . However, the source code for this implementation contract is not verified on BSCScan. This means the actual logic, state variables, and security mechanisms of the contract are unknown, making it impossible to assess its safety or functionality. This is a fundamental security flaw (7.2 Code Security).
FixImmediately verify the source code of the implementation contract () on BSCScan. Without source verification, the contract should be considered unauditable and unsafe.
StatusUnresolved
High

Opaque Upgrade Mechanism

H-01The contract uses the UUPS (Universal Upgradeable Proxy Standard) pattern, where the implementation contract itself contains the upgrade logic. Since the implementation contract (0xa9d0…a877) is unverified, the upgrade mechanism (7.7 Upgrades) is opaque. A malicious or compromised implementation could contain arbitrary upgrade logic, allowing an attacker to change the proxy's implementation to a contract with malicious code, potentially leading to a complete loss of funds or control.
IssueThe contract uses the UUPS (Universal Upgradeable Proxy Standard) pattern, where the implementation contract itself contains the upgrade logic. Since the implementation contract () is unverified, the upgrade mechanism (7.7 Upgrades) is opaque. A malicious or compromised implementation could contain arbitrary upgrade logic, allowing an attacker to change the proxy's implementation to a contract with malicious code, potentially leading to a complete loss of funds or control.
FixVerify the source code of the implementation contract to allow for a thorough audit of its upgrade logic. Ensure that upgrade permissions are appropriately restricted, ideally to a multi-signature wallet or a time-locked governance contract.
StatusUnresolved
High

Unknown Functionality and Access Control

H-02All core functionality, including asset handling, privileged roles, and critical operations, resides within the unverified implementation contract (0xa9d0…a877). Without its source code, it is impossible to determine the contract's intended behavior, assess its access control mechanisms (7.3 Access Control), or identify potential backdoors or vulnerabilities that could lead to unauthorized actions or economic exploits (7.4 Economic).
IssueAll core functionality, including asset handling, privileged roles, and critical operations, resides within the unverified implementation contract (). Without its source code, it is impossible to determine the contract's intended behavior, assess its access control mechanisms (7.3 Access Control), or identify potential backdoors or vulnerabilities that could lead to unauthorized actions or economic exploits (7.4 Economic).
FixVerify the source code of the implementation contract to enable a full security assessment of its functionality, access control, and economic model. Implement robust access control with multi-signature or time-lock mechanisms for critical functions.
StatusUnresolved
Info

Adherence to ERC-1967 UUPS Standard

I-01The proxy contract itself correctly implements the ERC-1967 UUPS proxy pattern using battle-tested OpenZeppelin libraries. This indicates a standard and well-understood architectural approach (7.1 Architecture) for upgradeability, assuming the implementation contract is also secure.
IssueThe proxy contract itself correctly implements the ERC-1967 UUPS proxy pattern using battle-tested OpenZeppelin libraries. This indicates a standard and well-understood architectural approach (7.1 Architecture) for upgradeability, assuming the implementation contract is also secure.
FixNo direct recommendation for the proxy contract itself, as it follows established standards. The primary recommendation is to ensure the security of the implementation contract.
StatusResolved

Category Ratings

TechnicalMedium5/10

The proxy contract correctly implements the ERC-1967 UUPS pattern using battle-tested OpenZeppelin libraries, which provides a strong foundation for architectural security (7.1 Architecture). However, the critical issue is that the underlying implementation contract () is not source verified. This means the actual code security (7.2 Code Security) cannot be assessed, and its functionality is opaque, presenting a significant technical risk.

GovernanceHigh1/10

The economic model and governance mechanisms (7.4 Economic, 7.5 Governance) are entirely defined within the unverified implementation contract. Without its source code, it is impossible to determine if there are any backdoors, privileged roles, or economic exploits. This lack of transparency presents a severe risk to users and the protocol's integrity.

UpgradesHigh2/10

The contract utilizes the UUPS proxy pattern, where the implementation contract itself controls upgrades (7.7 Upgrades). While UUPS is a standard pattern, the unverified nature of the implementation means that the upgrade logic is unknown. A malicious or compromised implementation could arbitrarily upgrade the proxy to any address, potentially leading to a complete loss of funds or control.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source

Holder Composition

3.8% in wallets80.2% in contracts
Effective Concentration35.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

Show 4 more pairsShow less

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

Key Addresses

Deployer
0x0303…0b6a
Unlocked LP Held By
0xaf1a…be170xaaf2…a6010xd9ad…119f0x040d…628e0x67fb…58870xe080…e3630x4863…01180x750b…960c0x3470…a1250x4148…ee62

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

What Raised This Score

  • Ownership NOT renounced — Timelock 48h delay (exit window)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (84.0% total → 35.9% effective; 3.8% in EOAs, 80.2% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 82.2% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 99.6% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 2 High 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

Yooldo Games (ESPORTS)High RiskAKEHigh RiskSIXSEVEN (67)High RiskOPENHigh RiskBaby Ansem (BABYANSEM)High RiskEVAAHigh Risk

Would You Like a More Detailed Audit of ChainOpera AI?

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

Get Detailed Audit