Quantum Audit Logo

Is SpaceXcoin a Scam?

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

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

SpaceXcoin SPACEXCOIN
0xf225…ffff
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The `Address.sol` library from OpenZeppelin provides essential utilities for interacting with addresses and performing low-level calls. It is a well-audited and widely used component in the EVM ecosystem. While the library itself is robust and secure, its functions, particularly those involving external calls, require careful implementation by calling contracts to prevent common vulnerabilities like reentrancy and misuse of powerful primitives.

1 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
$195.2K
Liquidity
$62.3K
Price
$0.000195
Token Age
3d
Top 10 Holders
48.2%

Security Findings

1 High1 Med1 Low1 Info
High

Reentrancy Risk from External Calls

H-01The `sendValue` and `functionCallWithValue` functions facilitate external calls, which are known vectors for reentrancy attacks. While the `Address` library itself is secure, calling contracts must implement the Checks-Effects-Interactions pattern or use reentrancy guards to prevent malicious re-entrances when interacting with untrusted external contracts. The library's documentation explicitly warns about this.
IssueThe `sendValue` and `functionCallWithValue` functions facilitate external calls, which are known vectors for reentrancy attacks. While the `Address` library itself is secure, calling contracts must implement the Checks-Effects-Interactions pattern or use reentrancy guards to prevent malicious re-entrances when interacting with untrusted external contracts. The library's documentation explicitly warns about this.
FixCalling contracts must ensure that state changes are completed before any external calls are made. Implement the Checks-Effects-Interactions pattern consistently or integrate a reentrancy guard mechanism (e.g., OpenZeppelin's `ReentrancyGuard`) in functions that perform external calls.
StatusUnresolved
Medium

Potential Misuse of `delegatecall`

M-01The `functionDelegateCall` function provides a low-level `delegatecall` wrapper. While correctly implemented within the library, `delegatecall` is a powerful and dangerous primitive. Incorrect usage in calling contracts, particularly in proxy patterns, can lead to storage collisions, unexpected behavior, or even critical vulnerabilities like arbitrary code execution or storage corruption if the target contract is not carefully managed.
IssueThe `functionDelegateCall` function provides a low-level `delegatecall` wrapper. While correctly implemented within the library, `delegatecall` is a powerful and dangerous primitive. Incorrect usage in calling contracts, particularly in proxy patterns, can lead to storage collisions, unexpected behavior, or even critical vulnerabilities like arbitrary code execution or storage corruption if the target contract is not carefully managed.
FixCalling contracts should use `delegatecall` only when absolutely necessary and with extreme caution. Ensure that the target contract's storage layout is compatible with the calling contract's, and that the target contract's logic is fully trusted and audited. Thorough testing is crucial for any `delegatecall` implementation.
StatusUnresolved
Low

Reliance on Caller's Security Practices

L-01As a utility library, `Address.sol` provides low-level functionalities like sending value and making calls without enforcing specific access control or security patterns. The overall security of a system using this library heavily depends on the calling contracts correctly implementing security best practices, such as access control (7.3 Access Control), reentrancy prevention, and proper error handling (7.8 Operations).
IssueAs a utility library, `Address.sol` provides low-level functionalities like sending value and making calls without enforcing specific access control or security patterns. The overall security of a system using this library heavily depends on the calling contracts correctly implementing security best practices, such as access control (7.3 Access Control), reentrancy prevention, and proper error handling (7.8 Operations).
FixDevelopers integrating this library must ensure that all functions utilizing `Address.sol`'s utilities are protected by appropriate access control mechanisms and adhere to robust security patterns to prevent unauthorized or malicious use.
StatusUnresolved
Info

Limitations of `isContract` Function

I-01The `isContract` function, while useful for certain checks, has documented limitations. It may return `false` for contracts under construction, destroyed contracts, or addresses where a contract will be created. Furthermore, the library explicitly states that `isContract` should not be relied upon to protect against flash loan attacks or to prevent calls from contracts, as it can be circumvented.
IssueThe `isContract` function, while useful for certain checks, has documented limitations. It may return `false` for contracts under construction, destroyed contracts, or addresses where a contract will be created. Furthermore, the library explicitly states that `isContract` should not be relied upon to protect against flash loan attacks or to prevent calls from contracts, as it can be circumvented.
FixDevelopers should be fully aware of the caveats associated with `isContract` and avoid using it for critical security checks where its limitations could be exploited. Consider alternative, more robust mechanisms for contract type verification or access control if strict differentiation is required.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The `Address.sol` library provides robust and well-tested utilities for safe external interactions, including `sendValue` and various `functionCall` wrappers, which correctly handle success checks and error propagation (7.2 Code Security). The library explicitly warns about reentrancy risks associated with external calls, emphasizing the need for the Checks-Effects-Interactions pattern in calling contracts. While the `isContract` function is useful, its limitations are clearly documented (7.1 Architecture).

GovernanceMedium5/10

As a foundational utility library, `Address.sol` does not incorporate specific governance or economic mechanisms (7.4 Economic, 7.5 Governance). Its design is purely functional, providing low-level address interaction capabilities without affecting tokenomics or decision-making processes. The library's security is independent of any external governance or economic models.

UpgradesLow9/10

The `Address.sol` library is typically integrated directly into contracts or linked, rather than being deployed as an upgradeable component (7.7 Upgrades). It does not implement proxy patterns or upgrade mechanisms itself. Therefore, upgrade safety concerns are not directly applicable to this library, but rather to the contracts that utilize it in an upgradeable architecture.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

48.2% in top 10
7.0% in wallets41.2% in contracts
Effective Concentration23.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

$62.3K across 4 pairs
Pancakeswap v2SPCXBanalysed$62.3K100.0%Pancakeswap v2WBNB$180.0%Pancakeswap v2未来引力$00.0%Pancakeswap v2金刚$00.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xe45d…b97b
Unlocked LP Held By
0xb94f…5030

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

What Raised This Score

8 factors
  • Top-10 concentration > 20% (48.2% total → 23.5% effective; 7.0% in EOAs, 41.2% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 7 days (early, volatile)
  • 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
XPIN Token (XPIN)Medium RiskTRADOORMedium RiskBeat Token (BEAT)Medium RiskNew BNB Coin (NNB)Medium RiskGen Z (Z)Medium RiskARKMedium Risk

Would You Like a More Detailed Audit of SpaceXcoin?

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

Get Detailed Audit