Quantum Audit Logo
Launch App

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

Is Chip Safe?

CHIPBase
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
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The OToken contract serves as an upgradeable ERC-20 token with minting and burning capabilities.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (95.9% total → 93.8% effective; 92.4% in EOAs, 3.5% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 1 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 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
3.5%92.4%Wallets4.1%
92.4%Wallets4.1%
ContractsWalletsEveryone elseBubble area = share of supply
95.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking3.5%
  • Walletsanonymous holders, free to sell92.4%
  • Everyone elsethe rest of the supply4.1%
Effective concentrationwhat the score reads93.8%
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$131.5K across 6 pairs

The risk score reads depth across every pair.

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$131.4KShare of depth99.9%
Top-1 Unlocked Holder99.9%
Top-3 Unlocked100.0%
Unlocked LP held by
0x5ec2…daa70x7234…dece

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control Over Token Supply (Mint/Burn)

The mint and burn functions are exclusively controlled by the BRIDGE_ADMIN_ROLE. This role has the ability to arbitrarily increase or decrease the total supply of OToken. While this is an intended design for a bridge-controlled token, it introduces a significant centralization risk (7.3 Access Control, 7.4 Economic). A compromise of the BRIDGE_ADMIN_ROLE could lead to hyperinflation, deflation, or other manipulations that severely impact the token's value and ecosystem integrity.H-01

Issue

The mint and burn functions are exclusively controlled by the BRIDGE_ADMIN_ROLE. This role has the ability to arbitrarily increase or decrease the total supply of OToken. While this is an intended design for a bridge-controlled token, it introduces a significant centralization risk (7.3 Access Control, 7.4 Economic). A compromise of the BRIDGE_ADMIN_ROLE could lead to hyperinflation, deflation, or other manipulations that severely impact the token's value and ecosystem integrity.

Fix

Ensure the BRIDGE_ADMIN_ROLE is secured by a robust multi-signature wallet with a high threshold or a decentralized autonomous organization (DAO) with a timelock. Implement strict operational security procedures for managing the keys associated with this role. Consider implementing rate limits or maximum mint/burn amounts per period to mitigate the impact of a potential compromise.

Status

Unresolved

Medium

Criticality of DEFAULT_ADMIN_ROLE Holder

The initialize function grants the DEFAULT_ADMIN_ROLE to a single admin address. This role has the power to grant and revoke all other roles, including the BRIDGE_ADMIN_ROLE (7.3 Access Control, 7.5 Governance). If the admin address is a single externally owned account (EOA) or a weakly secured multi-signature wallet, it represents a single point of failure. A compromise of this address would allow an attacker to gain full control over all administrative functions of the OToken contract, including the ability to manipulate token supply.M-01

Issue

The initialize function grants the DEFAULT_ADMIN_ROLE to a single admin address. This role has the power to grant and revoke all other roles, including the BRIDGE_ADMIN_ROLE (7.3 Access Control, 7.5 Governance). If the admin address is a single externally owned account (EOA) or a weakly secured multi-signature wallet, it represents a single point of failure. A compromise of this address would allow an attacker to gain full control over all administrative functions of the OToken contract, including the ability to manipulate token supply.

Fix

The admin address provided during initialization for the DEFAULT_ADMIN_ROLE must be a highly secure entity, preferably a multi-signature wallet with a high confirmation threshold or a DAO-controlled contract with a timelock. This ensures that critical administrative actions require consensus and have a delay period, enhancing security and decentralization.

Status

Unresolved

Low

Potential for Accidental Role Renunciation

The renounceRole function allows any account to voluntarily remove a role they possess. While this is a standard OpenZeppelin feature, if a critical role holder (e.g., DEFAULT_ADMIN_ROLE or BRIDGE_ADMIN_ROLE) accidentally renounces their role without ensuring another authorized account can re-grant it, it could lead to an operational issue where essential functions become inaccessible (7.8 Operations).L-01

Issue

The renounceRole function allows any account to voluntarily remove a role they possess. While this is a standard OpenZeppelin feature, if a critical role holder (e.g., DEFAULT_ADMIN_ROLE or BRIDGE_ADMIN_ROLE) accidentally renounces their role without ensuring another authorized account can re-grant it, it could lead to an operational issue where essential functions become inaccessible (7.8 Operations).

Fix

Educate role holders on the implications of renounceRole. Implement clear operational procedures for role management, including ensuring multiple accounts hold critical roles or that a recovery mechanism is in place before any role is renounced. Consider adding a check or a timelock to renounceRole for critical roles if the operational context allows.

Status

Unresolved

Info

Absence of a Pause Mechanism

The OToken contract currently lacks a pause mechanism. In the event of an emergency, such as a critical vulnerability discovered in the contract itself, a connected bridge, or a wider ecosystem exploit, the ability to temporarily halt token transfers, minting, or burning could be crucial to mitigate damage (7.1 Architecture, 7.8 Operations). Without such a mechanism, the only recourse would be an upgrade, which typically involves a timelock delay.I-01

Issue

The OToken contract currently lacks a pause mechanism. In the event of an emergency, such as a critical vulnerability discovered in the contract itself, a connected bridge, or a wider ecosystem exploit, the ability to temporarily halt token transfers, minting, or burning could be crucial to mitigate damage (7.1 Architecture, 7.8 Operations). Without such a mechanism, the only recourse would be an upgrade, which typically involves a timelock delay.

Fix

Consider implementing OpenZeppelin's PausableUpgradeable module. This would allow a designated role (e.g., a PAUSER_ROLE controlled by a multi-sig) to pause and unpause critical operations, providing an immediate emergency response capability. Ensure the pauser role is also securely managed.

Status

Unresolved

Analysis

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

The OToken contract serves as an upgradeable ERC-20 token with minting and burning capabilities. It leverages battle-tested OpenZeppelin libraries for its core functionalities, including upgradeability, access control, and reentrancy protection. The primary risks identified relate to the centralized control over token supply manipulation (mint/burn) and the critical importance of securing the administrative roles. The upgrade mechanism is robust, utilizing a TransparentUpgradeableProxy with a Timelock for the proxy admin.

Technical6/10Medium risk

The contract demonstrates strong technical security (7.2 Code Security) by inheriting from OpenZeppelin's robust and audited libraries, including ERC20Upgradeable, AccessControlUpgradeable, and ReentrancyGuardTransient. The mint and burn functions are correctly protected by the nonReentrant modifier, mitigating reentrancy risks. Solidity version 0.8.33 inherently provides overflow/underflow protection, and no custom arithmetic operations introduce new integer safety concerns. The use of MulticallUpgradeable is a utility feature and does not introduce security vulnerabilities.

Governance1/10High risk

The economic model (7.4 Economic) of OToken relies heavily on centralized control for its core functions. The BRIDGE_ADMIN_ROLE has the power to mint and burn arbitrary amounts of tokens, which represents a significant centralization risk (7.3 Access Control). If this role is compromised, the token's supply and value could be severely manipulated. The DEFAULT_ADMIN_ROLE (7.5 Governance) can grant or revoke any role, including BRIDGE_ADMIN_ROLE, making the security of the admin address passed during initialization paramount. It is crucial that these administrative roles are controlled by robust, multi-signature wallets or a decentralized autonomous organization (DAO) with a timelock.

Upgrades1/10High risk

The contract is designed for upgradeability (7.7 Upgrades) using OpenZeppelin's TransparentUpgradeableProxy pattern. The _disableInitializers() in the constructor and the initializer modifier on the initialize function correctly prevent re-initialization attacks. OpenZeppelin's upgradeable contracts utilize explicit storage slots, effectively mitigating storage collision risks during upgrades. The proxy's admin is controlled by a Timelock () with a 2-day delay, providing a strong safety mechanism for future upgrades.

Final RecommendationWhat to do about this score

Prioritize the secure management of the DEFAULT_ADMIN_ROLE and BRIDGE_ADMIN_ROLE private keys.

Implement a robust multi-signature wallet or DAO governance with a timelock for these critical roles to minimize single points of failure and provide a delay for critical operations. Consider implementing a pause mechanism to provide an emergency stop functionality for token transfers, minting, and burning in case of unforeseen vulnerabilities or external bridge exploits.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBase
Token age1y
Contract0x0c1c…1f6e
Deployer0x9868…79b2
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Timelock
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Chip 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. Aug 17, 202676High

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

Related Audits

6 more on the recordAll audits
defi-nativeBase76HighXRP (Universal)UXRP · Base76HighVCATBase76HighMEGA YACHT CULTMYC · Base76HighWrapped PROSPROS · Base77HighCortexCX · Base77High

Would You Like a More Detailed Audit of Chip?

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