Is Chip Safe? Smart Contract Security Analysis

Security Findings

1 High1 Low1 Info

High

Centralized Control of Critical Roles and Token Supply

H-01The `OToken` contract relies heavily on `AccessControlUpgradeable` for managing critical operations. The `DEFAULT_ADMIN_ROLE` (assigned during initialization) has the power to grant and revoke any role, including the `BRIDGE_ADMIN_ROLE`. The `BRIDGE_ADMIN_ROLE` is solely responsible for `mint` and `burn` operations, directly controlling the token's total supply. A compromise of the `DEFAULT_ADMIN_ROLE` or `BRIDGE_ADMIN_ROLE` could lead to unauthorized minting, burning, or manipulation of token supply, severely impacting the token's value and integrity (7.3 Access Control, 7.4 Economic, 7.5 Governance).

IssueThe `OToken` contract relies heavily on `AccessControlUpgradeable` for managing critical operations. The `DEFAULT_ADMIN_ROLE` (assigned during initialization) has the power to grant and revoke any role, including the `BRIDGE_ADMIN_ROLE`. The `BRIDGE_ADMIN_ROLE` is solely responsible for `mint` and `burn` operations, directly controlling the token's total supply. A compromise of the `DEFAULT_ADMIN_ROLE` or `BRIDGE_ADMIN_ROLE` could lead to unauthorized minting, burning, or manipulation of token supply, severely impacting the token's value and integrity (7.3 Access Control, 7.4 Economic, 7.5 Governance).

FixImplement robust multi-signature governance for the `DEFAULT_ADMIN_ROLE` to ensure no single entity can unilaterally control critical roles. For the `BRIDGE_ADMIN_ROLE`, consider a multi-signature setup or a more decentralized mechanism if feasible, and ensure its operational security is paramount.

StatusUnresolved

Low

No Dedicated Emergency Pause Mechanism

L-01The contract lacks a dedicated `Pausable` mechanism to halt token transfers or mint/burn operations in an emergency (e.g., exploit, critical bug). While `AccessControl` can restrict `mint`/`burn`, it doesn't cover `transfer` or `approve` functions, which could be exploited in certain scenarios (7.2 Code Security, 7.8 Operations).

IssueThe contract lacks a dedicated `Pausable` mechanism to halt token transfers or mint/burn operations in an emergency (e.g., exploit, critical bug). While `AccessControl` can restrict `mint`/`burn`, it doesn't cover `transfer` or `approve` functions, which could be exploited in certain scenarios (7.2 Code Security, 7.8 Operations).

FixConsider integrating OpenZeppelin's `PausableUpgradeable` for a global emergency stop functionality, controlled by a trusted multi-signature wallet. This would provide a rapid response capability to mitigate ongoing exploits or critical vulnerabilities.

StatusUnresolved

Info

Unnecessary `nonReentrant` Modifier

I-01The `mint` and `burn` functions are protected by the `nonReentrant` modifier. However, these functions do not perform any external calls that could lead to reentrancy. While harmless, the modifier adds a small, unnecessary gas cost to these operations (7.2 Code Security).

IssueThe `mint` and `burn` functions are protected by the `nonReentrant` modifier. However, these functions do not perform any external calls that could lead to reentrancy. While harmless, the modifier adds a small, unnecessary gas cost to these operations (7.2 Code Security).

FixRemove the `nonReentrant` modifier from `mint` and `burn` functions as they do not interact with external contracts. If future upgrades introduce external calls within these functions, the modifier can be re-added.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The OToken contract demonstrates strong technical foundations by inheriting from OpenZeppelin's `ERC20Upgradeable`, `AccessControlUpgradeable`, and `ReentrancyGuardTransient` (7.2 Code Security). The use of `nonReentrant` on `mint` and `burn` functions, although not strictly necessary given their current implementation, showcases a proactive approach to security. The contract correctly implements the `initializer` pattern for upgradeability and uses a recent Solidity compiler version (0.8.33).

GovernanceHigh1/10

The contract's economic model features centralized control over token supply (7.4 Economic). The `BRIDGE_ADMIN_ROLE` has exclusive rights to mint and burn tokens, with the `DEFAULT_ADMIN_ROLE` having the power to manage all roles, including the `BRIDGE_ADMIN_ROLE` (7.3 Access Control, 7.5 Governance). This design introduces a significant trust assumption, as a compromise of these roles could lead to arbitrary token supply manipulation. Robust multi-signature or decentralized governance for these critical roles is essential to mitigate this risk.

UpgradesHigh1/10

The OToken contract is deployed behind a TransparentUpgradeableProxy, leveraging OpenZeppelin's upgradeable patterns (7.7 Upgrades). The `initialize` function correctly uses the `initializer` modifier, and the constructor disables initializers to prevent re-initialization. Crucially, the proxy's admin is controlled by a Timelock with a 2-day delay, providing a window for review and reaction before any upgrade takes effect, significantly enhancing upgrade safety.

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent

AdminOZ ProxyAdmin

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

87.8% in top 10

73.5% in wallets14.3% in contracts

Effective Concentration79.2%

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

$102.2K

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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

2 addresses

Deployer

0x9868…79b2

Unlocked LP Held By

0xe776…cf78

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

What Raised This Score

9 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% (87.8% total → 79.2% effective; 73.5% in EOAs, 14.3% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
1 High 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

Is Chip Safe?

Security Findings

Centralized Control of Critical Roles and Token Supply

No Dedicated Emergency Pause Mechanism

Unnecessary `nonReentrant` Modifier

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Chip?