Is SPX6900 (SPX) Safe? Smart Contract Security Analysis

Security Findings

1 Crit3 High2 Med

Critical

Centralized Control and Honeypot Risk

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

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

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

StatusUnresolved

High

High and Dynamic Tax Rates

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

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

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

StatusUnresolved

High

Arbitrary Transfer Restrictions and Blacklisting

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

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

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

StatusUnresolved

High

Manipulable Max Transaction and Wallet Size Limits

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

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

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

StatusUnresolved

Medium

Complex and Error-Prone Transfer Logic

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

IssueThe `_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).

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

StatusUnresolved

Medium

`_preventSwapBefore` Mechanism

M-02The `_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).

IssueThe `_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).

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

StatusUnresolved

Category Ratings

TechnicalMedium5/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, anti-bot measures, and transaction limits, significantly increases its complexity and the potential for subtle logical errors (7.1 Architecture, 7.2 Code Security).

GovernanceLow7/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, enable/disable trading, and blacklist addresses. This level of centralization creates a severe risk of a rug pull or honeypot, where the owner could manipulate market conditions to their advantage, potentially trapping user funds.

UpgradesLow8/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 redeployment and migration.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

31.0% in top 10

19.0% in wallets12.0% in contracts

Effective Concentration23.8%

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

$14.49M across 12 pairs

Uniswap v2WETHanalysed$14.04M Uniswap v4ETH$257.1K Uniswap v3WETH$177.6K Uniswap v3USDC$5.4K Uniswap v4ZIK$1.4K Uniswap v3WETH$1.1K

Show 4 more pairsShow less

Uniswap v4ETH$1.0K Uniswap v4ETH$816 SupernovaWETH$525 0x95D9…1C13WETH$173

The 2 remaining pairs hold $129 between them and are not listed.

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

LP Locked100.0% · UNCX

Lock Expiry2092 (verified ≥ 1 year) · UNCX V2

Key Addresses

10 addresses

Deployer

0xeda4…b995

Unlocked LP Held By

0x15fd…9c7e0xa14a…eee70x76d2…b8a80xb3ac…68a00x826f…1e650x557a…44420x0000…8a900x1f2f…f3870x87c0…36d6

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

What Raised This Score

4 factors

Top-10 concentration > 20% (31.0% total → 23.8% effective; 19.0% in EOAs, 12.0% 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

Final Recommendation

AI Copilot

Users should exercise extreme caution when interacting with this token due to the extensive centralized control held by the contract owner.…

Read the verdictHide

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.

Contract

TypeRouter, Token

Audit History

1 audit on record

Jul 2336

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

Not Signed In

Is SPX6900 Safe?

Security Findings

Centralized Control and Honeypot Risk

High and Dynamic Tax Rates

Arbitrary Transfer Restrictions and Blacklisting

Manipulable Max Transaction and Wallet Size Limits

Complex and Error-Prone Transfer Logic

`_preventSwapBefore` Mechanism

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of SPX6900?