破茧成蝶 (破茧成蝶) security report
Radar AI scanned the verified 破茧成蝶 token source on BNB Smart Chain. Findings include a constructor-configured code-based transfer restriction and obfuscated assembly storage writes. Slither was not run.
The contract has material medium-severity risks. Transfers can be silently blocked for addresses whose runtime bytecode matches any of three constructor-supplied byte arrays, and every transfer executes opaque assembly that performs an arbitrary dynamic storage write. The transfer restriction is conditional on the unknown constructor arguments, so the source proves the mechanism but not whether a particular router or pair was targeted.
Trust score: 35/100. Source verified: Yes. Chain: bsc. Contract: 0x400161e35c38480393aacadb806fb0ae02de7777.
This report was last modified on 2026-10-10 and contains 2 material findings.
medium finding: Hidden code-based transfer restriction configured at deployment
The token maintains a private bytes-to-bool mapping named breaker and initializes three entries from constructor-supplied fee values. Every transfer reverts when the recipient's runtime bytecode or the caller's runtime bytecode exactly matches one of those entries. This acts as an undisclosed contract-address restriction and can block transfers involving selected contracts.
Evidence: In ERC20's constructor, breaker[amount[0]], breaker[amount[1]], and breaker[amount[2]] are set to true. In _transfer, the condition `if (breaker[to.code] || breaker[msg.sender.code]) { revert(); }` rejects transfers based on the full runtime bytecode of the sender or recipient. The supplied ABI exposes no getter or management function for breaker, and the Token constructor passes the deployment-provided fee array directly into ERC20.
Recommendation: Publish and validate the three constructor values, remove the bytecode-derived restriction, or replace it with an explicit and auditable address policy with transparent events and documented governance. Before integrations, test transfers to and from all intended routers, pairs, custodians, and other contracts using the exact deployed constructor configuration.
medium finding: Obfuscated arbitrary storage write executes on every transfer
The custom BNBop modifier performs low-level memory manipulation and an SSTORE during every _transfer call. The storage key is derived from hard-coded constants and a hash involving the transfer target, while the stored value is also a hard-coded arithmetic constant. This introduces opaque persistent state changes outside normal ERC-20 accounting and creates unnecessary risk of storage collision or undocumented behavior.
Evidence: The _transfer function is declared with modifier `t(to,1)`. Modifier t writes values into memory using inline assembly, computes a hash, and executes `sstore(keccak256(add(s,0x40), 0x40), mload(add(s,0x40)))` before normal balance updates. No documented contract feature uses this state, and the modifier is inherited by the token's transfer and transferFrom paths through _transfer.
Recommendation: Remove the modifier and use standard Solidity transfer logic. If persistent transfer metadata is required, define explicit storage variables, document their purpose, constrain writes to intended slots, and add tests proving that balance, allowance, and unrelated storage cannot be affected.