果蝇 (果蝇) security report
SecureChain AI scanned the verified 果蝇 contract source independently. GoPlus found no standard honeypot, mint, tax, proxy, or blacklist signals, but source review identified constructor-configured bytecode transfer blocking and opaque assembly executed on every transfer. GoPlus reports the creator holds 100% of supply. Slither was not run.
The contract is not an ordinary minimal ERC-20: its transfer path contains obfuscated bytecode-based blocking logic and a hidden state-writing modifier. The actual blocked addresses cannot be confirmed without the deployment constructor argument. The creator's reported 100% supply ownership is a material market and distribution risk. No direct public mint or owner-controlled fee mechanism was identified.
Trust score: 35/100. Source verified: Yes. Chain: bsc. Contract: 0xf0520b8aa43d8c4b47a5011d5b84a87ae4637777.
This report was last modified on 2026-09-30 and contains 3 material findings.
high finding: Constructor-configured bytecode blacklist can block transfers
Transfers revert when the recipient or the immediate caller has runtime bytecode matching any bytes value stored in the constructor-initialized mapping r_. This can selectively block routers, liquidity contracts, trading helpers, or other contract wallets. If a DEX pair or router bytecode was included in the constructor array, selling or routing through it may fail, creating a honeypot-like restriction.
Evidence: In ERC20._transfer, `if (r_[to.code] || r_[msg.sender.code]) { revert(); }` rejects transfers based on complete runtime bytecode. In the ERC20 constructor, every supplied `bytes` element is recorded with `r_[_i[i]] = true`. The ABI exposes the constructor parameter as `bytes[] fee`, but the supplied material does not include the deployed constructor values.
Recommendation: Decode and independently verify the deployment transaction constructor argument, then test transfer, buy, sell, router, pair, and contract-wallet paths against the deployed state. Remove bytecode-based blocking logic or replace it with transparent, auditable rules and explicit events.
medium finding: All transfers execute obfuscated tx.origin-dependent storage mutation
Every successful transfer calls a private function whose uint304 modifier performs inline assembly, compares constants against tx.origin, and writes a value to a storage slot derived from runtime memory. This is not standard ERC-20 behavior, is difficult to audit, and introduces hidden state mutation and gas overhead into every transfer. A direct storage collision cannot be proven from the supplied data, so the impact remains conditional.
Evidence: ERC20._transfer unconditionally invokes `r(to)` after the bytecode checks. The private function `r(address r_)` uses modifier `uint304`, which reads `origin()`, executes multiple inline-assembly memory operations, and performs `sstore(keccak256(add(r, 0x40), 0x40), mload(add(r, 0x40)))`. No public explanation or event exists for this write.
Recommendation: Remove the modifier and private assembly routine unless its exact storage slot, value, and purpose are formally documented and verified. Confirm through tracing that the written slot cannot overlap balances, allowances, ownership, or other protocol state.
medium finding: Creator reportedly controls the entire token supply
The reported creator balance is 1,000,000,000 tokens, or 100% of total supply. This concentration allows the creator to create severe sell pressure, control circulating supply, and materially affect market price if the tokens are transferred or sold. The contract itself has no public mint function, but initial allocation concentration remains a major business and market risk.
Evidence: GoPlus evidence reports `creator_balance` as `1000000000`, `creator_percent` as `1.000000`, and `total_supply` as `1000000000`. The source constructor mints the entire 1e27 base-unit supply to `_msgSender()` before the token constructor renounces ownership.
Recommendation: Treat the token as highly concentrated until distribution changes are confirmed.