Quantum Audit Logo

Is SpaceX xStock a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

SpaceX xStock SPCXX
0x68fa…ce28
Ethereum Not verifiedLast checked 3d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The audit of the Backed Auto Fee Token project reveals a critical concern: the implementation contract's source code is not publicly verified. This significantly hinders the ability to assess the core business logic and introduces substantial trust requirements. While the project utilizes a standard OpenZeppelin Transparent Proxy pattern with a multisig admin, the lack of transparency for the underlying token logic poses a severe risk to users.

1 Critical1 High1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (3d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$6.7K
Liquidity
$19.4K
Price
$148.4200
Token Age
3d
Top 10 Holders
99.6%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Unverified Implementation Contract Source Code

C-01The source code for the `BackedAutoFeeTokenImplementation` contract (0x65c4…f19b), which contains the core logic of the token, is not publicly verified on the blockchain explorer. This means that users, auditors, and the community cannot independently verify what code is actually running on-chain, making it impossible to assess its security, functionality, or adherence to stated specifications. This introduces a fundamental trust issue and prevents any meaningful security analysis of the token's behavior (7.2 Code Security).
IssueThe source code for the `BackedAutoFeeTokenImplementation` contract (), which contains the core logic of the token, is not publicly verified on the blockchain explorer. This means that users, auditors, and the community cannot independently verify what code is actually running on-chain, making it impossible to assess its security, functionality, or adherence to stated specifications. This introduces a fundamental trust issue and prevents any meaningful security analysis of the token's behavior (7.2 Code Security).
FixImmediately verify the source code of the `BackedAutoFeeTokenImplementation` contract on Etherscan (or the relevant block explorer). This is a critical step for transparency and establishing trust with users. Ensure that the verified code matches the deployed bytecode exactly.
StatusUnresolved
High

Lack of Transparency for Core Token Logic and Economic Parameters

H-01Due to the unverified implementation source code (C-01), the specific functionalities of the 'Auto Fee Token' (e.g., how fees are calculated, collected, and distributed; minting/burning capabilities; pausing mechanisms; blacklisting features) remain entirely opaque. This lack of transparency extends to critical economic parameters that could significantly impact token holders (7.4 Economic). Without visibility into the code, there is no way to confirm that the token operates as expected or that it doesn't contain hidden backdoors or malicious logic (7.5 Governance).
IssueDue to the unverified implementation source code (C-01), the specific functionalities of the 'Auto Fee Token' (e.g., how fees are calculated, collected, and distributed; minting/burning capabilities; pausing mechanisms; blacklisting features) remain entirely opaque. This lack of transparency extends to critical economic parameters that could significantly impact token holders (7.4 Economic). Without visibility into the code, there is no way to confirm that the token operates as expected or that it doesn't contain hidden backdoors or malicious logic (7.5 Governance).
FixBeyond verifying the source code, provide comprehensive documentation detailing the token's economic model, fee mechanisms, and all administrative functionalities. Clearly outline the roles and permissions of any privileged addresses within the token contract. Regular audits of the verified code should be conducted and published.
StatusUnresolved
Medium

Potential Centralized Control over Token Functionality

M-01While the proxy admin is controlled by a multisig, the `BackedAutoFeeTokenImplementation` contract likely inherits `OwnableUpgradeable` (as indicated by the provided snippets). Without the implementation source, it is unknown whether the owner of the token's core functionalities (e.g., minting, burning, pausing, modifying fee parameters) is a single EOA, a multisig, or a timelock-controlled address (7.3 Access Control). If controlled by a single EOA, it presents a single point of failure and a significant centralization risk for critical token operations (7.8 Operations).
IssueWhile the proxy admin is controlled by a multisig, the `BackedAutoFeeTokenImplementation` contract likely inherits `OwnableUpgradeable` (as indicated by the provided snippets). Without the implementation source, it is unknown whether the owner of the token's core functionalities (e.g., minting, burning, pausing, modifying fee parameters) is a single EOA, a multisig, or a timelock-controlled address (7.3 Access Control). If controlled by a single EOA, it presents a single point of failure and a significant centralization risk for critical token operations (7.8 Operations).
FixIf the token's core functionalities are controlled by a single EOA, consider migrating ownership to a robust multisig wallet or a timelock-controlled address. Clearly document all privileged roles and their associated addresses, along with the rationale for their access levels.
StatusUnresolved
Low

Absence of Timelock for Proxy Upgrades

L-01The proxy upgrade mechanism, while controlled by a 2-of-3 Gnosis Safe multisig, does not incorporate a timelock (7.7 Upgrades). This means that once the required multisig confirmations are met, an upgrade can be executed immediately. While a multisig provides a layer of security by requiring multiple approvals, a timelock would introduce a mandatory delay, allowing users and external monitors to review proposed changes and react if a malicious or erroneous upgrade is initiated.
IssueThe proxy upgrade mechanism, while controlled by a 2-of-3 Gnosis Safe multisig, does not incorporate a timelock (7.7 Upgrades). This means that once the required multisig confirmations are met, an upgrade can be executed immediately. While a multisig provides a layer of security by requiring multiple approvals, a timelock would introduce a mandatory delay, allowing users and external monitors to review proposed changes and react if a malicious or erroneous upgrade is initiated.
FixConsider integrating a timelock mechanism into the upgrade process. This would involve the multisig proposing an upgrade, which then enters a predefined delay period before it can be executed. This provides an additional safety net for users and the protocol.
StatusUnresolved
Info

Utilization of Standard OpenZeppelin Upgradeable Libraries

I-01The project leverages well-audited and widely adopted OpenZeppelin Contracts Upgradeable libraries, including `ERC20Upgradeable`, `OwnableUpgradeable`, and `Initializable`. This foundation provides a strong baseline for security and adherence to established standards for upgradeable contracts and token implementations (7.1 Architecture, 7.2 Code Security). The use of these battle-tested components reduces the risk of common vulnerabilities inherent in custom implementations of these primitives.
IssueThe project leverages well-audited and widely adopted OpenZeppelin Contracts Upgradeable libraries, including `ERC20Upgradeable`, `OwnableUpgradeable`, and `Initializable`. This foundation provides a strong baseline for security and adherence to established standards for upgradeable contracts and token implementations (7.1 Architecture, 7.2 Code Security). The use of these battle-tested components reduces the risk of common vulnerabilities inherent in custom implementations of these primitives.
FixContinue to rely on reputable and audited libraries for core functionalities. Ensure that all OpenZeppelin components are used correctly, especially regarding initialization patterns in upgradeable contracts, to avoid common proxy-related pitfalls.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The technical architecture leverages OpenZeppelin's upgradeable contracts (ERC20Upgradeable, OwnableUpgradeable, Initializable), which are well-audited and robust (7.1 Architecture). However, the critical issue is the unverified source code for the `BackedAutoFeeTokenImplementation` contract (7.2 Code Security). This prevents any meaningful technical analysis of the token's core logic, such as fee mechanisms, minting/burning, or reentrancy vulnerabilities. Without the source, the actual code running on-chain cannot be verified against any public specification.

GovernanceHigh1/10

The proxy administration is secured by a 2-of-3 Gnosis Safe multisig, which is a strong access control mechanism for upgrades (7.3 Access Control). However, the economic parameters and core functionalities of the `BackedAutoFeeTokenImplementation` (e.g., fee rates, supply management) are entirely opaque due to the unverified source (7.4 Economic). This lack of transparency means that critical economic aspects could be altered or exploited without public scrutiny, posing a significant governance risk (7.5 Governance).

UpgradesHigh1/10

The contract utilizes the EIP-1967 Transparent Proxy pattern with an OpenZeppelin ProxyAdmin, which is a standard and well-understood upgrade mechanism (7.7 Upgrades). The proxy admin is controlled by a 2-of-3 multisig, enhancing upgrade security. However, the absence of a timelock for upgrade operations means that a malicious multisig could execute an upgrade without giving users time to react. More critically, the unverified implementation source means any upgrade could introduce unknown or malicious code, making it impossible for users to verify the safety of new versions.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 2-of-3
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

99.6% in top 10
99.4% in wallets0.1% in contracts
Effective Concentration99.5%

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

$29.2K across 5 pairs
Uniswap v4USDCanalysed$19.4K66.4%Uniswap v3GOOGLon$5.0K17.1%Uniswap v4USDC$2.6K9.1%Uniswap v4ETH$2.0K6.7%Uniswap v4USDC$1990.7%

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 Holder37.4%
Top-3 Unlocked80.3%

Key Addresses

10 addresses
Deployer
0x5f7a…a2ad
Unlocked LP Held By
0x03e4…45010xe5e3…88bc0x24dc…0cbe0x459b…03b50xb5a3…b5b10x666e…87a40x99c3…d1eb0xfa4f…0b830x8b4a…bf77

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

What Raised This Score

12 factors
  • Ownership NOT renounced — Multisig (2-of-3)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (99.6% total → 99.5% effective; 99.4% in EOAs, 0.1% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($29,158 across 5 pairs — thin market)
  • LP top3 unlocked holders = 80.3% (independent LP — depth risk, pool = 66% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 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

Frequently Asked Questions

Is SpaceX xStock a scam?

Labeling SpaceX xStock as an outright scam based solely on provided data is not definitive. While the contract is verified and ownership renounced, significantly concerning factors exist. 99.9% of the supply is controlled by the top 10 holders, indicating extreme centralization, and liquidity is not locked. These characteristics create a high potential for price manipulation or a liquidity pull. The assigned risk score of 60/100 reflects these considerable dangers, urging extreme vigilance from investors.

Is SpaceX xStock safe to buy?

SpaceX xStock (SPCXX) carries significant risks and is not considered safe to buy based on current metrics. A critical concern is that 99.9% of the token supply is concentrated within the top 10 holders, making it highly susceptible to manipulation. Furthermore, the absence of locked liquidity means that the existing funds can be withdrawn at any time, posing a direct rug pull risk. Its overall risk score of 60/100 strongly indicates a hazardous investment profile.

Has SpaceX xStock been audited?

The SpaceX xStock (SPCXX) smart contract is verified, making its code public and reviewable for transparency. However, 'contract verified' differs from a comprehensive security audit conducted by an independent firm. An audit involves a deeper, expert analysis to proactively identify vulnerabilities. The provided data does not confirm that such a formal audit has been performed for SPCXX.

Related Audits

6 more on the record
BananaCritical RiskPonsCritical RiskGoldfish (GGBR)Critical RiskAUSDCritical RiskHumanity (H)Critical RiskVision (VSN)Critical Risk

Would You Like a More Detailed Audit of SpaceX xStock?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit