Quantum Audit Logo
Launch App

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

Is Sandisk Corporation Safe?

SNDKBBNB 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
Critical RiskHow is this score calculated?
SummaryAI Copilot

The SecuritiesToken contract, an upgradeable ERC-20 token, implements a scaled UI amount standard (ERC8056) and integrates with compliance and pause management systems.

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 > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.9%
  • LP top3 unlocked holders = 99.8%
  • 1 High finding(s) from audit
  • 3 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 > 70% (98.6% total → 97.2% effective; 96.3% in EOAs, 2.3% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.9% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 99.8% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 High finding(s) from audit
  • 3 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 43 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
2.3%96.3%Wallets
96.3%Wallets
ContractsWalletsEveryone elseBubble area = share of supply
98.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking2.3%
  • Walletsanonymous holders, free to sell96.3%
  • Everyone elsethe rest of the supply1.4%
Effective concentrationwhat the score reads97.2%
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$337.1K across 2 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$335.0KShare of depth99.4%
Top-1 Unlocked Holder96.9%
Top-3 Unlocked99.8%
Unlocked LP held by
0x556b…d59e0x8f9e…575d0x2054…28e40xc351…30140x3cb6…ecb20x26f7…2b6f0x2e6c…f1fd0xa5a2…da5d0xd270…31440xde6a…c055

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

Security Findings

1 High3 Medium1 Low
High

High Centralization of Administrative Control

The DEFAULT_ADMIN_ROLE holds extensive power, including managing ISSUER_ROLE, enabling/disabling mint/burn, and setting critical external contracts like ComplianceClient and PauseManagerClient. This creates a single point of failure where a compromised or malicious admin key could lead to severe consequences, such as freezing transfers, arbitrary token issuance/destruction, or manipulating the token's economic parameters via the multiplier. (7.3 Access Control, 7.5 Governance)H-01

Issue

The DEFAULT_ADMIN_ROLE holds extensive power, including managing ISSUER_ROLE, enabling/disabling mint/burn, and setting critical external contracts like ComplianceClient and PauseManagerClient. This creates a single point of failure where a compromised or malicious admin key could lead to severe consequences, such as freezing transfers, arbitrary token issuance/destruction, or manipulating the token's economic parameters via the multiplier. (7.3 Access Control, 7.5 Governance)

Fix

Consider implementing a multi-signature wallet or a time-locked governance mechanism for the DEFAULT_ADMIN_ROLE to mitigate the risk of a single point of failure and enhance security.

Status

Unresolved

Medium

Critical Initialization Parameter Dependency

The initialize function, specifically the __securitiesToken_init internal function, takes crucial parameters such as admin_ and issuers_. If admin_ is set to address(0) or an incorrect address during deployment, the contract could become unmanageable or controlled by an unintended entity. Similarly, if issuers_ contains address(0) or incorrect addresses, it could lead to operational issues. (7.7 Upgrades, 7.8 Operations)M-01

Issue

The initialize function, specifically the __securitiesToken_init internal function, takes crucial parameters such as admin_ and issuers_. If admin_ is set to address(0) or an incorrect address during deployment, the contract could become unmanageable or controlled by an unintended entity. Similarly, if issuers_ contains address(0) or incorrect addresses, it could lead to operational issues. (7.7 Upgrades, 7.8 Operations)

Fix

Implement robust pre-deployment checks and a secure deployment process to ensure all initialization parameters, especially admin_, are correct and valid. Consider adding a mechanism to recover admin control if admin_ is accidentally set to address(0) (e.g., a time-locked recovery function, though this adds complexity).

Status

Unresolved

Medium

Reliance on External Compliance and Pause Managers

The SecuritiesToken contract relies on external ComplianceClient and PauseManagerClient contracts to enforce transfer restrictions and pausing functionality. The security and integrity of the token's core transfer mechanism (_update) are directly dependent on these external contracts. A compromise or misconfiguration of these external contracts could lead to the token being frozen, transfers being arbitrarily restricted, or other unintended behaviors. (7.6 External)M-02

Issue

The SecuritiesToken contract relies on external ComplianceClient and PauseManagerClient contracts to enforce transfer restrictions and pausing functionality. The security and integrity of the token's core transfer mechanism (_update) are directly dependent on these external contracts. A compromise or misconfiguration of these external contracts could lead to the token being frozen, transfers being arbitrarily restricted, or other unintended behaviors. (7.6 External)

Fix

Ensure that the ComplianceClient and PauseManagerClient contracts are thoroughly audited, securely managed, and follow best practices. Consider implementing circuit breakers or emergency mechanisms within the SecuritiesToken to temporarily bypass or disable these external dependencies in case of a critical issue, if feasible and aligned with the project's risk model.

Status

Unresolved

Medium

Wide Range for UI Multiplier Manipulation

The _validateMultiplier function allows the _uiMultiplier to be set within a very broad range (from 1e9 to 1e27, representing 1e-9x to 1e9x relative to the base 1e18). While _authorizeMultiplierUpdate is restricted to onlyAdminOrIssuer, such a wide range provides significant power to these roles to drastically alter the perceived value or display of the token. Misuse or malicious manipulation of this multiplier could lead to economic instability or user confusion. (7.4 Economic, 7.5 Governance)M-03

Issue

The _validateMultiplier function allows the _uiMultiplier to be set within a very broad range (from 1e9 to 1e27, representing 1e-9x to 1e9x relative to the base 1e18). While _authorizeMultiplierUpdate is restricted to onlyAdminOrIssuer, such a wide range provides significant power to these roles to drastically alter the perceived value or display of the token. Misuse or malicious manipulation of this multiplier could lead to economic instability or user confusion. (7.4 Economic, 7.5 Governance)

Fix

Review the intended use case and acceptable bounds for the UI multiplier. If the current range is wider than necessary, consider narrowing it to reduce the potential impact of malicious or erroneous settings. Ensure strong governance and operational controls are in place for the DEFAULT_ADMIN_ROLE and ISSUER_ROLE that can modify this parameter.

Status

Unresolved

Low

Redundant Return Value for Mint/Burn Functions

The mint and burn functions return a boolean true after calling _mint and _burn respectively. However, the _mint and _burn functions from ERC20Upgradeable do not return a boolean. This means the return true; statement is redundant and could be misleading if a future change to _mint or _burn were to return a boolean indicating success/failure. While not a direct vulnerability, it's a minor inconsistency. (7.2 Code Security)L-01

Issue

The mint and burn functions return a boolean true after calling _mint and _burn respectively. However, the _mint and _burn functions from ERC20Upgradeable do not return a boolean. This means the return true; statement is redundant and could be misleading if a future change to _mint or _burn were to return a boolean indicating success/failure. While not a direct vulnerability, it's a minor inconsistency. (7.2 Code Security)

Fix

Remove the returns (bool) and return true; statements from the mint and burn functions, as the underlying _mint and _burn functions do not return a boolean. This aligns the function signature with the inherited behavior.

Status

Unresolved

Analysis

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

The SecuritiesToken contract, an upgradeable ERC-20 token, implements a scaled UI amount standard (ERC8056) and integrates with compliance and pause management systems. The contract exhibits good adherence to upgradeability patterns and OpenZeppelin best practices. However, the audit identified a high degree of centralization in administrative control, critical dependencies on external contracts, and a wide range for economic parameters, which collectively contribute to a High overall risk level. Careful attention to governance, deployment procedures, and external contract security is crucial.

Technical4/10Medium risk

The contract demonstrates good technical practices, utilizing OpenZeppelin's upgradeable patterns and implementing robust checks for compliance and pausing within the _update function (7.2 Code Security). Error handling for zero addresses and empty strings is also well-implemented. However, the contract's security is highly dependent on the external ComplianceClient and PauseManagerClient contracts, which introduces a significant external dependency risk (7.6 External). Additionally, critical initialization parameters for admin_ and issuers_ require careful handling during deployment to prevent operational issues (7.8 Operations).

Governance1/10High risk

The contract design features a highly centralized access control model, with the DEFAULT_ADMIN_ROLE possessing extensive power over critical functions such as minting, burning, and setting external dependencies (7.3 Access Control). This centralization presents a significant governance risk, as a single compromised admin key could lead to severe consequences (7.5 Governance). Furthermore, the ERC8056 multiplier can be set within a very wide range by privileged roles, introducing potential economic instability if misused (7.4 Economic).

Upgrades1/10High risk

The contract is designed for upgradeability using the BeaconProxy pattern and OpenZeppelin's upgradeable contracts, including proper initializer functions and a __gap storage variable (7.1 Architecture). This structure generally supports safe future upgrades. However, the initialize function's critical parameters, particularly the admin_ address, must be set correctly during the initial deployment to ensure proper control and prevent contract lock-out or unintended ownership (7.7 Upgrades).

Final RecommendationWhat to do about this score

Prioritize strengthening the administrative control mechanisms.

Implement a multi-signature wallet or a time-locked governance system for the DEFAULT_ADMIN_ROLE to mitigate the single point of failure risk. Conduct thorough pre-deployment checks for all initialization parameters, especially the admin_ and issuers_ addresses, to prevent critical misconfigurations. Ensure that all external dependencies, particularly the ComplianceClient and PauseManagerClient, are rigorously audited and securely managed, as their integrity directly impacts the token's functionality. Review the acceptable range for the UI multiplier and consider narrowing it if the current wide range is not strictly necessary for the protocol's intended operation.

Contract & Record

1 audit on record
TypeBeaconProxy
NetworkBNB Chain
Token age2mo
Contract0x3ee4…50fb
Deployer0x64fd…8d53
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Badge for your website
Sandisk Corporation 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 2, 2026100Critical

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

Would You Like a More Detailed Audit of Sandisk Corporation?

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