Quantum Audit Logo

Is Sandisk Corporation Safe?

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

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

Sandisk Corporation SNDKB
0x3ee4…50fb
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
How is this score calculated? → Critical Risk
Executive 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. 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.

1 High3 Medium1 Low
Volume 24h
$227.8K
Liquidity
$335.0K
Price
$1565.0580
Token Age
2mo
Top 10 Holders
98.6%

Security Findings

High

High Centralization of Administrative Control

H-01The `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)
IssueThe `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)
FixConsider 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.
StatusUnresolved
Medium

Critical Initialization Parameter Dependency

M-01The `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)
IssueThe `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)
FixImplement 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).
StatusUnresolved
Medium

Reliance on External Compliance and Pause Managers

M-02The `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)
IssueThe `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)
FixEnsure 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.
StatusUnresolved
Medium

Wide Range for UI Multiplier Manipulation

M-03The `_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)
IssueThe `_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)
FixReview 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.
StatusUnresolved
Low

Redundant Return Value for Mint/Burn Functions

L-01The `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)
IssueThe `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)
FixRemove 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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).

GovernanceHigh1/10

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).

UpgradesHigh1/10

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).

Security Checklist

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

96.3% in wallets2.3% in contracts
Effective Concentration97.2%

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

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 Holder96.9%
Top-3 Unlocked99.8%

Key Addresses

Deployer
0x64fd…8d53
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.

What Raised This Score

  • 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

Related Audits

WebKey DAO 2.0 (WKEYDAO2)Critical RiskPieverse Token (PIEVERSE)Critical RiskSnapCoinCritical RiskSK Hynix (SKHYB)Critical RiskGameStop (GMEB)Critical RiskApple (AAPLB)Critical Risk

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