Quantum Audit Logo

Is Apple (Ondo Tokenized) Safe?

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

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

Apple (Ondo Tokenized) AAPLON
0x14c3…2d4c
Ethereum
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 9d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The GMToken contract implements an upgradeable ERC-20 token with extensive access control for minting, burning, pausing, and compliance. It leverages OpenZeppelin's upgradeable contracts and a Beacon Proxy pattern. While the architecture provides granular control, the high degree of centralization, particularly the power of the DEFAULT_ADMIN_ROLE and the unrestricted BURNER_ROLE, introduces significant security and economic risks. Proper management of these roles is critical to the security of the token.

1 Critical2 High1 Medium1 Low1 Informational
Volume 24h
$38.1K
Liquidity
$34.4K
Price
$333.7200
Token Age
11mo
Top 10 Holders
93.8%

Security Findings

1 Crit2 High1 Med1 Low1 Info
Critical

Centralized Control and High Privileges

C-01The `DEFAULT_ADMIN_ROLE` holds extensive power, including the ability to grant/revoke all other roles (MINTER, BURNER, CONFIGURER). This centralizes control over token supply (mint/burn), token transfer restrictions (pause/compliance), and core token metadata. A compromise of this role would lead to catastrophic loss of funds or manipulation of the token ecosystem (7.3 Access Control, 7.4 Economic, 7.5 Governance).
IssueThe `DEFAULT_ADMIN_ROLE` holds extensive power, including the ability to grant/revoke all other roles (MINTER, BURNER, CONFIGURER). This centralizes control over token supply (mint/burn), token transfer restrictions (pause/compliance), and core token metadata. A compromise of this role would lead to catastrophic loss of funds or manipulation of the token ecosystem (7.3 Access Control, 7.4 Economic, 7.5 Governance).
FixTransfer the `DEFAULT_ADMIN_ROLE` to a robust multi-signature wallet or a decentralized autonomous organization (DAO) to distribute control and reduce the risk of a single point of failure. Implement strict operational procedures for managing this role.
StatusUnresolved
High

Unrestricted Burner Role

H-01The `BURNER_ROLE` allows an authorized address to burn tokens from *any* holder's balance (`_burn(from, amount)`). This means a malicious or compromised burner could arbitrarily destroy tokens held by users, leading to direct loss of user funds without their consent or prior approval (7.3 Access Control, 7.4 Economic).
IssueThe `BURNER_ROLE` allows an authorized address to burn tokens from *any* holder's balance (`_burn(from, amount)`). This means a malicious or compromised burner could arbitrarily destroy tokens held by users, leading to direct loss of user funds without their consent or prior approval (7.3 Access Control, 7.4 Economic).
FixRestrict the `burn` function to only allow burning from `msg.sender` (the burner's own balance) or implement a `burnFrom` function that requires prior `approve` calls, similar to `transferFrom`. If burning from arbitrary addresses is a requirement, ensure robust off-chain controls and oversight for the `BURNER_ROLE`.
StatusUnresolved
High

Configurer Role Can Change Critical Dependencies

H-02The `CONFIGURER_ROLE` can update the addresses of the `OndoComplianceGMClientUpgradeable` and `TokenPauseManagerClientUpgradeable` contracts via `setCompliance` and `setTokenPauseManager`. If a malicious or compromised address is set for these dependencies, it could lead to arbitrary pausing of transfers or manipulation of compliance checks, effectively halting or controlling token movement (7.3 Access Control, 7.6 External).
IssueThe `CONFIGURER_ROLE` can update the addresses of the `OndoComplianceGMClientUpgradeable` and `TokenPauseManagerClientUpgradeable` contracts via `setCompliance` and `setTokenPauseManager`. If a malicious or compromised address is set for these dependencies, it could lead to arbitrary pausing of transfers or manipulation of compliance checks, effectively halting or controlling token movement (7.3 Access Control, 7.6 External).
FixImplement a timelock for changes to critical external dependencies to allow for community review or emergency intervention. Ensure that the `CONFIGURER_ROLE` is managed with the highest security standards, potentially by a multi-signature wallet.
StatusUnresolved
Medium

Initialization Order in `__gmToken_init`

M-01The `__gmToken_init_unchained` function, which sets the `DEFAULT_ADMIN_ROLE` and overrides name/symbol, is called after the initialization of `OndoComplianceGMClientInitializable_init` and `TokenPauseManagerClientInitializable_init_unchained`. While not a direct vulnerability in this context, it is generally safer practice to initialize all base contracts first before the derived contract's specific logic to ensure all dependencies are fully set up before custom logic executes (7.1 Architecture, 7.7 Upgrades).
IssueThe `__gmToken_init_unchained` function, which sets the `DEFAULT_ADMIN_ROLE` and overrides name/symbol, is called after the initialization of `OndoComplianceGMClientInitializable_init` and `TokenPauseManagerClientInitializable_init_unchained`. While not a direct vulnerability in this context, it is generally safer practice to initialize all base contracts first before the derived contract's specific logic to ensure all dependencies are fully set up before custom logic executes (7.1 Architecture, 7.7 Upgrades).
FixConsider reordering the initialization calls within `__gmToken_init` to ensure `__gmToken_init_unchained` is called before the external client initializers, or at least ensure that no critical state relies on `DEFAULT_ADMIN_ROLE` or name/symbol being set before the external clients are initialized.
StatusUnresolved
Low

Lack of Specific Renouncement Mechanism for DEFAULT_ADMIN_ROLE

L-01While `renounceRole` exists for general roles, there is no specific mechanism or recommendation for the `DEFAULT_ADMIN_ROLE` to renounce its powers to a multi-signature wallet or governance contract after initial setup. This keeps a single point of failure for the most powerful role if not explicitly managed off-chain (7.3 Access Control, 7.8 Operations).
IssueWhile `renounceRole` exists for general roles, there is no specific mechanism or recommendation for the `DEFAULT_ADMIN_ROLE` to renounce its powers to a multi-signature wallet or governance contract after initial setup. This keeps a single point of failure for the most powerful role if not explicitly managed off-chain (7.3 Access Control, 7.8 Operations).
FixProvide clear documentation and a recommended procedure for the `DEFAULT_ADMIN_ROLE` to be transferred to a more secure, multi-signature controlled address or a governance contract post-deployment, if this is the intended long-term state.
StatusUnresolved
Info

Missing Custom Events for Role Management

I-01While `AccessControlUpgradeable` emits `RoleGranted` and `RoleRevoked` events, the `GMToken` contract itself does not emit custom events when specific roles like `MINTER_ROLE`, `BURNER_ROLE`, or `CONFIGURER_ROLE` are granted or revoked. This can make off-chain monitoring and auditing of critical permission changes more challenging for specific roles (7.2 Code Security, 7.8 Operations).
IssueWhile `AccessControlUpgradeable` emits `RoleGranted` and `RoleRevoked` events, the `GMToken` contract itself does not emit custom events when specific roles like `MINTER_ROLE`, `BURNER_ROLE`, or `CONFIGURER_ROLE` are granted or revoked. This can make off-chain monitoring and auditing of critical permission changes more challenging for specific roles (7.2 Code Security, 7.8 Operations).
FixConsider adding custom events in `_grantRole` and `_revokeRole` overrides (or in `grantRole`/`revokeRole` if not overriding internal functions) to specifically log when `MINTER_ROLE`, `BURNER_ROLE`, or `CONFIGURER_ROLE` are assigned or removed. This enhances transparency and ease of monitoring.
StatusUnresolved

Category Ratings

TechnicalHigh3/10

The contract utilizes well-audited OpenZeppelin upgradeable components, ensuring a solid foundation for ERC-20 functionality and access control (7.2 Code Security). The `_beforeTokenTransfer` hook correctly integrates compliance and pause checks (7.1 Architecture). However, the `BURNER_ROLE` has the ability to burn tokens from any address without approval, posing a direct threat to user funds (7.3 Access Control). Additionally, the `CONFIGURER_ROLE` can change critical external dependencies, which could lead to manipulation of token behavior (7.6 External).

GovernanceHigh1/10

The token's economic model is highly centralized, with the `DEFAULT_ADMIN_ROLE` possessing ultimate control over all critical functions, including minting, burning, pausing, and compliance settings (7.4 Economic). This role can grant or revoke all other powerful roles (MINTER, BURNER, CONFIGURER), creating a single point of failure (7.5 Governance). The `MINTER_ROLE` allows for arbitrary token creation, and the `BURNER_ROLE` can destroy tokens from any account, representing significant economic risks if these roles are compromised (7.4 Economic).

UpgradesHigh1/10

The contract correctly implements the upgradeable pattern using `_disableInitializers()` in the constructor and `initializer` modifiers for setup, ensuring proper initialization for a Beacon Proxy (7.7 Upgrades). It inherits from OpenZeppelin's upgradeable contracts, which are designed to prevent storage collisions. A minor concern is the order of initialization calls within `__gmToken_init`, where the contract's specific unchained initializer is called after external client initializers (7.7 Upgrades).

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
Upgrades (30d)0 · stable

Holder Composition

93.8% in top 10
7.6% in wallets86.1% in contracts
Effective Concentration42.1%

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

$62.9K across 6 pairs
Uniswap v3USDCanalysed$34.4K54.8%0x00a3…6B38USDC$15.2K24.2%0x00a3…6B38USDC$10.0K16.0%Uniswap v3USDC$2.4K3.9%Uniswap v4USDT$7481.2%

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 Holder98.4%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0x61ea…9536
Unlocked LP Held By
0x2e14…294d0x78d6…0e13

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

What Raised This Score

12 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 > 30% (93.8% total → 42.1% effective; 7.6% in EOAs, 86.1% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.4% (independent LP — depth risk, pool = 55% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 55% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 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
Humanity (H)Critical RiskNEARCritical RiskVision (VSN)Critical RiskSpaceX xStock (SPCXX)Critical RisktapCritical RiskBananaCritical Risk

Would You Like a More Detailed Audit of Apple (Ondo Tokenized)?

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

Get Detailed Audit