wildebeest (WILDEBEEST) security report
SecureChain.ai independently AI-scanned the verified WILDEBEEST contract. The material finding is a high-risk tx.origin-based allowance bypass that lets the deployer-linked tax wallet move arbitrary holder balances. GoPlus found no minting, blacklist, proxy, pause, or configured tax indicators. Slither was skipped, and the scan is not a guarantee of safety.
The contract has a high-severity centralized token-drain capability. The tax wallet, set permanently to the constructor caller, can use transferFrom to move tokens from any address without requiring or consuming an allowance. Slither was skipped, so no Slither results are available; this conclusion comes from independent source review and supplied GoPlus evidence.
Trust score: 35/100. Source verified: Yes. Chain: ethereum. Contract: 0xfc211056d5aeb071836a81f7c17d3d3844bc6c7b.
This report was last modified on 2026-09-19 and contains 4 material findings.
high finding: Tax wallet can bypass allowances and drain arbitrary token balances
transferFrom performs the token transfer before conditionally reducing the allowance. The allowance reduction is skipped whenever tx.origin equals the private _taxWallet address. Because _transfer does not independently verify that the caller is approved, a transaction initiated by the tax wallet can specify any sender and recipient and move the sender's balance without an allowance.
Evidence: In transferFrom, _transfer(sender, recipient, amount) is followed by `if (_taxWILDEBEESTR2ZHP0Z2JQ9Payer() != _taxWallet) _approve(...)`. The payer function returns `origin()` through assembly, while _taxWallet is assigned to _msgSender() in the constructor. _transfer only subtracts from _balances[sender] and does not check msg.sender authorization. GoPlus reports owner_address as the zero address, but this does not clear or change the private _taxWallet value.
Recommendation: Remove all tx.origin-based authorization and always enforce and decrement allowances in transferFrom. If an administrative recovery role is genuinely required, use an explicit, transparent, narrowly scoped role with documented limits and event logging; otherwise redeploy with the vulnerable logic removed. Existing holders should treat the tax-wallet key as a privileged drain key until the token is replaced or the behavior is otherwise verifiably eliminated.
medium finding: Permanent deployer-linked privileged identity remains after ownership renunciation
The contract separates Ownable ownership from _taxWallet. Renouncing ownership sets only _owner to address(0); it does not clear _taxWallet. Consequently, the deployer-linked address retains the allowance-bypass capability in transferFrom even when the public owner() function reports no owner.
Evidence: Ownable.renounceOwnership sets `_owner = address(0)` only. The constructor independently sets `_taxWallet = payable(_msgSender())`, and transferFrom compares the transaction origin against that stored address. GoPlus reports owner_address as the zero address, while creator_address is 0x3603dfea2c19e83f242f7450e6de00e3ad8b0168, demonstrating why owner renunciation does not by itself remove the separate privilege.
Recommendation: Do not describe ownership renunciation as full privilege removal while _taxWallet remains active. Remove the tax-wallet exception and redeploy or migrate holders to code with standard ERC-20 allowance enforcement. Verify the actual historical owner and tax-wallet values on-chain before relying on renunciation.
medium finding: Owner-controlled liquidity initialization and asset rescue create custodial control risk
Before ownership is renounced, the owner can initialize trading and direct all contract ETH and token liquidity through the Uniswap router, and can rescue arbitrary ERC-20 tokens or all ETH to _taxWallet. These powers can materially affect liquidity and recoverable assets, although the supplied GoPlus data reports owner_address as zero, so current exploitability of onlyOwner functions is not established from the supplied evidence.
Evidence: enableTrading is onlyOwner and calls addLiquidityETH with all contract ETH and token balance, sending LP tokens to owner(). rescueWILDEBEESTR2ZHP0Z2JQ9ERC20 transfers a percentage of any token balance to _taxWallet, and rescueWILDEBEESTR2ZHP0Z2JQ9Eth transfers the entire ETH balance there. GoPlus reports owner_address as 0x0000000000000000000000000000000000000000; the source review cannot independently establish whether ownership was renounced before or after liquidity setup.
Recommendation: Document the owner and liquidity lifecycle with on-chain evidence. If ownership is intentionally renounced, confirm all initialization is complete and that no replacement admin exists. Avoid unrestricted rescue functions in future deployments, or constrain them to unrelated assets, timelocks, multisignature approval, and transparent events.
medium finding: Liquidity lock evidence is incomplete despite GoPlus reporting a predominantly locked LP position
GoPlus reports approximately 99.99999999999983% of LP tokens at the dead address and identifies the LP position as locked, which is favorable. However, the supplied evidence also reports only two LP holders and an LP total supply of approximately 0.588464150140006404, while the source sends LP tokens to owner() during initialization. This discrepancy makes the complete liquidity ownership and lock state a material verification risk rather than proof of a vulnerability.
Evidence: GoPlus lp_holders lists the dead address with value 25425.579911302629441418 and percent 0.999999999999998300, while the source's enableTrading sends the returned liquidity tokens to owner(). The report does not include the pair's full holder distribution, lock contract details, or event history linking the initial owner-held LP to the dead address.
Recommendation: Verify the Uniswap pair address, total LP supply, all LP holders, transfer events, and any lock or burn transaction directly on Ethereum. Confirm that no meaningful LP balance remains controllable by the deployer or another address.