Stupid inu stonks ($sis) security report
SecureChain AI scanned the verified BSC source for Stupid inu stonks. GoPlus reports no honeypot, minting, blacklist, proxy, or adjustable-tax behavior. Medium risks include external tax and dividend dependencies, conditional migration-based trading restrictions, concentrated unlocked holders, and inconsistent liquidity reporting. Slither was not run.
The contract was AI scanned using its verified Solidity source and supplied GoPlus evidence; Slither was skipped. No critical or high finding was confirmed, but medium-risk business-logic and centralization concerns require monitoring. GoPlus reports is_honeypot=0, is_mintable=0, is_blacklisted=0, is_proxy=0, and owner_address=0x0000000000000000000000000000000000000000.
Trust score: 52/100. Source verified: Yes. Chain: bsc. Contract: 0x89382354c013131c60fadb6dcfa11d7637e07777.
This report was last modified on 2026-09-19 and contains 5 material findings.
medium finding: External tax processor can receive accumulated tax tokens after processing failure
Tax liquidation delegates control of collected tax tokens to the configured taxProcessor. If processTaxTokens reverts, the catch branch transfers the entire token balance held by the token contract to taxProcessor, not only the current liquidation amount. A compromised, malicious, or incorrectly configured processor could deliberately revert and take custody of accumulated tax tokens.
Evidence: In _processTax(), ITaxProcessor(taxProcessor).processTaxTokens(taxAmount) is wrapped in try/catch. The catch branch executes _plainTransfer(address(this), taxProcessor, remainingBalance) for balanceOf(address(this)). taxProcessor is supplied during initialize() and there is no setter to replace or revoke it.
Recommendation: Use a vetted immutable or governance-controlled processor, limit the fallback transfer to the current tax amount, and add an explicit recovery process with transparent recipient controls. Monitor processor code and allowance activity.
medium finding: Configured dividend contract can block token transfers
Every non-pool transfer can invoke the configured dividend contract twice through setShare. If either callback reverts, the token transfer reverts through DividendShareUpdateFailed. A faulty, paused, malicious, or incompatible dividend contract can therefore prevent holders from transferring or selling tokens, subject to the dividend contract being configured and active.
Evidence: _afterTokenTransfer() calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) inside try/catch blocks that explicitly revert on failure. dividendContract is assigned in initialize() and cannot be changed by a public setter.
Recommendation: Consider making dividend accounting non-blocking, using failure isolation or queued updates, and provide a tested emergency disable mechanism before deployment. Verify the configured dividend implementation and its access controls.
medium finding: Owner-dependent migration can conditionally lock pool trading
While poolState is BondingCurve, transfers involving any configured pool revert. Only the owner can move the contract through startMigration() and finalizeMigration(). If the owner is unavailable or migration is not completed, pool trading can remain blocked. GoPlus reports the owner address as zero, so this is especially important if the deployed instance is still in BondingCurve; the supplied evidence does not include the current pool state.
Evidence: _transfer() requires !pools[from] && !pools[to] in PoolState.BondingCurve. startMigration() and finalizeMigration() are both onlyOwner. GoPlus reports owner_address=0x0000000000000000000000000000000000000000, while the ABI exposes the owner-controlled migration functions.
Recommendation: Verify the live state() and migration events. Ensure deployment atomically initializes and completes the intended migration, or replace owner-gated migration with a permissionless, safely bounded transition once prerequisites are met.
medium finding: Highly concentrated token distribution creates material holder-dump risk
GoPlus reports that a contract holder owns approximately 31.15% of supply, the creator holds approximately 19.13%, and several additional wallets hold 13.00%, 13.00%, and 12.32%. These balances create substantial market-impact and liquidity-exhaustion risk even though no direct privileged mint function was identified.
Evidence: GoPlus holder data lists 0xe2ce6ab80874fa9fa2aae65d277dd6b8e65c9de0 at 31.1494%, creator 0xcab397d10543c990fdecb66a9485c9bd90612640 at 19.1280%, and three other major holders at 13.0000%, 13.0000%, and 12.3238%. The listed holdings are not locked.
Recommendation: Disclose holder identities and vesting arrangements, lock or transparently manage material allocations, and monitor large-holder transfers and liquidity depth before treating the token as low risk.
medium finding: Liquidity evidence is inconsistent and may indicate limited exit depth
The project metadata reports approximately $26,027.71 liquidity, while GoPlus lists the PancakeV2 pair liquidity as 0.00000000 and lp_holder_count as 0. This inconsistency prevents reliable assessment of available exit liquidity and warrants direct on-chain verification.
Evidence: Project data states liquidityUsd=26027.71. GoPlus reports the PancakeV2 pair 0x0fdec116693684659f6f7e6729a4dee1f9668920 with liquidity=0.00000000 and lp_holder_count=0.
Recommendation: Verify the pair reserves, LP token ownership, and lock status directly on BSC. Treat the lower or unverified liquidity figure as the conservative assumption until the discrepancy is resolved.