Is Chip Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Centralized Control Over Token Supply (Mint/Burn)

H-01The `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.

IssueThe `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.

FixEnsure 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.

StatusUnresolved

Medium

Criticality of DEFAULT_ADMIN_ROLE Holder

M-01The `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.

IssueThe `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.

FixThe `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.

StatusUnresolved

Low

Potential for Accidental Role Renunciation

L-01The `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).

IssueThe `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).

FixEducate 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.

StatusUnresolved

Info

Absence of a Pause Mechanism

I-01The 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.

IssueThe 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.

FixConsider 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.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh1/10

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.

UpgradesHigh1/10

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.

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

95.9% in top 10

92.4% in wallets3.5% in contracts

Effective Concentration93.8%

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

$131.5K across 6 pairs

AerodromeUSDCanalysed$131.4K Uniswap v4ETH$45 PancakeswapUSDC$31 Uniswap v4ETH$11 Uniswap v4USDC$1 Uniswap v4USDC$0

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 Holder99.9%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0x9868…79b2

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.

What Raised This Score

10 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

Is Chip Safe?

Security Findings

Centralized Control Over Token Supply (Mint/Burn)

Criticality of DEFAULT_ADMIN_ROLE Holder

Potential for Accidental Role Renunciation

Absence of a Pause Mechanism

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?