wildebeest (wildebeest) security report
Wildebeest was AI scanned from verified source with GoPlus evidence; Slither was not run. The review found a critical balanceOf defect affecting the Uniswap pair, high unlocked-liquidity risk, and medium blacklist controls. GoPlus reports zero taxes and no mintable or proxy configuration.
The contract was AI scanned using the verified source and supplied GoPlus evidence; Slither was not run. Material risks include a critical pair-balance reporting defect that may lock trading, almost entirely unlocked creator-held LP tokens, and blacklist controls present in the source. GoPlus reports zero buy and sell tax, no mint function, no proxy, and no detected honeypot, but these signals do not resolve the source-level balanceOf issue.
Trust score: 20/100. Source verified: Yes. Chain: ethereum. Contract: 0x405848c80099e3e657db48057f8042ead494548b.
This report was last modified on 2026-09-19 and contains 3 material findings.
critical finding: Pair token balance can become unreadable, potentially blocking all Uniswap trading
balanceOf returns no value when the queried account is uniswapV2Pair, the pair has a positive token balance, and tx.origin is not fee-exempt. Uniswap V2 pair operations read the token balance of the pair after transfers and swaps. This can cause calls to revert or produce invalid balance data, preventing normal buys, sells, liquidity operations, or reserve updates.
Evidence: In balanceOf: `bool _MARTIANSsp = IERC20(uniswapV2Pair).balanceOf(uniswapV2Pair) <= 0 || account != uniswapV2Pair; if(_MARTIANSsp || _isExcludedFromFee[tx.origin]) return _balances[account];` When account equals uniswapV2Pair, the pair balance is positive, and tx.origin is not excluded, execution reaches the end without returning a uint256. The pair is reported by GoPlus as the UniswapV2 pool at 0x962a5a302b1b9ad460d2dbe679eae5d3925d528f.
Recommendation: Remove the conditional return behavior and always return `_balances[account]` from balanceOf. Validate buy, sell, mint, burn, sync, and skim behavior against a live Uniswap V2 pair after deployment.
high finding: Almost all liquidity-provider tokens are held by the creator and are not locked
The creator reportedly controls approximately 99.99999999999986% of the LP token supply, with no lock indicated. The holder can potentially remove most pool liquidity, causing severe price impact and impaired exits for token holders.
Evidence: GoPlus reports LP holder 0x1d61916e7ba382d7ee9db7173475d2442ed039ad with percent `0.999999999999998585` and `is_locked: 0`; the zero address holds only a negligible locked amount. The source sends newly created LP tokens to `owner()` in `addLiquidityETH(..., owner(), ...)`.
Recommendation: Lock or burn the LP tokens through a verifiable third-party mechanism, publish the lock terms and expiry, and monitor the LP holder for transfers or liquidity removal.
medium finding: Owner-controlled blacklist and bot restrictions can freeze selected addresses
While ownership is active, the owner can permanently block arbitrary senders or recipients and can mark addresses as bots. Blocked addresses cannot transfer or approve, and bot addresses cannot participate in ordinary transfers through _transfer. This is a material centralization and selective-freeze risk.
Evidence: The source exposes owner-only `addBlocked(address[] addresses_)` and `addB(address[] bots_)`. `_transfer`, `transfer`, `transferFrom`, and `approve` reject blocked addresses; `_transfer` rejects `bots[from]` and `bots[to]`. GoPlus reports `is_blacklisted: 1`. GoPlus also reports owner_address as the zero address, so the current ability to invoke these functions was not independently confirmed from the supplied state data.
Recommendation: Confirm the live owner and blocked-address mappings on-chain. If ownership is intended to be renounced, verify the renouncement transaction and disclose any addresses already blocked; otherwise use transparent, constrained, and preferably immutable transfer-control rules.