Quantum Audit Logo

Is iShares China Large-Cap ETF (Ondo Tokenized) Safe?

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

Is this your token? Publish your own audit on this page →

iShares China Large-Cap ETF (Ondo Tokenized) FXION
0x9b8e…eea1
BNB Chain
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.Own this token? Put it under verification →
Last checked today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The GMToken contract serves as an upgradeable ERC-20 token implementation, utilizing OpenZeppelin's Beacon Proxy pattern and AccessControl for role-based permissions. It integrates external compliance and token pausing functionalities. While the core code is well-structured and leverages battle-tested libraries, significant centralization risks exist due to powerful administrative roles that control token supply and critical external dependencies. The compliance check logic also presents a potential for unintended transaction blocking.

2 High1 Medium1 Low1 Informational
Volume 24h
$14.11M
Liquidity
$1.54M
Price
$34.0830
Token Age
17d
Top 10 Holders
55.3%

Security Findings

2 High1 Med1 Low1 Info
High

Centralized Control Over Critical External Dependencies

H-01The `CONFIGURER_ROLE` has the ability to change the addresses of the `_compliance` and `_tokenPauseManager` contracts via `setCompliance` and `setTokenPauseManager` functions. This allows a single entity holding this role to redirect critical compliance and token pausing functionalities to potentially malicious or non-functional contracts, effectively disabling or compromising these core security features.
IssueThe `CONFIGURER_ROLE` has the ability to change the addresses of the `_compliance` and `_tokenPauseManager` contracts via `setCompliance` and `setTokenPauseManager` functions. This allows a single entity holding this role to redirect critical compliance and token pausing functionalities to potentially malicious or non-functional contracts, effectively disabling or compromising these core security features.
FixImplement a robust governance mechanism, such as a multi-signature wallet or a time-locked contract, for the `CONFIGURER_ROLE`. Any changes to critical external dependencies should require multiple approvals or a delay period to provide transparency and allow for community oversight.
StatusUnresolved
High

Centralized Control Over Token Supply

H-02The `MINTER_ROLE` can mint an arbitrary amount of tokens to any address, and the `BURNER_ROLE` can burn tokens from any address. While common for managed tokens, this grants significant power to the entities holding these roles, posing a high economic risk if these roles are compromised or misused. Malicious minting could devalue the token, and arbitrary burning could seize user funds.
IssueThe `MINTER_ROLE` can mint an arbitrary amount of tokens to any address, and the `BURNER_ROLE` can burn tokens from any address. While common for managed tokens, this grants significant power to the entities holding these roles, posing a high economic risk if these roles are compromised or misused. Malicious minting could devalue the token, and arbitrary burning could seize user funds.
FixEnsure that the `MINTER_ROLE` and `BURNER_ROLE` are controlled by highly secure, multi-signature wallets or a decentralized governance process. Implement strict operational procedures and monitoring for any minting or burning activities. Consider adding limits or additional checks for large mint/burn operations if feasible within the protocol's design.
StatusUnresolved
Medium

Potential Transfer Blocking via `msg.sender` Compliance Check

M-01The `_beforeTokenTransfer` hook includes a conditional compliance check for `msg.sender` (`if (from != msg.sender && to != msg.sender) { _checkIsCompliant(msg.sender); }`). This means that for `transferFrom` operations or transfers initiated by an approved contract, the *caller* of the transaction must also be compliant. This could inadvertently block legitimate transfers if the interacting protocol (e.g., a DEX router, a lending pool) is not whitelisted by the `OndoComplianceGMClientUpgradeable` contract, even if the `from` and `to` addresses are compliant.
IssueThe `_beforeTokenTransfer` hook includes a conditional compliance check for `msg.sender` (`if (from != msg.sender && to != msg.sender) { _checkIsCompliant(msg.sender); }`). This means that for `transferFrom` operations or transfers initiated by an approved contract, the *caller* of the transaction must also be compliant. This could inadvertently block legitimate transfers if the interacting protocol (e.g., a DEX router, a lending pool) is not whitelisted by the `OndoComplianceGMClientUpgradeable` contract, even if the `from` and `to` addresses are compliant.
FixClarify the intended behavior and implications of this `msg.sender` compliance check. If the intent is to allow protocol interactions, ensure that common DeFi protocols or their proxy addresses are whitelisted in the compliance contract. Alternatively, reconsider the necessity of this specific `msg.sender` check for `transferFrom` scenarios if it creates undue friction for legitimate integrations.
StatusUnresolved
Low

Critical Role Management for DEFAULT_ADMIN_ROLE

L-01The `DEFAULT_ADMIN_ROLE` is granted to `msg.sender` during the `__gmToken_init_unchained` initialization. This role has the highest level of privilege, including the ability to grant and revoke all other roles. While standard for initial deployment, improper management of this role post-deployment represents a single point of failure.
IssueThe `DEFAULT_ADMIN_ROLE` is granted to `msg.sender` during the `__gmToken_init_unchained` initialization. This role has the highest level of privilege, including the ability to grant and revoke all other roles. While standard for initial deployment, improper management of this role post-deployment represents a single point of failure.
FixImmediately after deployment and initialization, the `DEFAULT_ADMIN_ROLE` should be transferred from the deployer's address to a secure, multi-signature wallet or a robust governance contract. This minimizes the risk associated with a single private key controlling all administrative functions.
StatusUnresolved
Info

High Dependency on External Contracts

I-01The `GMToken` contract heavily relies on the `OndoComplianceGMClientUpgradeable` and `TokenPauseManagerClientUpgradeable` contracts for core functionalities like compliance checks and token pausing. The security, correctness, and availability of these external contracts are paramount to the overall integrity and intended behavior of the `GMToken` itself.
IssueThe `GMToken` contract heavily relies on the `OndoComplianceGMClientUpgradeable` and `TokenPauseManagerClientUpgradeable` contracts for core functionalities like compliance checks and token pausing. The security, correctness, and availability of these external contracts are paramount to the overall integrity and intended behavior of the `GMToken` itself.
FixEnsure that the external `OndoComplianceGMClientUpgradeable` and `TokenPauseManagerClientUpgradeable` contracts have undergone thorough security audits and are maintained by trusted entities. Implement robust monitoring for these external dependencies to detect any unexpected behavior or compromise.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The GMToken contract demonstrates good technical architecture (7.1) by inheriting from OpenZeppelin's upgradeable ERC-20 and AccessControl contracts, ensuring a robust foundation. Code security (7.2) is generally strong, with no apparent reentrancy or integer overflow vulnerabilities due to Solidity 0.8.16. However, the `_beforeTokenTransfer` hook includes a compliance check on `msg.sender` for certain scenarios, which could inadvertently block legitimate `transferFrom` operations by compliant users if the interacting protocol (e.g., a DEX router) is not also whitelisted. This specific logic warrants careful consideration regarding its implications for external integrations.

GovernanceHigh3/10

The contract's economic (7.4) and governance (7.5) models present high centralization risks. The `MINTER_ROLE` and `BURNER_ROLE` have complete control over token supply, allowing for arbitrary minting and burning, which can significantly impact token value. Furthermore, the `CONFIGURER_ROLE` can modify the addresses of the `OndoComplianceGMClientUpgradeable` and `TokenPauseManagerClientUpgradeable` contracts, enabling a single entity to redirect or disable critical compliance and pausing mechanisms. The `DEFAULT_ADMIN_ROLE` holds ultimate authority over all other roles, making its security paramount (7.3).

UpgradesHigh1/10

The contract is designed as an upgradeable implementation using OpenZeppelin's `Initializable` pattern and is deployed via a Beacon Proxy (7.7). This architecture allows for future logic upgrades while maintaining state. The use of `__gap` storage variables in inherited OpenZeppelin contracts correctly mitigates storage collision risks. The initialization logic correctly uses `_disableInitializers()` and `initializer` modifiers, ensuring proper setup and preventing re-initialization.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source

Holder Composition

55.3% in top 10
0.6% in wallets54.8% in contracts
Effective Concentration22.5%

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

$1.72M across 6 pairs
Pancakeswap v3USDTanalysed$1.54M89.7%UniswapUSDT$153.7K8.9%Pancakeswap v2WBNB$23.1K1.3%UniswapUSDT$4630.0%Pancakeswap v3WBNB$400.0%Pancakeswap v3USDC$390.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 Holder28.5%
Top-3 Unlocked61.2%

Key Addresses

11 addresses
Deployer
0x8ddd…6de2
Unlocked LP Held By
0xacd6…2a340x8f7d…a62a0x3440…380f0x1352…321b0xca68…a8880x3dd9…8c820x0818…cef80x8145…09920x326f…51c40x1853…c4ee

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)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 20% (55.3% total → 22.5% effective; 0.6% in EOAs, 54.8% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 30 days (still settling)
  • 2 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

Related Audits

6 more on the record
Infinity Ground AI (AIN)High RiskFinTech AI (FNA)High RiskSOCKHigh RiskTopazHigh RiskLitecoin Token (LTC)High RiskAnoma (XAN)Critical Risk

Would You Like a More Detailed Audit of iShares China Large-Cap ETF (Ondo Tokenized)?

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

Get Detailed Audit