On-chain security analysis — is it a scam or legit?
BNB ChainThe contract at 0x0a8d6c86e1bce73fe4d0bd531e1a567306836ea5 is an ERC-1967 UUPS proxy.
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.
0xaf1a…be170xaaf2…a6010xd9ad…119f0x040d…628e0x67fb…58870xe080…e3630x4863…01180x750b…960c0x3470…a1250x4148…ee62No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
The 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).
Immediately verify the source code of the implementation contract () on BSCScan. Without source verification, the contract should be considered unauditable and unsafe.
Unresolved
The 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.
Verify 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.
Unresolved
All 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).
Verify 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.
Unresolved
The 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.
No direct recommendation for the proxy contract itself, as it follows established standards. The primary recommendation is to ensure the security of the implementation contract.
Resolved
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.
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.
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.
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.
It is critically important to immediately verify the source code of the implementation contract at on BSCScan.
Until the implementation's source is publicly available and thoroughly audited, the contract should be considered unsafe for use, as its functionality, security, and upgradeability are entirely unknown. Users should exercise extreme caution.
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 ChainOpera AI (COAI) contract on BNB Chain is 0x0a8d6c86e1bce73fe4d0bd531e1a567306836ea5. 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 ChainOpera AI is 52/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.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.92M.
As of Sep 4, 2026, the 10 largest holders own 84.0% 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
