Quantum Audit Logo

Is OMI Token Safe?

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

OMI Token OMI
0x3792…3299
Base
Not verifiedThis 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.
Last checked 18d ago 2 audits on record
Executive SummaryAI Copilot

The OptimismMintableERC20 contract is a standard ERC20 token designed for cross-chain bridging, allowing a designated bridge contract to mint and burn tokens. The contract leverages OpenZeppelin's battle-tested ERC20 implementation and includes versioning via Semver. The primary security consideration is the centralized control over token supply by the immutable BRIDGE address, making the token's integrity highly dependent on the security of the external bridge contract.

1 High1 Medium1 Informational
Volume 24h
$65.9K
Liquidity
$345.8K
Price
$0.0002406
Token Age
2y
Top 10 Holders
28.3%

Security Findings

High

Centralized Control of Token Supply by Bridge

H-01The `OptimismMintableERC20` contract grants exclusive `mint` and `burn` capabilities to a single `BRIDGE` address, set immutably during construction. This design centralizes control over the token's total supply to the security of the designated bridge contract. A compromise of the `BRIDGE` contract would allow an attacker to arbitrarily mint or burn tokens, leading to severe economic consequences for the token and its holders. This represents a critical external dependency and a single point of failure. (7.3 Access Control, 7.4 Economic, 7.6 External)
IssueThe `OptimismMintableERC20` contract grants exclusive `mint` and `burn` capabilities to a single `BRIDGE` address, set immutably during construction. This design centralizes control over the token's total supply to the security of the designated bridge contract. A compromise of the `BRIDGE` contract would allow an attacker to arbitrarily mint or burn tokens, leading to severe economic consequences for the token and its holders. This represents a critical external dependency and a single point of failure. (7.3 Access Control, 7.4 Economic, 7.6 External)
FixEnsure the `BRIDGE` contract is robustly secured, thoroughly audited, and follows best practices for access control and operational security. Consider multi-signature control or time-locks for critical bridge operations if applicable to the bridge's design. The security posture of the `OptimismMintableERC20` token is directly proportional to the security of its associated `BRIDGE` contract.
StatusUnresolved
Medium

Irreversible `BRIDGE` and `REMOTE_TOKEN` Addresses

M-01The `BRIDGE` and `REMOTE_TOKEN` addresses are declared as `immutable` and are set only once during the contract's construction. While immutability can enhance security by preventing unauthorized changes, it also means that any error in setting these critical addresses during deployment cannot be corrected. An incorrectly configured `BRIDGE` address would render the token's mint/burn functionality unusable or controllable by an unintended entity, while an incorrect `REMOTE_TOKEN` address could lead to cross-chain mapping issues. (7.8 Operations)
IssueThe `BRIDGE` and `REMOTE_TOKEN` addresses are declared as `immutable` and are set only once during the contract's construction. While immutability can enhance security by preventing unauthorized changes, it also means that any error in setting these critical addresses during deployment cannot be corrected. An incorrectly configured `BRIDGE` address would render the token's mint/burn functionality unusable or controllable by an unintended entity, while an incorrect `REMOTE_TOKEN` address could lead to cross-chain mapping issues. (7.8 Operations)
FixImplement rigorous pre-deployment verification procedures, including checksum validation and multiple reviews, to ensure the correctness of the `_bridge` and `_remoteToken` parameters passed to the constructor. Consider deploying to a testnet with the exact parameters to confirm functionality before mainnet deployment.
StatusUnresolved
Info

Use of Legacy Functions

I-01The contract includes several functions (`l1Token`, `l2Bridge`, `remoteToken`, `bridge`) explicitly marked with `@custom:legacy` in their NatSpec comments. These functions provide redundant access to the `REMOTE_TOKEN` and `BRIDGE` immutable variables. While harmless in functionality, their presence adds to the contract's bytecode size and could potentially lead to confusion for integrators if not clearly understood that `REMOTE_TOKEN` and `BRIDGE` are the canonical variables. (7.2 Code Security, 7.8 Operations)
IssueThe contract includes several functions (`l1Token`, `l2Bridge`, `remoteToken`, `bridge`) explicitly marked with `@custom:legacy` in their NatSpec comments. These functions provide redundant access to the `REMOTE_TOKEN` and `BRIDGE` immutable variables. While harmless in functionality, their presence adds to the contract's bytecode size and could potentially lead to confusion for integrators if not clearly understood that `REMOTE_TOKEN` and `BRIDGE` are the canonical variables. (7.2 Code Security, 7.8 Operations)
FixFor future versions or new deployments, consider removing these legacy functions if backwards compatibility is no longer a strict requirement, to reduce contract complexity and bytecode size. Ensure documentation clearly distinguishes between canonical and legacy getters.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract demonstrates good technical architecture, extending OpenZeppelin's ERC20 for robust token functionality (7.1 Architecture). Code quality is high, with clear variable names, comprehensive NatSpec comments, and proper use of modifiers like `onlyBridge` for access control (7.2 Code Security). The core access control mechanism for minting and burning relies solely on the `BRIDGE` address (7.3 Access Control). A significant technical risk lies in the immutability of the `BRIDGE` address, which, if incorrectly set, cannot be changed, potentially rendering the token's cross-chain functionality inoperable (7.8 Operations).

GovernanceHigh2/10

The economic model of the OptimismMintableERC20 token is directly tied to the security of the `BRIDGE` contract (7.4 Economic). The `BRIDGE` address has absolute power to mint and burn tokens, meaning a compromise of this external contract would directly lead to an uncontrolled supply and severe economic impact on the token's value. There are no internal governance mechanisms within this contract (7.5 Governance), making the external bridge's governance and security paramount.

UpgradesHigh3/10

The OptimismMintableERC20 contract is not designed as an upgradeable proxy or an implementation contract for a proxy (7.7 Upgrades). Its core variables (`REMOTE_TOKEN`, `BRIDGE`) are immutable, and there are no upgrade-related functions. This design choice eliminates upgrade-specific risks such as storage collisions or improper initialization, but also means the contract cannot be modified post-deployment without a full redeployment.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

25.7% in wallets2.6% in contracts
Effective Concentration26.7%

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

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 Holder64.8%
Top-3 Unlocked99.8%

Key Addresses

Deployer
0x61a4…c656
Unlocked LP Held By
0x70fc…49620xda80…5c680xf02f…d07c0xaa0d…f4b90x88b3…b66b0xd860…84800x3e0e…e6400xfd49…d7f60x2f4e…ef8b0xd0f5…4817

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 (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20% (28.3% total → 26.7% effective; 25.7% in EOAs, 2.6% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 64.8% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 99.8% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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

Frequently Asked Questions

Is OMI Token a scam?

Based on automated analysis, OMI Token scores 76/100 (Critical Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is OMI Token safe to buy?

Our scanner flagged a risk score of 76/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has OMI Token been audited?

The contract is open-source and verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

Silencio (SLC)High RiskCoinbase Wrapped XRP (CBXRP)High RiskZestHigh RiskWrapped Coinbase Global Inc ST0x (WTCOIN)High RiskMorpho Token (MORPHO)High RiskTether USD (USDT)High Risk

Would You Like a More Detailed Audit of OMI Token?

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

Get Detailed Audit