Goatseus (GOATSEUS) security report
Radar by SecureChain AI scanned the verified Goatseus contract on Ethereum. The token has no visible privileged mint or blacklist controls, but the deployer receives the full supply and the documented tribute and hook mechanics are not implemented in token transfers.
The token contract is a minimal fixed-supply ERC-20 with no privileged administration or transfer restrictions. However, the deployer receives the entire supply at construction, and the advertised tribute, buyback, liquidity, holder-reward, and hook behavior is not implemented in or called by the token contract.
Trust score: 72/100. Source verified: Yes. Chain: ethereum. Contract: 0xb8addaf1123496d9b4411dfb4ac7c063f456402b.
This report was last modified on 2026-10-07 and contains 2 material findings.
medium finding: Advertised tribute and hook mechanics are not wired into token transfers
The source comments describe trade tribute, buyback-and-burn, liquidity additions, holder rewards, and Uniswap v4-style hooks, but the deployed token implementation only moves balances and emits Transfer events. The imported Annals, Edicts, Tribute, Legion, and Salarium sources are not instantiated or called by Goatseus.sol.
Evidence: Goatseus.sol imports the auxiliary contracts but defines its own storage and transfer path. _send only checks the sender balance, subtracts from _bal[from], adds to _bal[to], and emits Transfer. transfer and transferFrom call _send directly; neither applies a fee, calls Tribute, checks Legion, or invokes any hook.
Recommendation: Align documentation with the deployed bytecode, or implement and separately verify the intended integrations. Add tests proving fee collection, destination accounting, hook invocation, and failure behavior if these mechanics are required by the project design.
medium finding: Entire fixed supply is assigned to the deployer
The constructor places the full fixed supply in msg.sender. The contract provides no vesting, distribution, or protocol-level restriction on that balance, so the deployer can transfer the entire allocation through the ordinary ERC-20 transfer function.
Evidence: Goatseus.sol defines _SUPPLY as 1000000000 * 10**18 and the constructor executes _supply = _SUPPLY; _bal[msg.sender] = _SUPPLY;. The transfer function allows msg.sender to call _send(msg.sender, to, value) without any additional lock, vesting, or allocation control.
Recommendation: Document the initial allocation and distribution assumptions clearly. If concentration creates unacceptable control or sell-pressure risk, use a verifiable vesting, multisignature distribution, or time-lock design before deployment; do not rely on comments to establish those controls.