Quantum Audit Logo
Launch App

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

Is Ice Open Network Safe?

IONBNB Chain
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance5/10Upgrades8/10Checks passed4 of 5Findings1 High · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

The Bridge contract facilitates cross-chain asset transfers using a multi-signature oracle system.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 50%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-6)
  • Top-10 concentration > 50% (63.0% total → 52.6% effective; 45.7% in EOAs, 17.3% in contracts — heavy)
  • 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 44 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
17.3%Contracts45.7%Wallets37.0%Everyone else
17.3%Contracts45.7%Wallets37.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
63.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking17.3%
  • Walletsanonymous holders, free to sell45.7%
  • Everyone elsethe rest of the supply37.0%
Effective concentrationwhat the score reads52.6%
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$237.7K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$237.7KShare of depth100.0%
LP Locked100.0% · UNCX Locker
Top-1 Unlocked Holder0.0%
Unlocked LP held by
0xa6bd…f8e60xbc99…12210xf2e3…0e5c0x8c98…d650

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

Security Findings

1 High1 Medium1 Low2 Info
High

High Centralization Risk via Oracle Set

The security and integrity of the entire bridge system are fundamentally dependent on the honesty and operational security of the oraclesSet. A 2/3 majority of these oracles can collectively approve any minting operation, change the oracle set itself, or toggle the burn status. If a majority of oracles are compromised or collude, they gain complete control over the wrapped token supply and bridge operations, leading to potential arbitrary minting and asset loss. This is a core design decision but represents a significant trust assumption (7.4 Economic, 7.5 Governance, 7.6 External).H-01

Issue

The security and integrity of the entire bridge system are fundamentally dependent on the honesty and operational security of the oraclesSet. A 2/3 majority of these oracles can collectively approve any minting operation, change the oracle set itself, or toggle the burn status. If a majority of oracles are compromised or collude, they gain complete control over the wrapped token supply and bridge operations, leading to potential arbitrary minting and asset loss. This is a core design decision but represents a significant trust assumption (7.4 Economic, 7.5 Governance, 7.6 External).

Fix

While this is a design choice, ensure the oracle set is composed of diverse, reputable, and geographically distributed entities. Implement robust operational security procedures for each oracle. Consider exploring mechanisms for further decentralization or introducing additional layers of security (e.g., time locks for critical changes, community oversight) in future iterations if feasible.

Status

Unresolved

Medium

Potential Denial-of-Service (DoS) via Large Oracle Set

The updateOracleSet function contains two loops that iterate over the oraclesSet array, and the generalVote function iterates over the signatures array. If the number of oracles (and consequently, the number of required signatures) grows excessively large, these loops could consume more gas than the block gas limit, rendering critical administrative functions like voteForNewOracleSet and other voting mechanisms unusable. This would effectively prevent the oracle set from being updated or any new votes from being processed, leading to a denial of service for the bridge's governance (7.2 Code Security, 7.8 Operations).M-01

Issue

The updateOracleSet function contains two loops that iterate over the oraclesSet array, and the generalVote function iterates over the signatures array. If the number of oracles (and consequently, the number of required signatures) grows excessively large, these loops could consume more gas than the block gas limit, rendering critical administrative functions like voteForNewOracleSet and other voting mechanisms unusable. This would effectively prevent the oracle set from being updated or any new votes from being processed, leading to a denial of service for the bridge's governance (7.2 Code Security, 7.8 Operations).

Fix

Implement a maximum limit for the size of the oraclesSet to ensure that loop iterations remain within reasonable gas limits. Carefully calculate the maximum feasible oracle count based on current and projected gas costs. Consider alternative data structures or batching mechanisms for very large sets if a high number of oracles is a strict requirement.

Status

Unresolved

Low

Unpinned Solidity Pragma

The contract uses a floating Solidity pragma ^0.7.0. This allows it to be compiled with any compiler version from 0.7.0 up to, but not including, 0.8.0. While generally safe, using a floating pragma can lead to unexpected behavior if a new compiler version introduces subtle changes or bugs that affect the contract's logic. It's best practice to pin the pragma to a specific, tested compiler version (e.g., pragma solidity 0.7.6;) (7.2 Code Security).L-01

Issue

The contract uses a floating Solidity pragma ^0.7.0. This allows it to be compiled with any compiler version from 0.7.0 up to, but not including, 0.8.0. While generally safe, using a floating pragma can lead to unexpected behavior if a new compiler version introduces subtle changes or bugs that affect the contract's logic. It's best practice to pin the pragma to a specific, tested compiler version (e.g., pragma solidity 0.7.6;) (7.2 Code Security).

Fix

Pin the Solidity compiler version to a specific, known-good version (e.g., pragma solidity 0.7.6;) to ensure consistent compilation and deployment behavior across different environments and over time.

Status

Unresolved

Info

Use of pragma experimental ABIEncoderV2

The contract uses pragma experimental ABIEncoderV2;. While ABIEncoderV2 has been standard since Solidity 0.8.0, its explicit experimental declaration in 0.7.x versions was common. This is generally stable but is a historical note regarding compiler features (7.2 Code Security).I-01

Issue

The contract uses pragma experimental ABIEncoderV2;. While ABIEncoderV2 has been standard since Solidity 0.8.0, its explicit experimental declaration in 0.7.x versions was common. This is generally stable but is a historical note regarding compiler features (7.2 Code Security).

Fix

No direct action is required as this is a historical pragma. For future contracts, using Solidity 0.8.0 or higher would make this pragma unnecessary.

Status

Unresolved

Info

Oracle Set Size Comment Not Enforced

The comment in generalVote states: `// NOTE: In practice, the number of oracles should be chosen to be divisible by 3.` This is a good operational guideline for ensuring clean 2/3 majority calculations, but it is not enforced by the contract's code. The current implementation correctly handles non-divisible numbers using integer division (floor) (7.2 Code Security, 7.8 Operations).I-02

Issue

The comment in generalVote states: `// NOTE: In practice, the number of oracles should be chosen to be divisible by 3.` This is a good operational guideline for ensuring clean 2/3 majority calculations, but it is not enforced by the contract's code. The current implementation correctly handles non-divisible numbers using integer division (floor) (7.2 Code Security, 7.8 Operations).

Fix

Consider adding a require statement in updateOracleSet to enforce that newSet.length is divisible by 3, if this is a strict operational requirement. Otherwise, ensure all stakeholders understand that the 2/3 consensus uses floor division for non-divisible numbers.

Status

Unresolved

Analysis

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

The Bridge contract facilitates cross-chain asset transfers using a multi-signature oracle system. It allows for minting wrapped tokens, updating the oracle set, and controlling burn functionality, all governed by a 2/3 majority vote of the current oracle set. While the core voting mechanism is robust, the system's security heavily relies on the integrity of the oracle set. Potential denial-of-service vectors exist if the oracle set grows excessively large, impacting critical administrative functions. The contract is not upgradeable, which simplifies upgrade safety but requires careful initial deployment.

Technical8/10Low risk

The technical implementation demonstrates good practices such as requiring sorted signatures and preventing vote replays (7.2 Code Security). The contract correctly implements a 2/3 majority consensus for critical operations like minting and oracle set updates (7.3 Access Control). However, a significant technical risk is the potential for denial-of-service in updateOracleSet and generalVote if the oracle set becomes very large, due to unbounded loops (7.2 Code Security, 7.8 Operations). Additionally, the use of an unpinned pragma (^0.7.0) introduces minor uncertainty regarding compiler behavior (7.2 Code Security).

Governance5/10Medium risk

The economic and governance model is highly centralized around the oracle set (7.4 Economic, 7.5 Governance). While a 2/3 majority is required for all critical actions, including updating the oracle set itself, a compromise of 2/3 of the oracle addresses would grant full control over the bridge, allowing arbitrary minting or freezing of assets (7.4 Economic). The system's security is entirely dependent on the operational security and trustworthiness of these oracle entities (7.6 External). There are no explicit mechanisms for community governance or emergency shutdowns beyond the oracle set's control.

Upgrades8/10Low risk

The Bridge contract is not designed with an upgrade mechanism (7.7 Upgrades). This eliminates risks associated with proxy patterns, such as storage collisions or incorrect upgrade paths. However, it means that any discovered vulnerabilities or desired feature enhancements would necessitate a complete redeployment and migration of assets, which can be a complex and risky process.

Final RecommendationWhat to do about this score

It is strongly recommended to carefully manage the size and security of the oracle set, as it represents the single point of trust for the bridge's operations.

Implement a maximum limit for the number of oracles to mitigate the denial-of-service vulnerability in administrative functions. Consider pinning the Solidity compiler version to a specific patch release to ensure consistent compilation behavior. For long-term sustainability, evaluate the implications of non-upgradeability and plan for potential future migrations if the protocol evolves or critical issues arise.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age5mo
Contract0xe1ab…5ea8
Deployer0xcaa0…5c20
Badge for your website
Ice Open Network 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. Sep 4, 202647Medium
  2. Aug 11, 202657Medium

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

Frequently Asked Questions

What is the ION contract address?

The Ice Open Network (ION) contract on BNB Chain is 0xe1ab61f7b093435204df32f5b3a405de55445ea8. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Ice Open Network a scam?

Quantum Audit's risk score for Ice Open Network is 47/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: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is ION liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $237.7K.

Who holds ION?

As of Sep 4, 2026, the 10 largest holders own 63.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
CESSTokenCESS · BNB Chain47MediumBSquared TokenB2 · BNB Chain48MediumCSI888CSI · BNB Chain46MediumBrokBNB Chain48MediumRadiantRDNT · BNB Chain46MediumCRYSTAL STONESBNB Chain49Medium

Would You Like a More Detailed Audit of Ice Open Network?

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