Quantum Audit Logo

Is NVIDIA (Ondo Tokenized) Safe?

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

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

NVIDIA (Ondo Tokenized) NVDAON
0x2d1f…bdee
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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The GMToken contract, deployed as an upgradeable BeaconProxy, implements an ERC-20 token with extensive access control for minting, burning, and configuration. While leveraging well-audited OpenZeppelin libraries for upgradeability and access control, the contract exhibits a high degree of centralization. Critical findings include highly privileged roles that can unilaterally control token supply, burn user funds, and manipulate core token functionality by changing external dependencies. Upgrade safety also presents a high risk due to a missing `__gap` variable in the primary contract.

1 Critical2 High1 Medium1 Informational
Volume 24h
$695.8K
Liquidity
$154.4K
Price
$225.2600
Token Age
18d
Top 10 Holders
75.3%

Security Findings

1 Crit2 High1 Med1 Info
Critical

Centralized Control Over Critical Token Functions

C-01The `GMToken` contract grants highly privileged roles (`MINTER_ROLE`, `BURNER_ROLE`, `CONFIGURER_ROLE`) to potentially single entities, controlled by the `DEFAULT_ADMIN_ROLE`. The `MINTER_ROLE` can mint an arbitrary amount of tokens, leading to uncontrolled inflation. The `BURNER_ROLE` can burn tokens from *any* address, allowing for arbitrary fund confiscation. The `CONFIGURER_ROLE` can change the addresses of the `compliance` and `tokenPauseManager` contracts to arbitrary, potentially malicious, contracts, enabling a full denial of service or unauthorized transfer restrictions. This centralization poses a critical risk of economic manipulation, fund loss, or protocol shutdown if these rol…
IssueThe `GMToken` contract grants highly privileged roles (`MINTER_ROLE`, `BURNER_ROLE`, `CONFIGURER_ROLE`) to potentially single entities, controlled by the `DEFAULT_ADMIN_ROLE`. The `MINTER_ROLE` can mint an arbitrary amount of tokens, leading to uncontrolled inflation. The `BURNER_ROLE` can burn tokens from *any* address, allowing for arbitrary fund confiscation. The `CONFIGURER_ROLE` can change the addresses of the `compliance` and `tokenPauseManager` contracts to arbitrary, potentially malicious, contracts, enabling a full denial of service or unauthorized transfer restrictions. This centralization poses a critical risk of economic manipulation, fund loss, or protocol shutdown if these rol…
FixImplement robust multi-signature (e.g., Gnosis Safe) control for all critical roles (`DEFAULT_ADMIN_ROLE`, `MINTER_ROLE`, `BURNER_ROLE`, `CONFIGURER_ROLE`). Consider introducing time-locks for sensitive operations like changing external contract addresses or granting/revoking critical roles. Clearly document the responsibilities and operational procedures for each role.
StatusUnresolved
High

Missing `__gap` Variable in `GMToken` for Upgrade Safety

H-01The `GMToken` contract, despite inheriting from OpenZeppelin's upgradeable contracts which include `__gap` arrays, does not declare its own `__gap` array at the end of its storage variables. While inherited `__gap`s protect the base contracts, any new state variables introduced directly into `GMToken` in a future upgrade could potentially overwrite storage slots of existing variables in inherited base contracts if not carefully placed, leading to storage collisions and unexpected behavior or loss of data.
IssueThe `GMToken` contract, despite inheriting from OpenZeppelin's upgradeable contracts which include `__gap` arrays, does not declare its own `__gap` array at the end of its storage variables. While inherited `__gap`s protect the base contracts, any new state variables introduced directly into `GMToken` in a future upgrade could potentially overwrite storage slots of existing variables in inherited base contracts if not carefully placed, leading to storage collisions and unexpected behavior or loss of data.
FixAdd a `uint256[50] private __gap;` (or appropriate size) at the very end of the `GMToken` contract's state variables to ensure forward compatibility and prevent storage collisions during future upgrades. This is a standard practice for upgradeable contracts.
StatusUnresolved
High

Critical Reliance on External Compliance and Pause Managers

H-02The `GMToken`'s core transfer functionality is critically dependent on the `OndoComplianceGMClientUpgradeable` and `TokenPauseManagerClientUpgradeable` contracts, which are external dependencies. The `_beforeTokenTransfer` hook calls `_checkTokenIsPaused()` and `_checkIsCompliant()` from these external contracts. A bug, compromise, or malicious configuration of these external contracts (e.g., by the `CONFIGURER_ROLE`) could lead to a complete denial of service for token transfers, arbitrary transfer restrictions, or other unintended behavior, severely impacting the token's utility and security.
IssueThe `GMToken`'s core transfer functionality is critically dependent on the `OndoComplianceGMClientUpgradeable` and `TokenPauseManagerClientUpgradeable` contracts, which are external dependencies. The `_beforeTokenTransfer` hook calls `_checkTokenIsPaused()` and `_checkIsCompliant()` from these external contracts. A bug, compromise, or malicious configuration of these external contracts (e.g., by the `CONFIGURER_ROLE`) could lead to a complete denial of service for token transfers, arbitrary transfer restrictions, or other unintended behavior, severely impacting the token's utility and security.
FixImplement robust monitoring and auditing procedures for the external compliance and token pause manager contracts. Ensure these external contracts are themselves highly secure, immutable where possible, or controlled by strong multi-signature governance. Consider adding circuit breakers or emergency mechanisms to disable reliance on these external contracts in case of compromise or malfunction, if feasible.
StatusUnresolved
Medium

High Centralization of `DEFAULT_ADMIN_ROLE`

M-01The `DEFAULT_ADMIN_ROLE` is granted to `msg.sender` during initialization and has the power to grant and revoke all other roles, including `MINTER_ROLE`, `BURNER_ROLE`, and `CONFIGURER_ROLE`. This centralizes significant administrative power in a single entity or a small group, creating a single point of failure. A compromise of the `DEFAULT_ADMIN_ROLE`'s private key could lead to a complete takeover of the token's functionality.
IssueThe `DEFAULT_ADMIN_ROLE` is granted to `msg.sender` during initialization and has the power to grant and revoke all other roles, including `MINTER_ROLE`, `BURNER_ROLE`, and `CONFIGURER_ROLE`. This centralizes significant administrative power in a single entity or a small group, creating a single point of failure. A compromise of the `DEFAULT_ADMIN_ROLE`'s private key could lead to a complete takeover of the token's functionality.
FixAssign the `DEFAULT_ADMIN_ROLE` to a robust multi-signature wallet (e.g., Gnosis Safe) from the outset. Consider implementing a timelock for sensitive administrative actions, such as changing role administrators or granting/revoking critical roles, to provide a window for intervention in case of a malicious or erroneous action.
StatusUnresolved
Info

Ambiguous `msg.sender` Compliance Check in `_beforeTokenTransfer`

I-01The `_beforeTokenTransfer` function includes a compliance check for `msg.sender` only if `from != msg.sender && to != msg.sender`. This implies `msg.sender` is an intermediary (e.g., an approved operator or a proxy contract). While not a direct vulnerability, this specific condition might lead to confusion or unexpected behavior in complex transfer scenarios, especially if the intent for `msg.sender`'s compliance in such cases is not explicitly defined or universally understood.
IssueThe `_beforeTokenTransfer` function includes a compliance check for `msg.sender` only if `from != msg.sender && to != msg.sender`. This implies `msg.sender` is an intermediary (e.g., an approved operator or a proxy contract). While not a direct vulnerability, this specific condition might lead to confusion or unexpected behavior in complex transfer scenarios, especially if the intent for `msg.sender`'s compliance in such cases is not explicitly defined or universally understood.
FixClarify the intended behavior and implications of the `msg.sender` compliance check in the documentation. If the intent is to always check the actual `from` and `to` addresses, and `msg.sender`'s compliance is only relevant in specific proxy/operator patterns, ensure this logic is robust and well-tested across all expected use cases.
StatusUnresolved

Category Ratings

TechnicalHigh3/10

The GMToken contract utilizes OpenZeppelin's upgradeable ERC-20 and AccessControl libraries, which generally contribute to robust code security (7.2 Code Security). The `_beforeTokenTransfer` hook correctly integrates compliance and pausing logic. However, a significant technical risk is the absence of a `__gap` array in the `GMToken` contract itself, which could lead to storage collisions during future upgrades (7.7 Upgrades). Additionally, the contract's critical reliance on external `OndoComplianceGMClientUpgradeable` and `TokenPauseManagerClientUpgradeable` contracts introduces external dependency risks (7.6 External, 7.8 Operations).

GovernanceHigh1/10

The contract exhibits a highly centralized governance and economic model (7.5 Governance, 7.4 Economic). The `DEFAULT_ADMIN_ROLE` has ultimate control over all other roles, including `MINTER_ROLE`, `BURNER_ROLE`, and `CONFIGURER_ROLE`. The `MINTER_ROLE` can inflate the token supply, while the `BURNER_ROLE` can arbitrarily burn tokens from any address, posing a critical risk of fund loss. The `CONFIGURER_ROLE` can also change the addresses of the compliance and token pause managers, allowing for unilateral control over transfer restrictions and token pausing (7.3 Access Control).

UpgradesHigh1/10

The contract is designed for upgradeability using the BeaconProxy pattern and OpenZeppelin's `Initializable` base contracts, which is a standard and generally secure approach (7.1 Architecture). The `_disableInitializers()` in the constructor and the `onlyInitializing` modifiers are correctly implemented. However, the `GMToken` contract itself lacks a `__gap` array at the end of its storage variables. This omission creates a high risk of storage collisions if new state variables are introduced in a future upgrade, potentially overwriting existing data from inherited base contracts (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

75.3% in top 10
48.1% in wallets27.3% in contracts
Effective Concentration59.0%

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

$194.0K across 5 pairs
Uniswap v4USDCanalysed$154.4K79.6%Uniswap v3USDC$23.7K12.2%Uniswap v4ZIK$8.3K4.3%Uniswap v2ZIK$7.5K3.9%Uniswap v4USDC$870.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 Holder46.0%
Top-3 Unlocked78.4%

Key Addresses

11 addresses
Deployer
0x61ea…9536
Unlocked LP Held By
0xe641…ff920x1b26…9eb70x2e14…294d0x49b3…3e5f0x9e45…0e3e0xec39…11fb0xb5a3…b5b10x3b3f…ba0e0x78d6…0e130x0793…bfea

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 > 50% (75.3% total → 59.0% effective; 48.1% in EOAs, 27.3% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 30 days (still settling)
  • 1 Critical finding(s) from audit
  • 2 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

Related Audits

6 more on the record
SpaceX xStock (SPCXX)Critical RiskBananaCritical RiskPonsCritical RiskGoldfish (GGBR)Critical RiskAUSDCritical RiskHumanity (H)Critical Risk

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

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

Get Detailed Audit