Flying Tesla Roadster (FTR) security report
Radar AI scanned Flying Tesla Roadster on BNB Smart Chain. The verified source includes bytecode-based transfer blocking, unexplained assembly state writes, and full initial supply assignment to the deployer.
The contract is not a plain standard ERC-20 implementation. Transfers pass through hidden bytecode-based restrictions and an assembly storage-write routine, while the constructor assigns the complete initial supply to the deployer. Ownership is renounced and no external mint function is exposed, but the transfer logic and initial allocation create material risks.
Trust score: 35/100. Source verified: Yes. Chain: bsc. Contract: 0x76edfef4272e9191c8bd20eb5edc3236a51c7777.
This report was last modified on 2026-10-16 and contains 3 material findings.
high finding: Obfuscated transfer restriction can block selected addresses or all EOA transfers
Every token transfer invokes the custom p modifier and then checks goal[to.code] and goal[msg.sender.code]. The constructor sets three goal entries from deployer-supplied bytes values, so addresses whose runtime bytecode matches any configured value are rejected. If a configured value is empty bytes, every externally owned account with empty code is rejected. The constructor arguments needed to determine the configured patterns were not supplied.
Evidence: In ERC20._transfer, modifier p(to,1) is applied before transfer execution. The function then executes `if (goal[to.code] || goal[msg.sender.code]) { revert(); }`. In the ERC20 constructor, `goal[amount[0]] = true`, `goal[amount[1]] = true`, and `goal[amount[2]] = true`, with `amount` supplied by the deployer through Token's `bytes[] fee` constructor argument.
Recommendation: Expose and document transfer restrictions, remove the bytecode-based denylist, or replace it with a transparent, auditable mechanism with explicit governance and predictable address-based rules. Verify the deployment constructor arguments before enabling transfers.
medium finding: Every transfer performs unexplained obfuscated persistent storage writes
The p modifier uses inline assembly to derive a storage slot from transfer parameters and transaction-origin data, then writes a hardcoded value with sstore. This creates hidden state changes unrelated to ERC-20 accounting, increases transfer complexity and gas usage, and makes storage behavior difficult to audit. The supplied source does not show a legitimate consumer of these writes.
Evidence: Modifier `p(address y, uint n)` computes memory values with opaque constants and executes `sstore(keccak256(add(d, 0x40), 0x40), 7115454929198713368754825322558477545812811785540)`. The modifier is attached to `_transfer(address from, address to, uint256 value)` as `p(to,1)`, so it runs on both `transfer` and `transferFrom` paths.
Recommendation: Remove the assembly modifier and perform no persistent writes during transfers unless the state is explicitly required, documented, and covered by tests. If the behavior is intentional, publish the storage layout, derivation scheme, and invariant proving that it cannot affect balances, allowances, or other state.
medium finding: Entire initial token supply is assigned to the deployer
The constructor mints the complete initial supply directly to msg.sender. This creates substantial allocation and distribution control for the deploying address even though ownership is immediately renounced. Renouncing ownership does not reverse or restrict the deployer's token balance.
Evidence: ERC20's constructor executes `_mint(_msgSender(), 1e27)`. Token invokes that constructor, and the supplied GoPlus evidence identifies the creator address as the deployer associated with the full reported token allocation.
Recommendation: Publish a verifiable allocation plan, vesting or timelock arrangements, and clear controls for any deployer-held supply. Users should treat the deployer-controlled allocation as a material distribution and sell-pressure risk until independently demonstrated otherwise.