SpaceXSI (SpaceXSI) security report
Radar by SecureChain AI scanned the verified SpaceXSI contract on BNB Smart Chain. Material findings involve tax processor custody, transfer availability, and owner-controlled pool-state transitions.
The contract does not expose post-initialization minting or an upgrade function in the supplied source, but it relies on privileged and external components that can drain tax-held tokens, block transfers, or control when pool trading restrictions and taxation change.
Trust score: 52/100. Source verified: Yes. Chain: bsc. Contract: 0xf36a8e18890e4b61dd85b5ce37fe271ee2da7777.
This report was last modified on 2026-10-07 and contains 4 material findings.
high finding: Configured tax processor receives unlimited token allowance and can drain contract-held tokens
After the first tax liquidation, the token approves the configured taxProcessor for type(uint256).max. That external address can then call transferFrom against the token contract and move its entire token balance without a dedicated withdrawal limit or revocation path in this contract.
Evidence: In _processTax(), the contract executes _approve(address(this), taxProcessor, type(uint256).max) when the allowance is insufficient. The allowance remains active, and taxProcessor is stored during initialize() with no setter or cap on later transferFrom usage.
Recommendation: Use exact per-liquidation approvals, revoke the allowance after processing, or replace allowance-based custody with a tightly scoped pull mechanism. Validate and govern the taxProcessor address before initialization and monitor allowance changes.
high finding: Tax-processing failure can sweep the full token-contract balance to the tax processor
If the external tax processor call fails, the fallback transfers the entire token balance held by the token contract to taxProcessor, not only the current taxAmount. This can include previously accumulated taxes or tokens sent to the contract for another purpose.
Evidence: The catch block in _processTax() reads balanceOf(address(this)) into remainingBalance and calls _plainTransfer(address(this), taxProcessor, remainingBalance). The external processTaxTokens() call is made through an untrusted configurable contract interface and can revert.
Recommendation: Limit fallback transfers to the current taxAmount, isolate unrelated balances, and avoid automatic sweeping on arbitrary external-call failure. Add explicit recovery controls with timelocks and transparent accounting.
medium finding: External dividend callback can block ordinary token transfers
When dividendContract is configured, transfers invoke setShare() for eligible sender and recipient addresses. Any revert from that external contract causes the entire token transfer to revert, creating a transfer-lock condition if the dividend contract is unavailable, misconfigured, or intentionally rejects updates.
Evidence: _afterTokenTransfer() calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) inside try/catch blocks, then reverts with DividendShareUpdateFailed when either call fails. dividendContract is supplied during initialize() and has no update or disable function afterward.
Recommendation: Do not make core ERC20 transfers depend on a revertible external callback. Queue share updates, make failures non-blocking, or provide a governed emergency disable and replacement mechanism.
medium finding: Owner controls migration timing and can preserve pool restrictions or postpone taxation
The owner alone controls transitions out of BondingCurve and Migrating states. While BondingCurve is active, transfers to or from every configured pool revert; while Migrating is active, transfers are unrestricted and untaxed. The source does not enforce a deadline or automatic transition.
Evidence: startMigration() and finalizeMigration() are onlyOwner. In _transfer(), BondingCurve requires !pools[from] && !pools[to], while Migrating performs a plain transfer without tax. The owner can leave the contract in either state indefinitely.
Recommendation: Use immutable or time-bounded launch-state transitions, publish the configured pool and migration schedule, and apply governance controls or timelocks to state changes.