The BITES token project is complete, verified, and committed.

What was delivered

• src/BITESToken.sol: a self-contained ERC-20 with OpenZeppelin v5 semantics. The contract is named BITESToken (10 characters, within the 32-character manifest limit); name() and symbol() return BITES. The supply of 10,000,000 tokens at 18 decimals is a compile-time constant minted once to msg.sender in a no-argument constructor that calls nothing. There is no owner, mint, burn, pause, blocklist, fee, or upgrade path, and the built runtime contains no DELEGATECALL, CALLCODE, or SELFDESTRUCT.
• test/BITESToken.t.sol and test/DeployBITESToken.t.sol: 37 tests covering metadata, supply, exact transfers, allowance accounting including the unlimited sentinel, every revert path, launch-shaped flows (factory to distributor to claimant, pool round trip), the same privileged-selector probes the protected test uses, a bytecode opcode scan, and three fuzz tests.
• script/DeployBITESToken.s.sol: a reference deploy script whose deploy() function is tested directly; run() only wraps it in a broadcast.
• README.md: assumptions, manifest values, launch payout breakdown, after-launch settings (none), and operational responsibilities.
• foundry.toml pins solc = "0.8.26", bytecode_hash = "none", optimizer on, ffi off, empty fs_permissions. forge-std v1.11.0 is vendored under lib/forge-std/ as plain files with no nested .git.

Verification

forge build, forge test (37 passed, 0 failed), and forge fmt --check all pass in the working tree. I also copied the tree to a fresh directory and re-ran all three with --offline and an empty environment, and they passed there too. The built runtime has no metadata trailer and is 3.4 KB.

Noted limitation

Slither and Mythril were not run, since the execution profile does not provide them. The README states this and defers the audit to the launch's independent review step.

All work is committed on main as commit 423dd40.

Created launch.json with the exact BITES supply, empty constructor arguments, and required pool and economics values.

Validation passed: manifest checks, forge build, and all 37 repository tests. Only launch.json is a submission change.

I found one low-severity defect in BITES and nothing high or critical. The findings and coverage are in .imd-findings.json. I changed no project files; the scratch test I used to confirm the defect has been deleted.

Finding 1 (low): transferFrom accepts the zero address as sender (src/BITESToken.sol:138)

• The gap: _transfer rejects a zero-address receiver but never checks the sender. The contract's own comments promise OpenZeppelin v5 behaviour, where "the zero address can neither send nor receive".
• Failing input: any account with no balance or allowance calls transferFrom(address(0), 0xBEEF, 0). It returns true and emits Transfer(address(0), 0xBEEF, 0). It should revert.
• Impact: explorers and indexers read a transfer from the zero address as a mint, so anyone can fake "mint" events on a token whose promise is a fixed supply minted once. Balances and total supply never change, which is why it rates low.
• Proof: I ran a Foundry test that expects the revert. It fails on the current code, and the trace shows the event being emitted. The test source is in the finding's proof field.
• Fix: add if (from == address(0)) revert ERC20InvalidSender(address(0)); in _transfer, next to the receiver check.

What I checked against the Access Control, Trust Gap and Asymmetry guides:

• Permissions: there is no owner, minter, pause, blocklist, burnFrom, fallback or receive. The constructor's only effect is minting the full supply to the deployer, and totalSupply is a constant. There are no roles to escalate, nothing to initialise and no unequal guards.
• Trust Gap: no privileged actor or price formula exists, so there is no case where a permitted caller can extract value.
• Asymmetry: I compared the paired functions and checks. approve and transferFrom spend allowances correctly, including treating the maximum allowance as unlimited. The only mismatch is the missing sender check above.
• Launch flows: transfers carry no fee or burn and no address gets special treatment, so factory → distributor → claimant and the pool seed and swaps all move exactly the amount asked.

Coverage: approve holds, transfer holds, and transferFrom has finding 1. I also added rows for the "supply cannot grow / no privileged role" and "launch flows arrive whole" invariants, both holding.

Not checked: the verifier's protected launch test imports LaunchLiquidity, PoolInitializationGuard, HookFlags and v4-core, none of which are in this repository, so I couldn't run it. I reviewed the token against what it checks instead. The project's own test suite passes (37 tests).

Review complete. The findings file is written and validated, and the scratch test directory is removed. Nothing else in the tree was changed.

Outcome

The token is a plain fixed-supply ERC-20 with no owner, no hooks, no external calls and a constant totalSupply. Across the Execution Trace, Periphery and First Principles guides, I found one low-severity defect and no fund-loss paths.

Finding (low)

_transfer rejects a zero-address receiver but not a zero-address sender, even though the NatSpec promises both and the contract claims OpenZeppelin v5 semantics. Any caller can run transferFrom(address(0), to, 0) and get a successful return plus a Transfer(address(0), to, 0) event. Balances and supply are untouched, and a non-zero amount is stopped by the allowance check, so the only effect is a spoofable zero-value mint-shaped event for indexers. I verified this with a Foundry test before reporting it.

Coverage

• approve: holds. Zero spender rejected, overwrite semantics, no external surface.
• transfer: holds. Balance checked before the unchecked subtraction, self-transfer preserves balance, exact amounts moved.
• transferFrom: finding 1. Allowance handling and the max sentinel are correct otherwise.
• Invariants checked: balance sum equals the constant supply, no privileged role after construction, launch flows arrive whole, deploy script and vendored forge-std are sound.

The existing 37 tests pass. The aderyn "large numeric literal" lead is the supply constant, which evaluates correctly to 10,000,000 tokens at 18 decimals and is not a defect.

Review complete. The findings file is written and validated, and the working tree is untouched apart from it.

Outcome: one low-severity finding, no critical, high or medium defects. All three ABI entry points plus four invariant and economic rows are recorded in the coverage record.

What I checked, from the Economic Security, Invariant and Flow Gap guides:

• Conservation and allowance invariants. Traced by hand and confirmed with a handler-based stateful fuzz across seven actors, including the token's own address: the sum of balances always equals the constant supply, the zero address never holds anything, and allowances matched a ghost ledger exactly.
• Launch flows. The distributor, pool seed and remainder shares are exact multiples of one token, and every transfer path moves exactly the requested amount with no fee, hook, callback or external call. Nothing can grow the supply or move a holder's balance, and the runtime has no delegatecall, callcode or selfdestruct.
• External dependency and token-misbehaviour surface. The contract calls nothing, holds no oracle, accepts no ether and has no privileged role, so the atomic-extraction, dependency-failure and admin lenses have nothing to attach to.

The finding (low): _transfer in src/BITESToken.sol checks the receiver but not the sender for the zero address, unlike the OpenZeppelin v5 semantics the NatSpec claims. Any caller can run a zero-value transferFrom naming the zero address as sender. It succeeds and emits a mint-shaped Transfer event. Balances and supply are unchanged, which I verified, so the impact is limited to event integrity for indexers and launch monitors. The one-line fix is a sender check matching OpenZeppelin.

The scratch tests were removed after running. The approve front-running race was noted in coverage as standard EIP-20 behaviour, not reported as a defect.

The review is complete. The findings file is in place at the repository root, no source or configuration file was changed, and the scratch tests live only under the ignored test/scratch/ directory.

Outcome: one low-severity finding, no math defects. The token has no division, scaling, external calls, payable path or bytes decoding, so most of the Math Precision, Boundary and Numerical Gap checklists have nothing to bite on. What remained I verified by test rather than by reading alone.

Finding (low), src/BITESToken.sol:139. The internal transfer validates only the receiver, never the sender. Any address can call transferFrom(address(0), to, 0). The allowance check passes because zero is not less than zero, the balance check passes the same way, and the contract emits a mint-shaped Transfer(0x0, to, 0) event. The contract's own NatSpec claims OpenZeppelin v5 semantics, under which this reverts with ERC20InvalidSender. No balance or supply moves, so the impact is limited to indexers and mint-event-based accounting plus the stated-semantics mismatch. The attached proof test fails on the current code with the trace showing the emitted event, and passes once a zero-sender revert is added at the top of the internal transfer.

What holds, with evidence:

• Balance-sum invariant equals the 1e25 supply across a Foundry invariant run of 128,000 handler calls mixing transfer, approve and transferFrom among five actors. This confirms the two unchecked blocks are safe.
• Boundary inputs behave as documented: max uint and supply-plus-one revert with the exact custom error, self-transfer of the whole balance is a no-op, the unlimited-allowance sentinel is not decremented while max-minus-one is, and an unlimited allowance is still bounded by balance.
• The constant TOTAL_SUPPLY evaluates to exactly 10,000,000 tokens at 18 decimals, so the aderyn large-literal lead is style only. The launch split of 10, 81 and 9 percent is dust-free.
• ABI decoding rejects dirty upper bits in address words and short calldata. Ether sent to the token reverts.

Coverage record. All three listed entry points have rows: transfer and approve hold, transferFrom carries the finding. Six further rows cover the invariant, the constant, the constructor, the launch split, and the two guide-level sweeps. Nothing was left unreached.

Added 18 boundary/fuzz tests and three stateful invariants under test/, covering failures, rollback, allowances, and supply conservation.

forge build and forge test pass: 56 tests, zero failures. Invariants exercised 32,768 randomized calls.

No implementation defects found.

The review is complete and written to .imd-findings.json. No source files were changed, and the scratch tests were removed.

Outcome: The four specialists all reported the same defect, and it reproduces. I merged them into one low finding and added one informational note from my own re-read. Nothing critical, high or medium exists in this token.

Finding 1, low. transferFrom(address(0), to, 0) from any caller returns true and emits a zero-value Transfer from the zero address, which is the shape of a mint. The contract's NatSpec promises OpenZeppelin v5 semantics where the zero address cannot send. Balances and supply are untouched, so the impact is limited to indexers and monitors that treat Transfer-from-zero as a mint. I ran both specialist proofs under test/scratch and both fail on the current code with the trace showing the emitted event, so I attached one as the finding's proof. The fix is a one-line sender check in _transfer.

Finding 2, info. The NatSpec on the ERC20InvalidReceiver error says it also fires on insufficient balance. That path actually reverts with ERC20InsufficientBalance. The code is right and only the comment is wrong.

Coverage. All three entry points are answered. approve and transfer hold. transferFrom carries finding 1. I also recorded three invariants as holding: constant supply equal to the sum of balances, launch flows moving exact amounts, and deployability with the empty constructor-argument list and the manifest's supply of 1e25 minor units. The project's own 56 tests pass. The protected launch test could not be run here because it needs the factory environment and v4-core, which this tree does not vendor.