Quantum Audit Logo
Launch App

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

Is SpaceX xStock a Scam?

SPCXXEthereum
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 →
Last checked Sep 4, 2026 · 1 audit on recordNew Launch · 3d old
Critical RiskHow is this score calculated?
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.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • LP top3 unlocked holders = 80.3%
  • Token age < 7 days
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

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.

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
99.4%Wallets
99.4%Wallets
ContractsWalletsEveryone elseBubble area = share of supply
99.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking0.1%
  • Walletsanonymous holders, free to sell99.4%
  • Everyone elsethe rest of the supply0.4%
Effective concentrationwhat the score reads99.5%
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 4$29.2K across 5 pairs
LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$19.4KShare of depth66.4%
Top-1 Unlocked Holder37.4%
Top-3 Unlocked80.3%
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.

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Unverified Implementation Contract Source Code

The 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).C-01

Issue

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

Fix

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

Status

Unresolved

High

Lack of Transparency for Core Token Logic and Economic Parameters

Due 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).H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Potential Centralized Control over Token Functionality

While 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).M-01

Issue

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

Fix

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

Status

Unresolved

Low

Absence of Timelock for Proxy Upgrades

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

Utilization of Standard OpenZeppelin Upgradeable Libraries

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical4/10Medium risk

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.

Governance1/10High risk

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

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

The paramount recommendation is to immediately verify the source code of the BackedAutoFeeTokenImplementation contract on Etherscan or a similar block explorer.

This is crucial for transparency, user trust, and enabling proper security analysis. Additionally, consider implementing a timelock mechanism for all critical administrative operations, especially contract upgrades, to provide a delay period for community review and reaction. Ensure that all future implementation upgrades also have their source code publicly verified.

Contract & Record

1 audit on record
TypeBackedTokenProxy
NetworkEthereum
Token age3d
Contract0x68fa…ce28
Deployer0x5f7a…a2ad
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 2-of-3
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
SpaceX xStock security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History

    Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

    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.

    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 Is this your token? Publish your own audit on this page