SpaceXS (SpaceXS) security report
Radar AI scanned SpaceXS on BNB Smart Chain and found material transfer-path risks, including constructor-controlled bytecode filtering, hardcoded origin blocking, and obfuscated storage writes. Slither was not run.
SpaceXS is not free of material contract-level risks. The source includes conditional honeypot-like transfer restrictions and hardcoded origin-based blocking. Ownership is renounced and GoPlus reports no minting, proxy, blacklist, or tax controls, but those signals do not remove the risks embedded in the transfer implementation.
Trust score: 25/100. Source verified: Yes. Chain: bsc. Contract: 0xbc065daed7313f363ec275182ea92540da9b7777.
This report was last modified on 2026-10-07 and contains 3 material findings.
high finding: Constructor-controlled bytecode filter can block selected contracts and trading routes
The token stores three arbitrary bytes values supplied through the constructor in the spoon mapping. Every transfer reverts when either the recipient's runtime bytecode or msg.sender's runtime bytecode matches one of those values. If a constructor value matches a router, pair, or other required contract bytecode, transfers involving that contract can be blocked, creating a conditional honeypot-like or trading-lock path.
Evidence: In ERC20's constructor, spoon[amount[0]], spoon[amount[1]], and spoon[amount[2]] are set from the deployer's bytes[] input. In _transfer, the contract executes `if (spoon[to.code] || spoon[msg.sender.code]) { revert(); }`. The supplied ABI exposes the constructor as bytes[] fee, while the actual constructor values were not supplied for independent verification of which bytecodes were selected.
Recommendation: Decode and independently verify the deployed constructor arguments, compare all three stored bytecode values with the runtime bytecode of the PancakeSwap pair, router, token-supporting contracts, and common transfer destinations, and remove bytecode-based transfer filtering in a remediation deployment.
medium finding: Two hardcoded transaction origins are permanently blocked from transfers
The custom ETHY modifier runs before every _transfer and invokes invalid() when tx.origin equals either of two embedded hardcoded addresses. Any transfer initiated through either origin reverts, regardless of allowance or balance. This is a covert, irreversible address-specific transfer restriction and uses tx.origin rather than an explicit, auditable blacklist.
Evidence: The _transfer function is declared with the `r(to,1)` modifier. That modifier contains two checks of the form `if eq(div(..., 7), origin()) { invalid() }`, using fixed large integer constants. A matching tx.origin therefore causes the transfer transaction to fail before ERC20 balance updates execute.
Recommendation: Remove the obfuscated ETHY modifier and all tx.origin-based transfer decisions. If address restrictions are required, use an explicit, documented policy with auditable storage, events, access controls, and clearly defined recovery procedures.
medium finding: Obfuscated inline assembly executes a hidden storage write on every transfer
The transfer modifier performs an undocumented sstore to a computed storage slot before normal token accounting. Although the computed slot is not shown to intentionally overlap a known balance or allowance slot, this hidden state mutation increases auditability and storage-integrity risk and includes explicit invalid-opcode branches.
Evidence: Modifier r allocates memory, hashes transfer-related data, and executes `sstore(keccak256(add(s, 0x40), 0x40), mload(add(s, 0x40)))` before continuing to _transfer. The same modifier contains the two tx.origin invalid() checks. No documented contract feature requires this assembly behavior.
Recommendation: Remove the modifier and replace it with conventional Solidity transfer logic. If any state update is necessary, use named storage variables, documented invariants, events where appropriate, and targeted tests proving no collision with balances, allowances, ownership, or other state.