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

Is SpaceXcoin a Scam?

SPACEXCOIN

BNB Chain

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

Chart

34/ 100

Low RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical9/10 Governance5/10 Upgrades9/10 Checks passed4 of 5 Findings1 High · 1 Medium · 1 Low · 1 Info4

SummaryAI Copilot

The Address.sol library from OpenZeppelin provides essential utilities for interacting with addresses and performing low-level calls.

Read the full analysis

What raised the score

Top-10 concentration > 20%
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0%
LP top3 unlocked holders = 100.0%
Token age < 7 days
1 High finding(s) from audit
1 Medium finding(s) from audit
1 Low finding(s) from audit

Exact 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

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 44 of 5 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockNot locked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

48.2%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking41.2%
Walletsanonymous holders, free to sell7.0%
Everyone elsethe rest of the supply51.8%

Effective concentrationwhat the score reads23.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$62.3K across 4 pairs

The risk score reads depth across every pair.

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$62.3KShare of depth100.0%

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Unlocked LP held by

0xb94f…5030

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

Security Findings

1 High1 Medium1 Low1 Info

High

Reentrancy Risk from External Calls

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

Issue

Fix

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

Status

Unresolved

Medium

Potential Misuse of `delegatecall`

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

Issue

Fix

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

Status

Unresolved

Low

Reliance on Caller's Security Practices

As 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).L-01

Issue

Fix

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

Status

Unresolved

Info

Limitations of `isContract` Function

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

Issue

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

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.

Technical9/10Low risk

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

Governance5/10Medium risk

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.

Upgrades9/10Low risk

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.

Final RecommendationWhat to do about this score

Projects integrating the Address.sol library must prioritize secure usage patterns, especially when performing external calls.

Always apply the Checks-Effects-Interactions pattern or use reentrancy guards when interacting with untrusted external contracts via sendValue or functionCallWithValue. Exercise extreme caution and thorough testing when utilizing functionDelegateCall to prevent storage collisions or unintended logic execution, particularly in upgradeable proxy environments. Ensure that any contract relying on isContract understands its inherent limitations.

Contract & Record

1 audit on record

TypeToken

NetworkBNB Chain

Token age3d

Contract0xf225…ffff

Deployer0xe45d…b97b

Badge for your website

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

Aug 13, 202634Low

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

Frequently Asked Questions

What is the SPACEXCOIN contract address?

The SpaceXcoin contract on BNB Chain is 0xf225e70162837a811c77dc2bb413a5c06e97ffff. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.