SuppostX Inu (SI) security report
Radar by SecureChain AI scanned the verified SuppostX Inu contract on Base. The fixed-supply ERC-20 has no detected minting, blacklist, pause, tax, or upgrade controls. Medium risks concern initial launcher custody and externally changeable metadata.
No Critical or High vulnerability was found in the supplied source. The main risks are centralized initial supply custody by the immutable launcher address and externally controlled token metadata through launcher.baseTokenURI(). Slither was not run, so this assessment is based on independent source review and supplied GoPlus signals.
Trust score: 86/100. Source verified: Yes. Chain: base. Contract: 0xc265edb97b653870de209cba291a7573efcd1b41.
This report was last modified on 2026-10-07 and contains 3 material findings.
medium finding: Entire fixed supply is initially assigned to the launcher
The constructor mints the complete token supply directly to launcher_, creating a centralized initial allocation and giving that address control over distribution and market-making decisions before any transfers occur.
Evidence: In StonkToken.constructor, the contract requires a nonzero launcher_ and executes _mint(launcher_, totalSupply_). The launcher address is immutable, and no vesting, allocation restriction, or distribution mechanism is implemented in this token contract.
Recommendation: Document the launcher allocation and distribution policy, and use an independently controlled distribution, vesting, or custody process if centralized initial control is not intended.
medium finding: External metadata dependency can fail silently
A failure in the launcher metadata call is caught and converted into an empty tokenURI response. Integrators that rely on tokenURI for display or classification may therefore receive no metadata without an on-chain error signal.
Evidence: The tokenURI() implementation wraps the external baseTokenURI() call in try/catch and returns "" in the catch branch; it also returns "" when the returned base string is empty.
Recommendation: Provide a documented fallback or immutable metadata path, and ensure consuming applications do not treat an empty tokenURI as proof that metadata is permanently unavailable or invalid.
medium finding: Token metadata depends on a mutable external launcher URI
tokenURI() does not store an immutable metadata base. Each call queries launcher.baseTokenURI(), so the launcher-side URI configuration can change the metadata endpoint or make metadata unavailable without changing this token contract.
Evidence: StonkToken.tokenURI() calls IStonkLauncherBaseURI(launcher).baseTokenURI(), concatenates the returned base with the token address and .json, and returns an empty string when the call fails or the base is unset. The source documentation states that the platform domain can be rotated through a launcher owner call.
Recommendation: Use an immutable or content-addressed metadata base when stable metadata is required, or clearly disclose the launcher governance and recovery controls for metadata changes and failures.