Quantum Audit Logo
Launch App

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

Is NVIDIA Corp Safe?

NVDABBNB 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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance2/10Upgrades1/10Checks passed1 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The SecuritiesToken contract serves as an upgradeable ERC-20 token implementation, incorporating access control, compliance, pausing, and a scaled UI amount mechanism.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Complex proxy pattern
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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% (76.2% total → 68.5% effective; 63.3% in EOAs, 12.9% 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 High finding(s) from audit
  • 2 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 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
12.9%Contracts63.3%Wallets23.8%Everyone else
12.9%63.3%Wallets23.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
76.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking12.9%
  • Walletsanonymous holders, free to sell63.3%
  • Everyone elsethe rest of the supply23.8%
Effective concentrationwhat the score reads68.5%
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$2.71M across 10 pairs
Show 3 more pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$1.67MShare of depth61.5%
Top-1 Unlocked Holder26.0%
Top-3 Unlocked56.4%
Unlocked LP held by
0xf949…02980x4783…e70e0x57dc…53410x97d2…f1820x3723…9fbe0x2339…26200x4af1…ce510x409d…3c5c0x3d16…e5710x4dc9…7d16

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

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized Control and Single Point of Failure

The DEFAULT_ADMIN_ROLE possesses extensive control over critical contract parameters and operations. This role can grant/revoke any role (including itself and ISSUER_ROLE), change token metadata (name, symbol, identifier), enable/disable minting/burning, set compliance and pause manager contracts, and authorize UI multiplier updates. If this role's private key is compromised, the entire system is at risk of malicious manipulation or shutdown (7.3, 7.5).H-01

Issue

The DEFAULT_ADMIN_ROLE possesses extensive control over critical contract parameters and operations. This role can grant/revoke any role (including itself and ISSUER_ROLE), change token metadata (name, symbol, identifier), enable/disable minting/burning, set compliance and pause manager contracts, and authorize UI multiplier updates. If this role's private key is compromised, the entire system is at risk of malicious manipulation or shutdown (7.3, 7.5).

Fix

Implement a robust multi-signature wallet or a decentralized autonomous organization (DAO) for the DEFAULT_ADMIN_ROLE. This distributes control and requires multiple approvals for critical operations, significantly reducing the risk associated with a single point of failure.

Status

Unresolved

Medium

Critical External Dependencies

The contract relies on external compliance_ and pauseManager_ contracts, which are set by the DEFAULT_ADMIN_ROLE. The security and correct functioning of these external contracts are paramount. A malicious or buggy external contract could lead to a denial of service for token transfers, incorrect compliance checks, or other unintended behavior, impacting the entire token ecosystem (7.6).M-01

Issue

The contract relies on external compliance_ and pauseManager_ contracts, which are set by the DEFAULT_ADMIN_ROLE. The security and correct functioning of these external contracts are paramount. A malicious or buggy external contract could lead to a denial of service for token transfers, incorrect compliance checks, or other unintended behavior, impacting the entire token ecosystem (7.6).

Fix

Thoroughly audit the ComplianceClientUpgradeable and PauseManagerClientUpgradeable contracts to ensure their security and intended behavior. Consider implementing circuit breakers or emergency mechanisms to disconnect from a compromised external dependency if possible, or ensure these external contracts are immutable after deployment.

Status

Unresolved

Medium

Lack of Zero Address Check for Admin in Initialization

The initialize function grants the DEFAULT_ADMIN_ROLE to the admin_ address without checking if admin_ is address(0). If admin_ is accidentally set to address(0) during deployment, the DEFAULT_ADMIN_ROLE would be unassignable, potentially rendering the contract unmanageable and locking critical administrative functions (7.3, 7.8).M-02

Issue

The initialize function grants the DEFAULT_ADMIN_ROLE to the admin_ address without checking if admin_ is address(0). If admin_ is accidentally set to address(0) during deployment, the DEFAULT_ADMIN_ROLE would be unassignable, potentially rendering the contract unmanageable and locking critical administrative functions (7.3, 7.8).

Fix

Add a require(admin_ != address(0), "Zero address for admin") check in the initialize function before granting the DEFAULT_ADMIN_ROLE to prevent critical misconfiguration.

Status

Unresolved

Low

Broad Multiplier Range and Potential for Misinterpretation

The _validateMultiplier function allows a very wide range for the UI multiplier (1e-9x to 1e9x). While bounds are checked, such a broad range, controllable by DEFAULT_ADMIN_ROLE or ISSUER_ROLE, could significantly alter the perceived value of the token. This might confuse users or enable manipulative behavior if not managed transparently and communicated clearly (7.4).L-01

Issue

The _validateMultiplier function allows a very wide range for the UI multiplier (1e-9x to 1e9x). While bounds are checked, such a broad range, controllable by DEFAULT_ADMIN_ROLE or ISSUER_ROLE, could significantly alter the perceived value of the token. This might confuse users or enable manipulative behavior if not managed transparently and communicated clearly (7.4).

Fix

Document the intended use and implications of the multiplier range. Consider if such a broad range is truly necessary for the project's economic model or if tighter, more specific bounds would be appropriate. Ensure clear and proactive communication to users about any changes to the UI multiplier.

Status

Unresolved

Info

_checkAdminOrIssuer Visibility

The _checkAdminOrIssuer function is declared as private view. While it is correctly used by the onlyAdminOrIssuer modifier, making it internal view would allow other internal functions within the contract to directly call it if needed, without changing its security implications. This offers slightly more flexibility for future internal logic (7.2).I-01

Issue

The _checkAdminOrIssuer function is declared as private view. While it is correctly used by the onlyAdminOrIssuer modifier, making it internal view would allow other internal functions within the contract to directly call it if needed, without changing its security implications. This offers slightly more flexibility for future internal logic (7.2).

Fix

Consider changing the visibility of _checkAdminOrIssuer from private view to internal view for increased internal reusability, if deemed beneficial for future development.

Status

Unresolved

Analysis

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

The SecuritiesToken contract serves as an upgradeable ERC-20 token implementation, incorporating access control, compliance, pausing, and a scaled UI amount mechanism. It leverages OpenZeppelin's upgradeable contracts and follows standard patterns for proxy implementations. The contract exhibits a high degree of centralization, with the DEFAULT_ADMIN_ROLE possessing extensive control over critical parameters and operations. External dependencies for compliance and pausing introduce additional risk vectors.

Technical6/10Medium risk

The SecuritiesToken contract is built upon OpenZeppelin's upgradeable standards, ensuring robust ERC-20 functionality and upgrade safety (7.2, 7.7). It implements granular access control with DEFAULT_ADMIN_ROLE and ISSUER_ROLE for specific operations like minting and burning (7.3). However, the reliance on external ComplianceClientUpgradeable and PauseManagerClientUpgradeable contracts introduces critical external dependencies, whose security and availability are paramount (7.6). Additionally, a missing zero-address check for the initial admin in the initialize function could lead to unmanageable contract state (7.8).

Governance2/10High risk

The contract's governance model is highly centralized, with the DEFAULT_ADMIN_ROLE holding extensive power over token parameters, roles, and external integrations (7.5). This role can modify the token's name, symbol, identifier, enable/disable mint/burn, and set critical external contracts. The ISSUER_ROLE also has significant power to mint and burn tokens, and authorize UI multiplier changes, which directly impacts the token's economic representation (7.4). While this centralization allows for efficient management, it presents a single point of failure if the DEFAULT_ADMIN_ROLE is compromised.

Upgrades1/10High risk

The SecuritiesToken contract is designed as an upgradeable implementation for a BeaconProxy, correctly utilizing OpenZeppelin's initializer pattern and __gap storage to prevent storage collisions during upgrades (7.7). The _disableInitializers() call in the constructor and onlyInitializing modifiers ensure proper initialization flow. The use of a BeaconProxy allows for efficient upgrades across multiple instances of the token. However, the upgrade process itself, managed by the DEFAULT_ADMIN_ROLE, remains a critical centralized control point.

Final RecommendationWhat to do about this score

Prioritize decentralizing or securing the DEFAULT_ADMIN_ROLE through a robust multi-signature wallet or a DAO to mitigate the single point of failure risk.

Conduct thorough security audits of all external dependency contracts (compliance and pause managers) to ensure their integrity and prevent potential denial-of-service scenarios. Implement comprehensive checks, including a zero-address validation for the initial admin, to prevent critical misconfigurations during deployment.

Contract & Record

1 audit on record
TypeBeaconProxy
NetworkBNB Chain
Token age13d
Contract0x02fc…7436
Deployer0x64fd…8d53
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Badge for your website
NVIDIA Corp 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, 202681High
  2. Aug 11, 202688Critical

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

Related Audits

6 more on the recordAll audits
Giggle TomTOM · BNB Chain81HighUnited StablesU · BNB Chain82HighCATBNB Chain82HighVortexPadVPAD · BNB Chain82HighAIOZ NetworkAIOZ · BNB Chain82HighNEAR ProtocolNEAR · BNB Chain82High

Would You Like a More Detailed Audit of NVIDIA Corp?

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