果蝇 (果蝇) security report
Radar by SecureChain.ai AI-scanned the verified 果蝇 contract on BSC. GoPlus found no detected honeypot, proxy, minting, or taxes, but source review identified a permanent constructor-configured code-hash transfer restriction, unusual assembly storage writes, and full initial supply concentration in the creator. Slither was not run.
The token is verified and was AI scanned, but it presents material risk. The constructor can permanently block transfers involving selected contract code hashes, and the deployer initially receives 100% of the supply. GoPlus reports no active blacklist, taxes, proxy, or mint function, but those signals do not remove the source-level restriction or concentration risks.
Trust score: 38/100. Source verified: Yes. Chain: bsc. Contract: 0xf0520b8aa43d8c4b47a5011d5b84a87ae4637777.
This report was last modified on 2026-09-19 and contains 3 material findings.
high finding: Constructor-configured code-hash transfer blacklist can permanently restrict trading
The token stores constructor-supplied byte strings in r_. Every transfer reverts when either the recipient's runtime bytecode hash or msg.sender's runtime bytecode hash is present in that mapping. Because r_ is populated only during construction and has no removal function, any selected contract code hash is permanently blocked for the lifetime of the token. This can prevent transfers to or from a DEX pair, router, contract wallet, or other targeted contract.
Evidence: In ERC20's constructor, `for (uint256 i; i < _i.length; ++i) { r_[_i[i]] = true; }`. In `_transfer`, `if (r_[to.code] || r_[msg.sender.code]) { revert(); }`. The supplied ABI exposes the deployment constructor as `constructor(bytes[] fee)`, and the source provides no setter or clearing function for r_. The actual constructor array values were not supplied, so the presence of a currently targeted hash cannot be confirmed from the available evidence.
Recommendation: Decode and independently verify the deployed constructor arguments and compare every stored hash against the runtime bytecode hashes of the liquidity pair, routers, and commonly used token-handling contracts. Treat any match as a permanent transfer restriction. Do not rely solely on GoPlus's `is_blacklisted: 0`, because that signal does not establish that this constructor-seeded code-hash mechanism is empty or harmless.
medium finding: Entire initial supply is concentrated in the deployer address
The contract mints the full 1e27 base-unit supply to msg.sender during construction. The supplied GoPlus evidence reports creator_balance equal to total supply and creator_percent equal to 1.000000. A single deployer-controlled address can therefore sell or transfer the complete supply, creating severe dilution, price-impact, and liquidity-drain risk even though the owner role is subsequently renounced.
Evidence: The ERC20 constructor executes `_mint(_msgSender(), 1e27)`. GoPlus reports `creator_balance: 1000000000`, `creator_percent: 1.000000`, and `owner_address: 0x0000000000000000000000000000000000000000`. Reported liquidity is approximately $31,077.06, which may be small relative to a full-supply disposal.
Recommendation: Verify current holder balances and deployer transfers on-chain, including whether the deployer retains or has distributed the supply. Review liquidity ownership and lock status, and model the market impact of large holder sales before treating the token as investable.
medium finding: Obfuscated storage write executes on every transfer
Every successful transfer calls the private function r(to), which applies the uint304 modifier. That modifier performs an inline-assembly sstore to a keccak-derived storage slot using constants, the transfer target, and tx.origin-derived data. This is outside normal ERC-20 behavior and creates an unreviewed persistent storage side effect on every transfer. The supplied source does not establish a direct theft path, but the unusual write materially increases storage-corruption and compatibility risk and warrants bytecode-level validation.
Evidence: `_transfer` calls `r(to)` before `_update`. The private function is declared `function r(address r_) private uint304(r_){}`. The modifier contains `sstore(keccak256(add(r,0x40), 0x40), mload(add(r,0x40)))` and uses `origin()` in the calculation. No documented business purpose or read path for this storage write is provided.
Recommendation: Reproduce the deployed bytecode and trace storage changes across transfers. Prove that the calculated slots cannot overlap ERC-20 balances, allowances, supply, ownership, or other protocol state. Remove the assembly side effect unless it is required, documented, and independently audited.