Is Ice Open Network (ION) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low2 Info

High

High Centralization Risk via Oracle Set

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

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

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

StatusUnresolved

Medium

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

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

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

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

StatusUnresolved

Low

Unpinned Solidity Pragma

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

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

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

StatusUnresolved

Info

Use of `pragma experimental ABIEncoderV2`

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

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

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

StatusUnresolved

Info

Oracle Set Size Comment Not Enforced

I-02The 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).

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceMedium5/10

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.

UpgradesLow8/10

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.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

63.0% in top 10

45.7% in wallets17.3% in contracts

Effective Concentration52.6%

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

$237.7K

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

LP Locked100.0% · UNCX Locker

Top-1 Unlocked Holder0.0%

Key Addresses

5 addresses

Deployer

0xcaa0…5c20

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.

What Raised This Score

5 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

Final Recommendation

AI Copilot

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

Read the verdictHide

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

TypeToken

Audit History

1 audit on record

Aug 1157Sep 447

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

Is Ice Open Network Safe?

Security Findings

High Centralization Risk via Oracle Set

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

Unpinned Solidity Pragma

Use of `pragma experimental ABIEncoderV2`

Oracle Set Size Comment Not Enforced

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

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