binancians (binancians) security report
Radar by SecureChain AI scanned the verified binancians contract on BNB Smart Chain. Source review found a constructor-configured bytecode blacklist and an unexplained assembly storage write. GoPlus reported no detected honeypot, minting, blacklist, tax, pause, or proxy signal, but constructor-dependent behavior requires verification.
The token is not suitable for a clean security assessment because transfer behavior depends on three opaque constructor-supplied byte strings and every transfer executes obfuscated assembly. If any configured byte string is empty, transfers involving ordinary externally owned accounts can revert universally; matching contract bytecode is also blocked. The fixed storage write may additionally corrupt state if its derived slot collides with meaningful storage.
Trust score: 18/100. Source verified: Yes. Chain: bsc. Contract: 0xb39888cf57a4fb9d763a8873618540d56e9a7777.
This report was last modified on 2026-10-13 and contains 2 material findings.
high finding: Constructor-configured bytecode blacklist can create a hidden transfer lock
The constructor stores fee[0], fee[1], and fee[2] as true keys in the cookies mapping. Every transfer then reverts when either the recipient's runtime bytecode or msg.sender's runtime bytecode matches one of those keys. Because constructor values are opaque bytes inputs, deployment can configure hidden restrictions that are not exposed through owner controls. If any configured key is empty bytes, the condition matches the code of ordinary externally owned accounts, potentially causing transfers involving those accounts to revert.
Evidence: In ERC20's constructor, cookies[amount[0]], cookies[amount[1]], and cookies[amount[2]] are set to true. The _transfer function uses `if (cookies[to.code] || cookies[msg.sender.code]) { revert(); }`. The Token constructor passes its deploy-time `fee` array directly into ERC20. The supplied ABI exposes the constructor as `bytes[] fee`. GoPlus reports is_blacklisted=0 and is_honeypot=0, but those signals do not remove the source-level conditional restriction.
Recommendation: Verify the exact constructor arguments and inspect the cookies mapping for the deployed instance, including whether an empty byte string or the runtime bytecode of any required token integration was configured. Remove the bytecode-based restriction and replace it with explicit, auditable policy if any transfer filtering is required. Test transfers from EOAs and through intended contract integrations.
medium finding: Obfuscated transfer modifier performs an unexplained arbitrary storage write
The custom `u` modifier runs on every _transfer and uses inline assembly to derive a storage slot from hard-coded constants and then executes sstore. This is outside normal ERC-20 accounting and is not documented by the public ABI. The write is independent of token balances and may corrupt meaningful state if its derived slot collides with a contract storage slot. The source does not provide a safe invariant or proof that the slot is unused.
Evidence: The _transfer declaration is `function _transfer(address from, address to, uint256 value)u(to,1) internal`. Modifier `u` executes `sstore(keccak256(add(s, 0x40), 0x40), mload(add(s, 0x40)))` after multiple hard-coded constants, tx.origin, and invalid-opcode checks. This assembly executes before the normal _update balance movement on every transfer.
Recommendation: Remove the custom modifier and use a standard, auditable transfer path. If the write is claimed to be required, document its purpose, calculate the exact storage slot, prove that it cannot overlap any declared or inherited storage, and test repeated transfers and all permit and transferFrom paths for state corruption.