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.

Early-stage security check — honeypot & rug-pull analysis
Is SpaceX xStock a Scam?
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 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- 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking0.1%
- Walletsanonymous holders, free to sell99.4%
- Everyone elsethe rest of the supply0.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 4- 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 LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x03e4…45010xe5e3…88bc0x24dc…0cbe0x459b…03b50xb5a3…b5b10x666e…87a40x99c3…d1eb0xfa4f…0b830x8b4a…bf77No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
CriticalUnverified 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
HighLack 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
MediumPotential 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
LowAbsence 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
InfoUtilization 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 4The 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.
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).
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
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