Quantum Audit Logo

Is Apple Safe?

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

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

Apple AAPLB
0x431a…9b7a
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The audit focused on the `SecuritiesToken` contract, which serves as the implementation for a BeaconProxy. The contract implements an upgradeable ERC-20 token with custom scaling (`ERC8056BaseUpgradeable`), access control, compliance, and pause functionalities. While the contract leverages well-audited OpenZeppelin libraries for upgradeability and access control, several areas of concern were identified, primarily related to centralized administrative power, the broad authority granted to the 'Issuer' role, and dependencies on external contracts. A critical missing zero-address check for the admin during initialization was also noted. The `ERC8056BaseUpgradeable` code was truncated, limiting a full review of its complex scaling logic.

2 High2 Medium1 Low1 Informational
Volume 24h
$402.4K
Liquidity
$373.6K
Price
$320.6500
Token Age
1mo
Top 10 Holders
93.4%

Security Findings

2 High2 Med1 Low1 Info
High

Centralized Control by DEFAULT_ADMIN_ROLE

H-01The `DEFAULT_ADMIN_ROLE` holds extensive power, including the ability to set token name/symbol/identifier, enable/disable minting/burning, manage all roles (including `ISSUER_ROLE`), and set the addresses for the `ComplianceClient` and `PauseManagerClient`. A compromise of this single role would grant an attacker full control over the token's functionality and potentially its economic parameters.
IssueThe `DEFAULT_ADMIN_ROLE` holds extensive power, including the ability to set token name/symbol/identifier, enable/disable minting/burning, manage all roles (including `ISSUER_ROLE`), and set the addresses for the `ComplianceClient` and `PauseManagerClient`. A compromise of this single role would grant an attacker full control over the token's functionality and potentially its economic parameters.
FixImplement a multi-signature wallet for the `DEFAULT_ADMIN_ROLE` to distribute control and require multiple approvals for critical operations. This significantly reduces the risk of a single point of failure.
StatusUnresolved
High

Issuer Role Can Authorize Multiplier Updates

H-02The `_authorizeMultiplierUpdate()` function, which is a prerequisite for changing the `_uiMultiplier`, is accessible to both `DEFAULT_ADMIN_ROLE` and `ISSUER_ROLE` via the `onlyAdminOrIssuer` modifier. Changes to the `_uiMultiplier` directly impact the token's value and user balances. Granting this powerful ability to potentially multiple `ISSUER_ROLE` holders increases the attack surface for economic manipulation or accidental misconfiguration, as the `ISSUER_ROLE`'s primary function is typically related to minting/burning, not economic parameter adjustments.
IssueThe `_authorizeMultiplierUpdate()` function, which is a prerequisite for changing the `_uiMultiplier`, is accessible to both `DEFAULT_ADMIN_ROLE` and `ISSUER_ROLE` via the `onlyAdminOrIssuer` modifier. Changes to the `_uiMultiplier` directly impact the token's value and user balances. Granting this powerful ability to potentially multiple `ISSUER_ROLE` holders increases the attack surface for economic manipulation or accidental misconfiguration, as the `ISSUER_ROLE`'s primary function is typically related to minting/burning, not economic parameter adjustments.
FixRestrict the `_authorizeMultiplierUpdate()` function to only the `DEFAULT_ADMIN_ROLE`. This ensures that only the most trusted and secure role can initiate changes to the token's core economic scaling factor.
StatusUnresolved
Medium

Missing Zero Address Check for Admin in Initializer

M-01The `initialize` function grants the `DEFAULT_ADMIN_ROLE` to the `admin_` address provided. However, there is no check to ensure that `admin_` is not `address(0)`. If the contract is initialized with `admin_` as `address(0)`, no entity would possess the `DEFAULT_ADMIN_ROLE`, rendering the contract unmanageable and unable to perform critical administrative functions (e.g., setting compliance, pause manager, or granting other roles).
IssueThe `initialize` function grants the `DEFAULT_ADMIN_ROLE` to the `admin_` address provided. However, there is no check to ensure that `admin_` is not `address(0)`. If the contract is initialized with `admin_` as `address(0)`, no entity would possess the `DEFAULT_ADMIN_ROLE`, rendering the contract unmanageable and unable to perform critical administrative functions (e.g., setting compliance, pause manager, or granting other roles).
FixAdd a `require(admin_ != address(0), "ZeroAddress");` check at the beginning of the `__securitiesToken_init` function to prevent initialization with a zero address admin.
StatusUnresolved
Medium

Dependency on External Compliance and Pause Manager Contracts

M-02The `SecuritiesToken` contract relies heavily on external `ComplianceClientUpgradeable` and `PauseManagerClientUpgradeable` contracts, whose addresses are set by the `DEFAULT_ADMIN_ROLE`. The security and trustworthiness of these external contracts are paramount, as a malicious or compromised `ComplianceClient` could block legitimate transfers or allow non-compliant ones, and a malicious `PauseManagerClient` could permanently pause the token or pause it at will, effectively freezing all token operations.
IssueThe `SecuritiesToken` contract relies heavily on external `ComplianceClientUpgradeable` and `PauseManagerClientUpgradeable` contracts, whose addresses are set by the `DEFAULT_ADMIN_ROLE`. The security and trustworthiness of these external contracts are paramount, as a malicious or compromised `ComplianceClient` could block legitimate transfers or allow non-compliant ones, and a malicious `PauseManagerClient` could permanently pause the token or pause it at will, effectively freezing all token operations.
FixEnsure that the `ComplianceClient` and `PauseManagerClient` contracts are thoroughly audited, well-secured, and controlled by trusted entities, ideally through a multi-signature setup. Implement robust monitoring for these external contracts. Consider adding a time-lock or governance mechanism for changing these critical external contract addresses.
StatusUnresolved
Low

Inconsistent Pragma Version

L-01The main `SecuritiesToken.sol` contract uses `pragma solidity ^0.8.20;` while the imported `ERC8056BaseUpgradeable.sol` uses `pragma solidity ^0.8.24;`. Although both versions are compatible with a compiler version of 0.8.24 (as indicated in the prefill), maintaining a consistent pragma across all contract files is a best practice for clarity and to avoid potential future compiler-related issues or warnings.
IssueThe main `SecuritiesToken.sol` contract uses `pragma solidity ^0.8.20;` while the imported `ERC8056BaseUpgradeable.sol` uses `pragma solidity ^0.8.24;`. Although both versions are compatible with a compiler version of 0.8.24 (as indicated in the prefill), maintaining a consistent pragma across all contract files is a best practice for clarity and to avoid potential future compiler-related issues or warnings.
FixStandardize the pragma version across all contract files to `pragma solidity ^0.8.24;` or the specific version used for compilation.
StatusUnresolved
Info

Truncated `ERC8056BaseUpgradeable` Code

I-01The provided source code for the `ERC8056BaseUpgradeable` contract was truncated. This contract is fundamental to the `SecuritiesToken`'s core token mechanics, particularly its scaled amount (`_uiMultiplier`) logic. A complete security assessment of the `SecuritiesToken`'s economic model and potential for integer overflows/underflows or rounding errors within the scaling mechanism requires a full review of the `ERC8056BaseUpgradeable` implementation.
IssueThe provided source code for the `ERC8056BaseUpgradeable` contract was truncated. This contract is fundamental to the `SecuritiesToken`'s core token mechanics, particularly its scaled amount (`_uiMultiplier`) logic. A complete security assessment of the `SecuritiesToken`'s economic model and potential for integer overflows/underflows or rounding errors within the scaling mechanism requires a full review of the `ERC8056BaseUpgradeable` implementation.
FixProvide the complete source code for all inherited and imported contracts to enable a comprehensive security audit of the entire system.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The technical architecture is sound, utilizing OpenZeppelin's upgradeable contracts and access control patterns (7.1 Architecture, 7.2 Code Security). The contract correctly implements `__gap` storage for upgradeability and uses `onlyInitializing` and `_disableInitializers()` for secure initialization. However, a missing zero-address check for the admin in the `initialize` function could lead to an unmanageable contract if deployed incorrectly (7.2 Code Security). Additionally, the `ERC8056BaseUpgradeable` contract's core logic for scaled amounts was truncated, preventing a full assessment of its potential for rounding errors or other vulnerabilities (7.2 Code Security).

GovernanceHigh1/10

The contract exhibits a high degree of centralization, with the `DEFAULT_ADMIN_ROLE` possessing extensive control over critical parameters, role management, and external dependencies (7.3 Access Control, 7.8 Operations). A compromise of this single role would grant full control over the token's supply and functionality. Furthermore, the `ISSUER_ROLE` is empowered to authorize `_uiMultiplier` updates, which directly impacts the token's economic value and user balances, increasing the risk of economic manipulation if an issuer's key is compromised (7.4 Economic, 7.3 Access Control). The reliance on external `ComplianceClient` and `PauseManagerClient` contracts introduces a dependency risk, as their security and trustworthiness directly impact the `SecuritiesToken`'s integrity (7.6 External).

UpgradesHigh1/10

The contract is designed as an upgradeable implementation for a BeaconProxy, correctly utilizing OpenZeppelin's upgradeable patterns (7.7 Upgrades). The `__gap` storage variable is present, ensuring future storage compatibility. The initializer functions are properly guarded with `onlyInitializing` and `_disableInitializers()`, mitigating re-initialization risks. The `_setUIMultiplier` function includes a reasonable time constraint for future multiplier changes, enhancing upgrade safety (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

Holder Composition

93.4% in top 10
83.8% in wallets9.6% in contracts
Effective Concentration87.7%

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

$435.4K across 7 pairs
Pancakeswap v3USDTanalysed$373.6K85.8%UniswapUSDT$60.7K13.9%Pancakeswap v2WBNB$6510.1%Pancakeswap v3SPYB$2070.0%Pancakeswap v3GOOGLB$2020.0%Pancakeswap v3WBNB$400.0%
Show 1 more pairShow less
Pancakeswap v3USDT$10.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 Holder53.5%
Top-3 Unlocked91.9%

Key Addresses

11 addresses
Deployer
0x64fd…8d53
Unlocked LP Held By
0xf949…02980x556b…d59e0x4a1b…2dc70x94ad…b4330x1fee…ed6f0xac9c…e5ab0xf210…69500xd9a2…040b0xe9ce…c8a70xdd73…ddfd

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

What Raised This Score

11 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% (93.4% total → 87.7% effective; 83.8% in EOAs, 9.6% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 53.5% (independent LP — depth risk, pool = 86% of DEX liquidity)
  • LP top3 unlocked holders = 91.9% (independent LP — depth risk, pool = 86% of DEX liquidity)
  • 2 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

Related Audits

6 more on the record
WebKey DAO 2.0 (WKEYDAO2)Critical RiskPieverse Token (PIEVERSE)Critical RiskSnapCoinCritical RiskSK Hynix (SKHYB)Critical RiskGameStop (GMEB)Critical RiskSandisk Corporation (SNDKB)Critical Risk

Would You Like a More Detailed Audit of Apple?

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

Get Detailed Audit