Quantum Audit Logo

Is SpaceX Safe?

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

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

SpaceX SPCXB
0xbe9d…03e1
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The SecuritiesToken contract implements an upgradeable ERC-20 token with compliance, pausing, and a scaled UI multiplier mechanism. It leverages OpenZeppelin's upgradeable patterns and access control. The contract demonstrates good adherence to upgradeability best practices and includes robust checks for initialization and token operations. However, the system exhibits significant centralization of control in the `DEFAULT_ADMIN_ROLE` and `ISSUER_ROLE`, particularly concerning the ability to modify critical external dependencies and economic parameters. The wide range allowed for the UI multiplier also presents a notable economic risk.

1 High1 Medium1 Low1 Informational
Volume 24h
$1.87M
Liquidity
$2.22M
Price
$150.2200
Token Age
1mo
Top 10 Holders
86.9%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control over Critical Functions and External Dependencies

H-01The `DEFAULT_ADMIN_ROLE` possesses extensive control over the `SecuritiesToken` contract. This role can change the addresses of the `ComplianceClient` and `PauseManagerClient` contracts, enable/disable minting and burning, and authorize UI multiplier updates. This level of centralization means that a compromise or malicious action by a single administrator could lead to a complete system takeover, including disabling compliance, pausing all operations, or manipulating the token supply and value.
IssueThe `DEFAULT_ADMIN_ROLE` possesses extensive control over the `SecuritiesToken` contract. This role can change the addresses of the `ComplianceClient` and `PauseManagerClient` contracts, enable/disable minting and burning, and authorize UI multiplier updates. This level of centralization means that a compromise or malicious action by a single administrator could lead to a complete system takeover, including disabling compliance, pausing all operations, or manipulating the token supply and value.
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `DEFAULT_ADMIN_ROLE` to require multiple approvals for critical operations, such as changing external contract addresses or modifying core token parameters. Consider time-locks for highly sensitive actions to provide a window for community review or emergency intervention.
StatusUnresolved
Medium

Wide UI Multiplier Range with Potential Economic Impact

M-01The `_validateMultiplier` function allows the UI multiplier to be set within an extremely wide range, from `1e9` (0.000000001x) to `1e27` (1,000,000,000x). While controlled by privileged roles (`DEFAULT_ADMIN_ROLE` or `ISSUER_ROLE`) and limited to 365 days in the future, such drastic changes in the multiplier could significantly impact the token's perceived value and user balances, potentially leading to economic instability or unexpected behavior if not managed with extreme care.
IssueThe `_validateMultiplier` function allows the UI multiplier to be set within an extremely wide range, from `1e9` (0.000000001x) to `1e27` (1,000,000,000x). While controlled by privileged roles (`DEFAULT_ADMIN_ROLE` or `ISSUER_ROLE`) and limited to 365 days in the future, such drastic changes in the multiplier could significantly impact the token's perceived value and user balances, potentially leading to economic instability or unexpected behavior if not managed with extreme care.
FixReview the intended economic model and consider if such a wide multiplier range is truly necessary. If not, narrow the allowed range to reduce the potential for extreme value fluctuations. Implement a more robust governance process or a time-locked delay for multiplier changes, especially for significant adjustments, to allow stakeholders to react.
StatusUnresolved
Low

Reliance on External Contract Security

L-01The `SecuritiesToken` contract heavily relies on the `ComplianceClientUpgradeable` and `PauseManagerClientUpgradeable` for critical functionality, including transaction validation and pausing mechanisms. The security and correct functioning of these external contracts are paramount to the overall integrity of the token. Any vulnerabilities or malicious implementations within these external dependencies could directly compromise the `SecuritiesToken`.
IssueThe `SecuritiesToken` contract heavily relies on the `ComplianceClientUpgradeable` and `PauseManagerClientUpgradeable` for critical functionality, including transaction validation and pausing mechanisms. The security and correct functioning of these external contracts are paramount to the overall integrity of the token. Any vulnerabilities or malicious implementations within these external dependencies could directly compromise the `SecuritiesToken`.
FixEnsure that the `ComplianceClientUpgradeable` and `PauseManagerClientUpgradeable` contracts have undergone thorough security audits. Implement robust monitoring for these external contracts to detect any unexpected behavior or changes. Consider adding mechanisms to gracefully handle failures or unexpected returns from these external calls, if applicable.
StatusUnresolved
Info

Significant Power of ISSUER_ROLE

I-01The `ISSUER_ROLE` has the authority to mint and burn tokens, as well as to authorize UI multiplier updates. This grants significant power over the token's supply and economic parameters. While this is likely an intended design, it highlights the importance of securing the keys associated with this role.
IssueThe `ISSUER_ROLE` has the authority to mint and burn tokens, as well as to authorize UI multiplier updates. This grants significant power over the token's supply and economic parameters. While this is likely an intended design, it highlights the importance of securing the keys associated with this role.
FixEnsure that all addresses assigned the `ISSUER_ROLE` are managed with the highest security standards, potentially using multi-signature wallets or hardware security modules. Implement strict operational procedures and access controls around these privileged accounts.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical architecture (7.1) is well-structured, utilizing OpenZeppelin's upgradeable contracts and a clear separation of concerns for compliance and pausing. Code security (7.2) is generally strong, with appropriate use of modifiers, error handling, and Solidity 0.8+ safety features. For example, `_update` includes comprehensive compliance checks for `msg.sender`, `from`, and `to` addresses. However, the reliance on external `ComplianceClient` and `PauseManagerClient` contracts (7.6) introduces a dependency risk, as their security directly impacts the token's integrity. No reentrancy or integer overflow/underflow vulnerabilities were identified.

GovernanceHigh1/10

Access control (7.3) is managed via `AccessControlEnumerableUpgradeable`, defining `DEFAULT_ADMIN_ROLE` and `ISSUER_ROLE`. The `DEFAULT_ADMIN_ROLE` holds significant power, including the ability to set `ComplianceClient` and `PauseManagerClient` addresses, enable/disable minting/burning, and authorize multiplier updates. This centralization (7.5) presents a single point of failure. Economically (7.4), the `_validateMultiplier` function allows a very wide range for the UI multiplier (1e-9x to 1e9x), which, while controlled by privileged roles, could lead to drastic token revaluation if misused. The `ISSUER_ROLE` also has substantial power to mint and burn tokens.

UpgradesHigh1/10

The contract is designed for upgradeability using the BeaconProxy pattern, with the provided code serving as the implementation. It correctly uses OpenZeppelin's `initializer` modifier and `_disableInitializers()` in the constructor to prevent re-initialization. The `__gap` storage variable is appropriately included to ensure future storage layout compatibility. The initialization logic for all inherited upgradeable contracts is correctly chained, demonstrating robust upgrade safety (7.7).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source

Holder Composition

86.9% in top 10
82.3% in wallets4.6% in contracts
Effective Concentration84.1%

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

$6.23M across 16 pairs
Pancakeswap v3USDTanalysed$2.22M35.7%Pancakeswap v2MarsCoin$1.88M30.2%Pancakeswap v3WBNB$1.39M22.4%Pancakeswap v3USDT$327.2K5.3%UniswapUSDT$238.6K3.8%UniswapUSDT$130.7K2.1%
Show 4 more pairsShow less
Pancakeswap v2WBNB$26.1K0.4%TopazUSDT$2.0K0.0%Uniswap比特币$7550.0%Pancakeswap v3WBNB$6090.0%

The 6 remaining pairs hold $985 between them and are not listed.

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 Holder49.7%
Top-3 Unlocked77.0%

Key Addresses

11 addresses
Deployer
0x64fd…8d53
Unlocked LP Held By
0x556b…d59e0xf949…02980xe63b…34b40x2fc7…5e3f0xf33b…b2f10x84a4…dee60xef6e…cce70x4686…f0050x2216…1e930x755a…2c89

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

What Raised This Score

9 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% (86.9% total → 84.1% effective; 82.3% in EOAs, 4.6% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 High finding(s) from audit
  • 1 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
Lorenzo Governance Token (BANK)Critical RiskVenusCoinCritical RiskBedrock (BR)Critical RiskCysic Token (CYS)Critical RiskBased Token (BASED)Critical RiskZypher Token (POP)Critical Risk

Would You Like a More Detailed Audit of SpaceX?

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

Get Detailed Audit