Radar by SecureChain AI

Super Intelligence (SI) security report

SecureChain AI scanned the verified Super Intelligence SI contract independently and reviewed GoPlus evidence. No Critical or High issue was established. Medium risks include centralized tax-wallet withdrawals, broad transfer-tax logic, and an owner-controlled blacklist design. Slither was not run.

No Critical or High vulnerability was established from the supplied source and GoPlus evidence. Medium-risk control and business-logic issues remain: the tax wallet can withdraw contract-held ETH and ERC20 assets, and the contract's tax logic can charge ordinary wallet-to-wallet transfers when the configured final tax is nonzero. Slither was skipped, so this is not a completed static-analysis result and does not guarantee safety.

Trust score: 72/100. Source verified: Yes. Chain: ethereum. Contract: 0xa5b388d516b45962b2256171d65ab9517260d2a6.

This report was last modified on 2026-09-30 and contains 3 material findings.

medium finding: Tax wallet has unilateral control over contract-held ETH and ERC20 assets

The constructor permanently assigns _taxWallet to the deployer, and this address is separate from Ownable ownership. The tax wallet can call manualSwap, manualSend, and rescueERC20 without owner authorization.

Evidence: manualSwap requires _msgSender() == _taxWallet, swaps the entire token balance of address(this), and forwards all resulting ETH to _taxWallet. manualSend forwards all contract ETH to _taxWallet. rescueERC20 transfers the entire balance of an arbitrary tokenAddress from the contract to _taxWallet. The GoPlus evidence identifies the creator as 0xe9657afca6ad9b0af6d400b2725baa656cc0feb7, while owner_address is zero; ownership renunciation does not revoke the separate tax-wallet authority.

Recommendation: Use a timelocked, multisignature fee recipient and restrict rescue functions to a narrowly defined recovery process. Exclude LP tokens and the project token from generic rescueERC20, or require governance approval and emit explicit recovery events.

medium finding: Nonzero tax logic applies to ordinary wallet transfers

The transfer implementation calculates tax for every transfer where neither party is the owner, before checking whether the transaction is a buy or sell. Therefore, while the configured buy or sell tax is nonzero, ordinary wallet-to-wallet transfers can lose the same tax amount to the contract. This is a material transfer-behavior risk even though GoPlus reports current buy and sell tax as zero.

Evidence: In _transfer, when from != owner() and to != owner(), taxAmount is initially calculated from _initialBuyTax or _finalBuyTax. The buy and sell branches only replace that value when interacting with uniswapV2Pair; no condition limits the initial calculation to DEX buys. The source sets initial buy and sell taxes to 18 and final taxes to 0.

Recommendation: Calculate tax only inside explicit buy and sell branches, or document and independently expose the intended transfer-tax policy. Add tests covering wallet-to-wallet transfers before and after tax reductions.

medium finding: Owner-controlled blacklist can block transfers while ownership remains active

The source includes a bots mapping checked for both sender and recipient. An owner can add arbitrary addresses to this mapping, causing transfers involving those addresses to revert. GoPlus reports no current blacklist state and owner_address as the zero address, so the supplied evidence indicates this control is not presently exercisable through the owner; the risk concerns the deployed design and any period before renunciation.

Evidence: _transfer requires !bots[from] && !bots[to]. addBots and delBots are onlyOwner functions, and isBlackListed90854900525039 exposes the status under a nonstandard blacklist-like name. GoPlus reports is_blacklisted 0 and owner_address 0x0000000000000000000000000000000000000000.

Recommendation: Remove blacklist functionality where it is not essential, or enforce transparent governance, event logging, bounded use, and an auditable appeal or expiry mechanism. Verify historical ownership and blacklist events before relying on current owner renunciation.