wildebeest (wildebeest) security report
Wildebeest was AI scanned using verified Solidity source and GoPlus evidence. No public minting, proxy, blacklist, transfer tax, or clear honeypot path was identified. The main material risk is centralized transfer control: trenchManager can restrict transfers, and the token initially operates in manager-controlled mode. Slither was not run.
The contract is not currently shown to have minting, fee manipulation, blacklist, proxy, or honeypot behavior. However, trenchManager has centralized control over transfer availability and can set the token to a restricted mode that reverts every transfer. The supplied evidence does not include the current on-chain _mode value, so the live status of this control requires verification.
Trust score: 58/100. Source verified: Yes. Chain: ethereum. Contract: 0x57737ded3870e43fed7d80d31e0ced3d5fb0cccc.
This report was last modified on 2026-09-19 and contains 3 material findings.
high finding: Privileged manager can freeze all token transfers
The trenchManager can call setMode and select MODE_TRANSFER_RESTRICTED. In that mode, _beforeTokenTransfer reverts every transfer, mint, or burn operation, preventing holders from transferring or selling tokens until the mode is changed.
Evidence: Token3.sol defines MODE_TRANSFER_RESTRICTED = 1. _beforeTokenTransfer reverts with ERR_TOKEN_TRANSFER_RESTRICTED whenever _mode equals that value. setMode is callable by trenchManager and changes _mode whenever the existing mode is non-normal. The constructor initializes _mode to MODE_TRANSFER_CONTROLLED, so the manager can exercise this authority from deployment. GoPlus reports transfer_pausable=0, but that automated signal does not reflect the source-level manager-controlled mode mechanism.
Recommendation: Use an immutable or governance-controlled transfer policy, constrain setMode to an explicit lifecycle with timelocks and events, and document the manager's ability to pause transfers. Verify the current _mode on-chain and monitor all setMode calls.
medium finding: Transfers are initially restricted to the trench manager
At deployment, the token does not behave as a freely transferable ERC-20. MODE_TRANSFER_CONTROLLED requires every transfer to either originate from or terminate at trenchManager, which can block ordinary wallet-to-wallet transfers and secondary-market activity until the manager changes the mode.
Evidence: The constructor sets _mode = MODE_TRANSFER_CONTROLLED after minting the entire 1e27 supply to trenchManager. _beforeTokenTransfer requires from == trenchManager || to == trenchManager while that mode is active. GoPlus shows the token is in a DEX and reports cannot_buy=0 and cannot_sell_all=0, but the supplied data does not include the current _mode value or prove that unrestricted mode is active.
Recommendation: Confirm the deployed _mode and publish the intended transfer-state lifecycle. If unrestricted transfers are intended, transition through a transparent, irreversible governance process rather than relying on a privileged manager call.
medium finding: Initial token supply is fully centralized in trenchManager
The constructor mints the full fixed supply to trenchManager, giving that address custody and operational control over the entire initial supply. This creates material concentration and distribution risk even though no public mint function is present.
Evidence: Token3.sol calls _mint(trenchManager, TOTAL_SUPPLY), where TOTAL_SUPPLY is 1e27. GoPlus reports total_supply=1000000000 and identifies two contract holders accounting for 100% of the reported supply, while the creator holds only approximately 0.000132%. The source does not expose a public mint function, but the manager receives the complete initial allocation.
Recommendation: Disclose the trenchManager address, allocation and distribution controls; use transparent vesting or timelocked distribution where appropriate; and monitor large transfers from the manager-controlled contracts.