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.

On-chain security analysis — is it a scam or legit?
Is Sandisk Corporation Safe?
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 →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- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking2.3%
- Walletsanonymous holders, free to sell96.3%
- Everyone elsethe rest of the supply1.4%
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 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x556b…d59e0x8f9e…575d0x2054…28e40xc351…30140x3cb6…ecb20x26f7…2b6f0x2e6c…f1fd0xa5a2…da5d0xd270…31440xde6a…c055No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighHigh 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
MediumCritical 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
MediumReliance 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
MediumWide 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
LowRedundant 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 4The 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).
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).
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).
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- 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