Is SPX6900 (SPX) Safe? Smart Contract Security Analysis

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Audit History

2 audits on record

Jul 2336

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The SPX token contract exhibits a high degree of centralization, with the owner possessing extensive control over critical parameters such as taxes, trading status, and transfer restrictions. This centralized power, combined with initially high sell taxes, introduces significant economic and security risks, including the potential for rug pulls or honeypot scenarios. While standard security practices like SafeMath are employed, the complex transfer logic adds to the technical risk.

Final Recommendation: Users should exercise extreme caution when interacting with this token due to the extensive centralized control held by the contract owner. The ability to modify taxes, trading status, and transfer restrictions at will introduces significant economic risks. Developers are strongly advised to decentralize control by implementing multi-signature wallets for critical functions, time-locks for parameter changes, or by renouncing ownership after a stable period, if feasible. Additionally, simplify the complex transfer logic to reduce the attack surface for potential logical errors.

Category Ratings

TechnicalMedium

5/10

The contract utilizes SafeMath for arithmetic operations, mitigating common integer overflow/underflow vulnerabilities (7.2 Code Security). The `inSwap` modifier helps prevent reentrancy during liquidity swaps. However, the `_transfer` function's extensive conditional logic, incorporating taxes

GovernanceLow

7/10

The contract grants the owner absolute control over critical economic parameters and operational aspects (7.3 Access Control, 7.4 Economic, 7.5 Governance, 7.8 Operations). The owner can set extremely high buy and sell taxes (e.g., initial 70% sell tax), modify transaction and wallet size limits, en

UpgradesLow

8/10

The SPX token contract is not designed with an upgrade mechanism (e.g., proxy pattern) (7.7 Upgrades). This means the contract's logic is immutable once deployed, eliminating risks associated with upgradeability but also preventing any future bug fixes or feature enhancements without a full red

LP Distribution

LP Locked100.0% · Null Address, UNCX

Lock Expiry2092 (verified ≥ 1 year) · UNCX V2

What Raised This Score

4 factors

Top-10 concentration > 20% (31.0% total → 23.5% effective; 18.6% in EOAs, 12.5% in contracts — mild)
1 Critical finding(s) from audit
3 High finding(s) from audit
2 Medium 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 Findings

6 total

1 Critical 3 High 2 Medium

C-01CriticalUnresolved

Centralized Control and Honeypot Risk

The contract owner possesses absolute control over critical functions and parameters, including the ability to set arbitrary buy and sell taxes (e.g., initial 70% sell tax), enable/disable trading, add/remove addresses from a 'bots' blacklist, and modify maximum transaction/wallet size limits. This extreme centralization allows the owner to manipulate market conditions, restrict user transfers, and potentially execute a rug pull or create a honeypot scenario, where users can buy but cannot sell or are subject to prohibitive fees. This poses a severe risk to user funds and the protocol's integrity (7.3 Access Control, 7.4 Economic, 7.5 Governance, 7.8 Operations).

Recommendation: Implement a multi-signature wallet for critical administrative functions. Introduce time-locks for sensitive parameter changes (e.g., tax rates, max transaction limits) to provide transparency and allow users to react. Consider gradually decentralizing control or renouncing ownership of certain functions once the protocol is stable and mature. Clearly communicate the extent of owner privileges to users.

H-01HighUnresolved

High and Dynamic Tax Rates

The contract features extremely high initial tax rates (15% buy tax, 70% sell tax). Furthermore, the owner can modify all tax parameters (`_initialBuyTax`, `_initialSellTax`, `_finalBuyTax`, `_finalSellTax`, `_reduceBuyTaxAt`, `_reduceSellTaxAt`) at any time without notice. Such high and mutable taxes can severely deter legitimate trading, lead to significant loss of user funds, and be used to manipulate the token's economy, potentially trapping users in a position where selling is economically unfeasible (7.4 Economic).

Recommendation: Reduce initial tax rates to a more reasonable level to encourage trading. If dynamic taxes are necessary, implement a transparent governance mechanism or time-locks for changes. Consider capping the maximum allowable tax rate to prevent abusive settings. Clearly document all tax mechanisms and potential changes.

H-02HighUnresolved

Arbitrary Transfer Restrictions and Blacklisting

The owner has the ability to add/remove addresses from a `bots` mapping and enable/disable `transferDelayEnabled`. When enabled, `transferDelayEnabled` prevents transfers within a 1-minute window for non-excluded addresses. These features, while intended for anti-bot measures, can be abused by the owner to arbitrarily restrict legitimate users from transferring or selling their tokens, effectively blacklisting them or creating artificial liquidity issues (7.3 Access Control, 7.4 Economic).

Recommendation: Remove or significantly limit the owner's ability to blacklist addresses or impose transfer delays on legitimate users. If anti-bot measures are critical, implement them through more transparent and auditable mechanisms, or consider community-driven governance for such actions. Ensure that any restrictions are clearly communicated and justified.

H-03HighUnresolved

Manipulable Max Transaction and Wallet Size Limits

The owner can dynamically adjust `_maxTxAmount` and `_maxWalletSize` at any time. This capability can be exploited to prevent large buys or sells, or to effectively 'trap' tokens in user wallets by setting the maximum wallet size below a user's current balance, preventing them from receiving more tokens or even selling their existing holdings if the transaction limit is also set too low (7.4 Economic, 7.8 Operations).

Recommendation: Fix the `_maxTxAmount` and `_maxWalletSize` parameters after launch, or implement time-locks and multi-signature control for any changes. Ensure that these limits are set at reasonable levels that do not impede legitimate trading or trap user funds. Clearly disclose these limits and any potential for their modification.

M-01MediumUnresolved

Complex and Error-Prone Transfer Logic

The `_transfer` function is highly complex, incorporating numerous conditional checks for taxes, anti-bot measures, maximum transaction amounts, and wallet size limits. This intricate logic, while attempting to implement various features, increases the surface area for subtle logical errors, unexpected interactions between different conditions, and potential edge-case bugs that could lead to incorrect token transfers or unintended consequences (7.1 Architecture, 7.2 Code Security).

Recommendation: Refactor the `_transfer` function to reduce its complexity. Consider separating concerns into smaller, more manageable internal functions. Thoroughly test all possible execution paths and edge cases, especially interactions between tax calculations, anti-bot logic, and transfer limits. Prioritize clarity and simplicity over overly complex feature combinations within a single function.

M-02MediumUnresolved

`_preventSwapBefore` Mechanism

The `_preventSwapBefore` mechanism prevents the automatic liquidity swap (tax collection) for a specified number of initial buy transactions (`_buyCount`). While potentially intended to stabilize early trading, this can lead to an accumulation of tax tokens in the contract without being swapped to ETH, potentially causing a large, sudden swap later that could impact the token price. It also introduces an arbitrary restriction on the contract's normal operation (7.4 Economic, 7.8 Operations).

Recommendation: Re-evaluate the necessity and impact of the `_preventSwapBefore` mechanism. If it's deemed critical, ensure its behavior is well-understood and documented. Consider removing it to allow for consistent tax collection and liquidity management from the start, or implement a more predictable and transparent delay mechanism.

Frequently Asked Questions

Is SPX6900 a scam?

Based on the provided data, SPX6900 does not exhibit common technical characteristics of a scam. Its contract is verified, ownership is renounced, there's no mint function for arbitrary token creation, and liquidity is locked. These elements collectively indicate a strong foundation in terms of technical security and transparency, mitigating several typical 'rug pull' risks often seen in scam projects.

Is SPX6900 safe to buy?

SPX6900 presents several positive security attributes, including a verified contract, renounced ownership, no mint function, and locked liquidity, which address common technical risks. However, 'safety to buy' also encompasses market volatility, investor sentiment, and broader crypto market risks, none of which are covered by these technical security measures. Investors should consider the token's fundamentals, market dynamics, and their own risk tolerance before making investment decisions.

Has SPX6900 been audited?

The provided data confirms that the SPX6900 contract is 'verified,' meaning its source code is publicly available and matches the deployed bytecode on the Ethereum blockchain. This allows for transparency and public scrutiny. However, 'contract verified' is distinct from having undergone a formal, independent security audit by a specialized firm. The data does not explicitly state whether SPX6900 has completed such an audit.

Is SPX6900 Safe? SPX