{"assessments":[],"deployments":[],"fuzz":[],"identity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"interpretation":"Records acceptance and evidence. Neither completion nor an AI assessment establishes correctness, safety, or independent review.","jobId":"fd84aead-61cc-4b77-878c-2f5c36822793","kind":"shape:chain","nodes":[{"acceptedSubmissionHash":"173e637c22a7b55c7898c771ad01e32baf86e5d4ed09914faf698cd5afaf4fed","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_economics","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"},{"acceptedSubmissionHash":"9d0e86bf1b497a4e8e37dcd8625f0c567192737d55c68ca5e0c66e693ffa66a8","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_flow","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"},{"acceptedSubmissionHash":"0567df23fbab7eb3e1dac0bf35f779cc4922c1f51b9c00eec8ba7df7b9fef2c6","dependsOn":["build_contract_project","write_foundry_tests","manifest","audit_math","audit_permissions","audit_economics","audit_flow"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"af3aa01159bbf354f621cafa5c0006f6169e0938a8b015be508b7377dbf165bc","skillId":"audit-judge","tools":[]},"key":"audit_judge","kind":"code","role":"review","skillHash":"af3aa01159bbf354f621cafa5c0006f6169e0938a8b015be508b7377dbf165bc","skillId":"audit-judge","state":"accepted"},{"acceptedSubmissionHash":"dac1ce00ef2f4b362120327e96eeb2715d6137b2044e393dfbe9dc194c89f986","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_math","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"},{"acceptedSubmissionHash":"f23f4599e5e206b5ee1813c8da6284e681aa177d7e1b0c257cd641ff6eb8a233","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_permissions","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"},{"acceptedSubmissionHash":"71e25ac762283a0d5d4bec10aa36bffc718c46fea663e80025787195b32ef7dc","dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"6b8d2c2ebd3301cff2be8edb1e1cc6ba65c858c02fe7247be81722b969842265","skillId":"build-contract-project","tools":[]},"key":"build_contract_project","kind":"code","role":"implement","skillHash":"6b8d2c2ebd3301cff2be8edb1e1cc6ba65c858c02fe7247be81722b969842265","skillId":"build-contract-project","state":"accepted"},{"acceptedSubmissionHash":"5689b8b06304c28660909d103ac3aefc1758fc097500f888cc375e8d55bbf358","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"tools":[]},"key":"manifest","kind":"code","role":"integrate","skillHash":null,"skillId":null,"state":"accepted"},{"acceptedSubmissionHash":"9399181cc80795cddcc42b4fcdf68374afc2285a3b21cb57ac534a8e62a896fb","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"73431852439ad3a343f3d2b7db1c43cd363b9f48f9bb51497374a0cf6d50b223","skillId":"write-foundry-tests","tools":[]},"key":"write_foundry_tests","kind":"code","role":"tests","skillHash":"73431852439ad3a343f3d2b7db1c43cd363b9f48f9bb51497374a0cf6d50b223","skillId":"write-foundry-tests","state":"accepted"}],"objective":"A custom token: BITES (BITES).\nToken name: BITES\nToken symbol: BITES\nToken supply: 10,000,000 with 18 decimals, all minted once to the deployer in the constructor.","parentJobId":null,"planHash":"5c673bd5972c54201bd52bb1b53efb1879503c3805c24d494820c0e707474598","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"fd84aead-61cc-4b77-878c-2f5c36822793","publication":{"commit":null,"deliveredAt":null,"repoUrl":"https://github.com/identity-md-launches/launch-1474-bites"},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[],"schema":"identitymd-work-v1","signals":[{"agentId":"52188","feedbackHash":"400682794ef5219db20925f5551dd1f34421b55a8621ce128b4c82035ecfd4fa","nodeKey":"audit_economics","submissionHash":"173e637c22a7b55c7898c771ad01e32baf86e5d4ed09914faf698cd5afaf4fed","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51214","feedbackHash":"27321ac45996abf361ffa827ee6bcf00e1dcc68f8bb62d416af2c4c9f2180a93","nodeKey":"audit_flow","submissionHash":"9d0e86bf1b497a4e8e37dcd8625f0c567192737d55c68ca5e0c66e693ffa66a8","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52611","feedbackHash":"eddc8a0af6d7a6f99305e46f2a9d627ad22c1ff7e568d3885e1cec9551e340cd","nodeKey":"audit_judge","submissionHash":"0567df23fbab7eb3e1dac0bf35f779cc4922c1f51b9c00eec8ba7df7b9fef2c6","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52678","feedbackHash":"2026c4cf6978ac89164b2217f4ac20e293a82b704fe68ca2e984b0f36f97c990","nodeKey":"audit_math","submissionHash":"dac1ce00ef2f4b362120327e96eeb2715d6137b2044e393dfbe9dc194c89f986","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52130","feedbackHash":"2c0b15322b41848ab4c7c5171951a5166ad9be87799eef2960c3a7a6b8920dac","nodeKey":"audit_permissions","submissionHash":"f23f4599e5e206b5ee1813c8da6284e681aa177d7e1b0c257cd641ff6eb8a233","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52706","feedbackHash":"daff850277bcd873bf5dce8deab2f51d63d946aea0f161c759c658ede325dacb","nodeKey":"build_contract_project","submissionHash":"71e25ac762283a0d5d4bec10aa36bffc718c46fea663e80025787195b32ef7dc","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"51089","feedbackHash":"6c63c557c2d12f550f5ffc7e0546116fbbfda76e3c8f84304061fcf19cb876e1","nodeKey":"manifest","submissionHash":"5689b8b06304c28660909d103ac3aefc1758fc097500f888cc375e8d55bbf358","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"52707","feedbackHash":"09792c205db5f83c964176bcd6801e6b8e990b2ec8ad5ee32ca7f5132e583919","nodeKey":"write_foundry_tests","submissionHash":"9399181cc80795cddcc42b4fcdf68374afc2285a3b21cb57ac534a8e62a896fb","tag1":"verification:checks","tag2":"acceptance-v2","value":1}],"site":null,"snapshotHash":"20f542b3a58bf29659d3eea9ca5229080d849ebd6524398e9d8a5226b0a90fa6","state":"completed","submissions":[{"artifacts":[],"attempt":1,"bundleHash":null,"device":"2a4ad9be53991100","findings":[{"citation":"resolved","description":"Merged from audit_math, audit_permissions, audit_flow and audit_economics, which all report the same root cause. `_transfer` (src/BITESToken.sol:138-149) validates only the receiver; it never rejects `from == address(0)`. The contract's NatSpec (lines 9-12) promises OpenZeppelin v5 semantics and that 'the zero address can neither send nor receive'. In OZ v5 `_transfer` reverts with `ERC20InvalidSender(address(0))` for a zero-address sender. Here `transferFrom(address(0), to, 0)` from any caller passes `_spendAllowance` (allowance of address(0) is 0, and 0 < 0 is false), passes the balance check (balance of address(0) is 0, and 0 < 0 is false), writes 0 to both slots and emits `Transfer(address(0), to, 0)`, the shape EIP-20 reserves for a mint, then returns true. A non-zero amount is stopped only incidentally by the allowance check with `ERC20InsufficientAllowance`, not with a sender error. Reproduced: both specialist proofs (.imd/reads/proofs/Proof_5eec7c82ac15.t.sol and Proof_5f7b34179f1f.t.sol) fail on this code with 'next call did not revert as expected' and the trace shows `emit Transfer(from: 0x0, to: <recipient>, amount: 0)` followed by `[Return] true`. Balances and totalSupply are unchanged, so there is no loss of funds and the supply cannot grow: impact is limited to event-level integrity (indexers, explorers and launch monitors that classify Transfer-from-zero as a mint will record spurious zero-value post-launch mints) and the contract's own stated semantics being false. Severity low. Minimal fix preserving intended behaviour: declare `error ERC20InvalidSender(address sender);` and add `if (from == address(0)) revert ERC20InvalidSender(address(0));` as the first line of `_transfer`, matching OZ v5.","line":139,"path":"src/BITESToken.sol","proof":"// SPDX-License-Identifier: MIT\npragma solidity 0.8.26;\n\nimport {Test} from \"forge-std/Test.sol\";\nimport {BITESToken} from \"src/BITESToken.sol\";\n\n/// @notice The contract documents that \"the zero address can neither send nor receive\" and that it\n///         follows OpenZeppelin v5 semantics, under which `_transfer` from address(0) reverts with\n///         ERC20InvalidSender. On the code as it is, any caller can run\n///         `transferFrom(address(0), to, 0)`: `_spendAllowance` passes (0 >= 0), `_transfer` checks\n///         only `to`, and a mint-shaped `Transfer(address(0), to, 0)` event is emitted.\n///         This test fails on the current code and passes once `_transfer` rejects `from == address(0)`.\ncontract ZeroAddressSenderTest is Test {\n    BITESToken token;\n    address alice = makeAddr(\"alice\");\n    address bob = makeAddr(\"bob\");\n\n    function setUp() public {\n        token = new BITESToken();\n    }\n\n    function test_transferFromZeroAddressSenderReverts() public {\n        vm.prank(alice);\n        vm.expectRevert();\n        token.transferFrom(address(0), bob, 0);\n    }\n}","reproduction":"State: freshly deployed BITESToken (deployer holds 10_000_000e18). Caller alice = any address with no balance and no allowance. Call: vm.prank(alice); token.transferFrom(address(0), bob, 0). Expected (per NatSpec lines 9-12 and OZ v5): revert ERC20InvalidSender(0x0000000000000000000000000000000000000000). Actual: returns true and emits Transfer(from=0x0000000000000000000000000000000000000000, to=bob, value=0); afterwards balanceOf(bob) == 0 and totalSupply() == 10000000000000000000000000. Same call with amount 1 reverts ERC20InsufficientAllowance(alice, 0, 1) rather than a sender error. Verified by running the attached proof with `forge test --match-path test/scratch/Proof_5f7b34179f1f.t.sol -vvv`: FAIL 'next call did not revert as expected', trace `BITESToken::transferFrom(0x0, bob, 0)` -> `emit Transfer(from: 0x0, to: bob, amount: 0)` -> `[Return] true`.","severity":"low","snippet":"        if (to == address(0)) revert ERC20InvalidReceiver(address(0));","title":"transferFrom accepts address(0) as sender: anyone can emit a mint-shaped Transfer(address(0), to, 0), contrary to the documented OpenZeppelin v5 'zero address can neither send' guarantee"},{"citation":"resolved","description":"The error documentation on line 19 says `ERC20InvalidReceiver` is raised when a transfer 'would take more than the sender holds'. In `_transfer` (lines 139-141) that condition reverts with `ERC20InsufficientBalance(from, fromBalance, amount)`; `ERC20InvalidReceiver` is only ever raised for a zero-address receiver. Code behaviour is correct and matches OZ v5; only the comment is wrong, which can mislead integrators decoding reverts. Fix: drop the clause 'or would take more than the sender holds' from the line-19 comment.","line":19,"path":"src/BITESToken.sol","reproduction":"State: fresh BITESToken, deployer holds 10_000_000e18, alice holds 0. Call: vm.prank(alice); token.transfer(bob, 1). Expected per the line-19 comment: revert ERC20InvalidReceiver(...). Actual: revert ERC20InsufficientBalance(alice, 0, 1) (line 141). Call token.transfer(address(0), 0) from the deployer: reverts ERC20InvalidReceiver(0x0) (line 139), the only path that raises that error.","severity":"info","snippet":"    /// @notice A transfer was attempted to the zero address, or would take more than the sender holds.","title":"NatSpec for ERC20InvalidReceiver claims it also covers an insufficient balance, but that path reverts with ERC20InsufficientBalance"}],"hash":"0567df23fbab7eb3e1dac0bf35f779cc4922c1f51b9c00eec8ba7df7b9fef2c6","nodeId":"635ef9a1-be06-4bb2-8efe-ec27883e4e4b","outcome":"completed","summary":"The review is complete and written to `.imd-findings.json`. No source files were changed, and the scratch tests were removed.\n\n**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.\n\n**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`.\n\n**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.\n\n**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.","treeHash":null,"usage":{"cachedInputTokens":223189,"inputTokens":130,"model":"claude-fable-5-1","outputTokens":7603,"runtime":"claude","turns":13,"wallClockMs":125019}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"d4b53d656a3fbe07","findings":[{"citation":"resolved","description":"The NatSpec at src/BITESToken.sol:9-12 states the contract follows OpenZeppelin v5 semantics and that \"the zero address can neither send nor receive\". `_transfer` only guards the receiver (`to == address(0)`); there is no `from == address(0)` check, which OpenZeppelin v5's `_transfer` has (it reverts with `ERC20InvalidSender(address(0))`). `transferFrom(address(0), to, amount)` reaches `_transfer` with `from == address(0)`. For `amount > 0` it is stopped only incidentally, by `_spendAllowance` (allowance of the zero address is always 0 since nobody can call `approve` as address(0)) and reverts with `ERC20InsufficientAllowance`, not with a sender error. For `amount == 0` nothing stops it: `_spendAllowance` writes `0 - 0`, `_transfer` passes `0 < 0` and emits `Transfer(address(0), to, 0)` and returns true. Any unprivileged caller can therefore emit mint-shaped Transfer events from address(0) at will. No balance or supply changes (verified by test), so impact is limited to event-level integrity: indexers, explorers and launch monitors that treat `Transfer(from=0x0)` as a mint will record spurious zero-value mints after launch, and the documented guarantee in the contract's own NatSpec is false. Invariant lens: `balanceOf(address(0)) == 0` and `sum(balances) == totalSupply` still hold; the broken guarantee is the interface promise that address(0) is never a sender. Minimal fix that preserves intended behaviour: add `if (from == address(0)) revert ERC20InvalidSender(address(0));` (declaring that error) at the top of `_transfer`, matching OZ v5.","line":138,"path":"src/BITESToken.sol","reproduction":"State: fresh BITESToken (any deployer). Call, from any address `stranger` with no balance and no allowance: `token.transferFrom(address(0), bob, 0)`. Expected (per NatSpec lines 9-12 / OZ v5): revert ERC20InvalidSender(0x0). Actual: returns true and emits `Transfer(0x0000000000000000000000000000000000000000, bob, 0)`; balanceOf(bob) == 0, totalSupply unchanged at 10000000000000000000000000. With amount 1 instead of 0: reverts ERC20InsufficientAllowance(stranger, 0, 1) rather than a sender error. Verified with a scratch Foundry test (vm.expectEmit on Transfer(address(0), bob, 0) then vm.prank(stranger); token.transferFrom(address(0), bob, 0) passes).","severity":"low","snippet":"    function _transfer(address from, address to, uint256 amount) private {\n        if (to == address(0)) revert ERC20InvalidReceiver(address(0));\n        uint256 fromBalance = _balances[from];\n        if (fromBalance < amount) revert ERC20InsufficientBalance(from, fromBalance, amount);","title":"transferFrom lets the zero address act as sender: a zero-value Transfer(address(0), to, 0) can be emitted by anyone, contrary to the documented OZ v5 semantics"}],"hash":"173e637c22a7b55c7898c771ad01e32baf86e5d4ed09914faf698cd5afaf4fed","nodeId":"de9bac25-df21-4729-95ad-35f7d51fd47d","outcome":"completed","summary":"Review complete. The findings file is written and validated, and the working tree is untouched apart from it.\n\n**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.\n\n**What I checked, from the Economic Security, Invariant and Flow Gap guides:**\n- **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.\n- **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.\n- **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.\n\n**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.\n\nThe 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.","treeHash":null,"usage":{"cachedInputTokens":812467,"inputTokens":322,"model":"claude-fable-5-1","outputTokens":14418,"runtime":"claude","turns":25,"wallClockMs":226353}},{"artifacts":[],"attempt":1,"bundleHash":"3cf306aec713e2cc3e5c15505c90efd27f79f8e33bd1fee748e191cbb917e1a8","device":"393ade31b99d5d5b","findings":[],"hash":"5689b8b06304c28660909d103ac3aefc1758fc097500f888cc375e8d55bbf358","nodeId":"d1133b17-9576-4f38-a21a-2700993da227","outcome":"completed","summary":"Created [launch.json](/home/imd/.identitymd/work/fd84aead-61cc-4b77-878c-2f5c36822793/d1133b17-9576-4f38-a21a-2700993da227/launch.json) with the exact BITES supply, empty constructor arguments, and required pool and economics values.\n\nValidation passed: manifest checks, `forge build`, and all 37 repository tests. Only `launch.json` is a submission change.","treeHash":"278a76bf5de313fcae6988d1505eecf99674d2e3","usage":{"cachedInputTokens":132224,"inputTokens":22049,"model":"gpt-6-astra","outputTokens":2040,"runtime":"codex","turns":3,"wallClockMs":54439}},{"artifacts":[],"attempt":1,"bundleHash":"fb7772bfc8244384524935afd23f665620463970476c091249c0b384320c0321","device":"f3b611cf8afb513f","findings":[],"hash":"71e25ac762283a0d5d4bec10aa36bffc718c46fea663e80025787195b32ef7dc","nodeId":"7e3b46ac-255c-4606-8da1-d3ecf1a60341","outcome":"completed","summary":"The BITES token project is complete, verified, and committed.\n\n**What was delivered**\n\n- `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.\n- `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.\n- `script/DeployBITESToken.s.sol`: a reference deploy script whose `deploy()` function is tested directly; `run()` only wraps it in a broadcast.\n- `README.md`: assumptions, manifest values, launch payout breakdown, after-launch settings (none), and operational responsibilities.\n- `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`.\n\n**Verification**\n\n`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.\n\n**Noted limitation**\n\nSlither 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.\n\nAll work is committed on `main` as commit 423dd40.","treeHash":"fcc5597f136d036e047697cba7468bf8a59d1d1c","usage":{"cachedInputTokens":684942,"inputTokens":386,"model":"claude-fable-5-1","outputTokens":21480,"runtime":"claude","turns":27,"wallClockMs":247287}},{"artifacts":[],"attempt":1,"bundleHash":"26fa7627c93b8cdf0cb5f44806c5f6d8a2b4e23b812f5d4b118081803fd37454","device":"2293d6b19e81ef1a","findings":[],"hash":"9399181cc80795cddcc42b4fcdf68374afc2285a3b21cb57ac534a8e62a896fb","nodeId":"f9e21c83-11f5-414a-8aa3-d1f90b31dbe4","outcome":"completed","summary":"Added 18 boundary/fuzz tests and three stateful invariants under `test/`, covering failures, rollback, allowances, and supply conservation.\n\n`forge build` and `forge test` pass: 56 tests, zero failures. Invariants exercised 32,768 randomized calls.\n\nNo implementation defects found.","treeHash":"52096106ab400fcc2ece0fbcb4ac68c0ab5d15e3","usage":{"cachedInputTokens":943488,"inputTokens":80017,"model":"gpt-6-astra","outputTokens":14151,"runtime":"codex","turns":6,"wallClockMs":364601}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"dd2ee4882a1be950","findings":[{"citation":"resolved","description":"_transfer (src/BITESToken.sol:138-149) rejects a zero-address receiver but never rejects a zero-address sender. The contract's own NatSpec (lines 11-12: 'the zero address can neither send nor receive') and its stated OpenZeppelin v5 semantics (OZ v5 _transfer reverts with ERC20InvalidSender(address(0))) both promise the opposite. Execution trace of transferFrom(address(0), to, 0) from any unprivileged caller: _spendAllowance reads _allowances[0][caller] == 0, 0 < 0 is false, so it falls through and writes 0 - 0 = 0; _transfer passes the receiver check, reads _balances[0] == 0, 0 < 0 is false, writes 0 and 0, and emits Transfer(address(0), to, 0). The call returns true. Balances and totalSupply are unchanged, so there is no loss of funds; the only effect is that any address can mint-shaped Transfer events (from == address(0)) of value 0 for any recipient, which indexers, explorers and accounting tools that classify Transfer-from-zero as a mint will record as a mint of 0 to that recipient. A non-zero amount is stopped earlier by the allowance check (ERC20InsufficientAllowance(caller, 0, amount)), so supply cannot actually grow. Minimal fix that preserves behaviour: add `if (from == address(0)) revert ERC20InvalidSender(address(0));` at the top of _transfer (declaring the error), matching the comment and OZ v5.","line":139,"path":"src/BITESToken.sol","reproduction":"State: freshly deployed BITESToken; caller 0xA77 holds nothing and has no allowance. Call: vm.prank(0xA77); token.transferFrom(address(0), 0xB0B, 0). Expected (per NatSpec lines 11-12 and OZ v5): revert ERC20InvalidSender(address(0)). Actual: returns true and emits Transfer(address(0), 0xB0B, 0); balanceOf(0xB0B) == 0 and totalSupply() == 10_000_000e18 afterwards. Verified with a Foundry test using vm.expectEmit(true,true,true,true,address(token)); emit Transfer(address(0), bob, 0); before the call: it passes on the current code. The same call with amount 1 reverts ERC20InsufficientAllowance(0xA77, 0, 1), confirming only zero-value events are reachable.","severity":"low","snippet":"        if (to == address(0)) revert ERC20InvalidReceiver(address(0));","title":"transferFrom accepts the zero address as sender: anyone can emit Transfer(address(0), to, 0), contrary to the documented 'zero address can neither send nor receive' guarantee"}],"hash":"9d0e86bf1b497a4e8e37dcd8625f0c567192737d55c68ca5e0c66e693ffa66a8","nodeId":"badf6bdc-5b23-40e0-b98c-9a0119f13526","outcome":"completed","summary":"Review complete. The findings file is written and validated, and the scratch test directory is removed. Nothing else in the tree was changed.\n\n**Outcome**\n\nThe 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.\n\n**Finding (low)**\n\n`_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.\n\n**Coverage**\n\n- `approve`: holds. Zero spender rejected, overwrite semantics, no external surface.\n- `transfer`: holds. Balance checked before the unchecked subtraction, self-transfer preserves balance, exact amounts moved.\n- `transferFrom`: finding 1. Allowance handling and the max sentinel are correct otherwise.\n- 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.\n\nThe 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.","treeHash":null,"usage":{"cachedInputTokens":341048,"inputTokens":162,"model":"claude-fable-5-1","outputTokens":9992,"runtime":"claude","turns":19,"wallClockMs":147953}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"03332db135fe4c15","findings":[{"citation":"resolved","description":"Boundary (sentinel-address branch, zero input). `_transfer` validates only `to`; it never rejects `from == address(0)`. The contract's NatSpec (lines 9-11) states it follows OpenZeppelin v5 semantics and that \"the zero address can neither send nor receive\". In OZ v5, `_transfer` reverts with `ERC20InvalidSender(address(0))` for a zero-address sender. Here, `transferFrom(address(0), to, 0)` passes `_spendAllowance` (allowance 0 is not < amount 0), passes the balance check (0 is not < 0), writes nothing, and emits `Transfer(address(0), to, 0)`, the exact shape EIP-20 reserves for a mint. Any unprivileged caller can emit such events for any `to` at will. No balance or supply changes (amount is forced to 0 because address(0) holds nothing and has granted no allowance), so the impact is limited to indexers, explorers and mint-event-based accounting that treat `Transfer` from the zero address as token creation, plus the stated-semantics mismatch. Minimal fix that preserves intended behaviour: add `error ERC20InvalidSender(address sender);` and `if (from == address(0)) revert ERC20InvalidSender(address(0));` at the top of `_transfer`, matching OZ v5.","line":139,"path":"src/BITESToken.sol","proof":"// SPDX-License-Identifier: MIT\npragma solidity 0.8.26;\n\nimport {Test} from \"forge-std/Test.sol\";\nimport {BITESToken} from \"src/BITESToken.sol\";\n\n/// @notice The contract documents that \"the zero address can neither send nor receive\" and that it\n///         follows OpenZeppelin v5 semantics, under which `_transfer` from address(0) reverts with\n///         ERC20InvalidSender. On the code as it is, any caller can run\n///         `transferFrom(address(0), to, 0)`: `_spendAllowance` passes (0 >= 0), `_transfer` checks\n///         only `to`, and a mint-shaped `Transfer(address(0), to, 0)` event is emitted.\n///         This test fails on the current code and passes once `_transfer` rejects `from == address(0)`.\ncontract ZeroAddressSenderTest is Test {\n    BITESToken token;\n    address alice = makeAddr(\"alice\");\n    address bob = makeAddr(\"bob\");\n\n    function setUp() public {\n        token = new BITESToken();\n    }\n\n    function test_transferFromZeroAddressSenderReverts() public {\n        vm.prank(alice);\n        vm.expectRevert();\n        token.transferFrom(address(0), bob, 0);\n    }\n}","reproduction":"State: fresh BITESToken, alice holds nothing and has no allowance. Call, from alice (any address): token.transferFrom(address(0), bob, 0). Expected (per NatSpec lines 9-11 / OZ v5): revert ERC20InvalidSender(0x0). Actual: returns true and emits Transfer(from=0x0000000000000000000000000000000000000000, to=bob, value=0). Confirmed with forge trace: `BITESToken::transferFrom(0x0, bob, 0)` -> `emit Transfer(from: 0x0, to: bob, amount: 0)` -> `[Return] true`. With amount >= 1 the call reverts ERC20InsufficientAllowance(alice, 0, 1), so only the zero-value variant is reachable.","severity":"low","snippet":"        if (to == address(0)) revert ERC20InvalidReceiver(address(0));","title":"transferFrom accepts address(0) as sender: anyone can emit a mint-shaped Transfer(0x0, to, 0) event, contrary to the documented OpenZeppelin v5 semantics"}],"hash":"dac1ce00ef2f4b362120327e96eeb2715d6137b2044e393dfbe9dc194c89f986","nodeId":"e2873c95-536a-48da-9dac-c78c37262034","outcome":"completed","summary":"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.\n\n**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.\n\n**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.\n\n**What holds, with evidence:**\n- 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.\n- 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.\n- 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.\n- ABI decoding rejects dirty upper bits in address words and short calldata. Ether sent to the token reverts.\n\n**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.","treeHash":null,"usage":{"cachedInputTokens":806835,"inputTokens":322,"model":"claude-fable-5-1","outputTokens":16019,"runtime":"claude","turns":24,"wallClockMs":246231}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"1c29c7c6e4cf57eb","findings":[{"citation":"resolved","description":"Asymmetry (Asymmetry guide step 3, branch/validation diff): _transfer validates the receiver (to != 0) but never validates the sender, and _approve validates the spender but transferFrom never validates `from`. The contract NatSpec (line 11) promises OpenZeppelin v5 semantics where 'the zero address can neither send nor receive', and OZ v5 _transfer reverts with ERC20InvalidSender(address(0)). Here, because _allowances[0][caller] == 0 and _balances[0] == 0, a call with amount 0 passes both _spendAllowance (0 < 0 is false) and the balance check (0 < 0 is false), so any unprivileged caller can make the token emit Transfer(from: address(0), to: anyAddress, value: 0) at any time after the constructor. Indexers, explorers and launch monitoring treat Transfer from address(0) as a mint, so an outsider can fabricate post-launch 'mint' events against a token whose guarantee is that supply is fixed and minted only once. No balance or totalSupply changes (impact is limited to event and off-chain trust, hence low). Fix: add `if (from == address(0)) revert ERC20InvalidSender(address(0));` in _transfer (with a matching error), mirroring the receiver check.","line":138,"path":"src/BITESToken.sol","proof":"// SPDX-License-Identifier: MIT\npragma solidity 0.8.26;\n\nimport {Test} from \"forge-std/Test.sol\";\nimport {BITESToken} from \"src/BITESToken.sol\";\n\ncontract ZeroSenderTest is Test {\n    event Transfer(address indexed from, address indexed to, uint256 value);\n\n    function test_zeroAddressCannotSend() public {\n        BITESToken token = new BITESToken();\n        address stranger = address(0xBEEF);\n        // Documented: \"the zero address can neither send nor receive\" (OpenZeppelin v5 semantics).\n        vm.prank(stranger);\n        vm.expectRevert();\n        token.transferFrom(address(0), stranger, 0);\n    }\n}","reproduction":"Deploy BITESToken (deployer holds 10,000,000e18). From any EOA, e.g. 0xBEEF (no balance, no allowance), call transferFrom(address(0), 0xBEEF, 0). Expected (per NatSpec / OZ v5): revert ERC20InvalidSender(address(0)). Actual: returns true and emits Transfer(0x0000000000000000000000000000000000000000, 0x000000000000000000000000000000000000bEEF, 0), a log identical in shape to a mint. transfer(X, 0) from address(0) cannot be reached (msg.sender != 0), so transferFrom is the only path. Verified with forge: the test in `proof` fails with 'next call did not revert as expected' and the trace shows the emitted Transfer from address(0).","severity":"low","snippet":"    function _transfer(address from, address to, uint256 amount) private {\n        if (to == address(0)) revert ERC20InvalidReceiver(address(0));","title":"Missing zero-sender check lets anyone emit a forged mint event Transfer(address(0), X, 0) via transferFrom(address(0), X, 0)"}],"hash":"f23f4599e5e206b5ee1813c8da6284e681aa177d7e1b0c257cd641ff6eb8a233","nodeId":"8a020b63-3f90-4462-a6cc-bc05d523c348","outcome":"completed","summary":"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.\n\n**Finding 1 (low): `transferFrom` accepts the zero address as sender** (`src/BITESToken.sol:138`)\n- **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\".\n- **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.\n- **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.\n- **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.\n- **Fix:** add `if (from == address(0)) revert ERC20InvalidSender(address(0));` in `_transfer`, next to the receiver check.\n\n**What I checked against the Access Control, Trust Gap and Asymmetry guides:**\n- **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.\n- **Trust Gap:** no privileged actor or price formula exists, so there is no case where a permitted caller can extract value.\n- **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.\n- **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.\n\n**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.\n\n**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).","treeHash":null,"usage":{"cachedInputTokens":403463,"inputTokens":14,"model":"claude-opus-5-5","outputTokens":5418,"runtime":"claude","turns":8,"wallClockMs":72625}}],"verification":[{"checks":[{"durationMs":1592,"exitCode":0,"name":"build","output":"Compiling 24 files with Solc 0.8.26\nSolc 0.8.26 finished in 1.45s\nCompiler run successful!\n","passed":true},{"durationMs":114,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 1 test for test/DeployBITESToken.t.sol:DeployBITESTokenTest\n[PASS] test_deployMintsSupplyToTheScriptCaller() (gas: 1111168)\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 527.82µs (244.09µs CPU time)\n\nRan 36 tests for test/BITESToken.t.sol:BITESTokenTest\n[PASS] testFuzz_allowanceAccounting(uint256,uint256) (runs: 256, μ: 183225, ~: 202426)\nLogs:\n  Bound result 770\n  Bound result 1061\n\n[PASS] testFuzz_transferAboveBalanceReverts(uint256,uint256) (runs: 256, μ: 102546, ~: 103400)\nLogs:\n  Bound result 4173185410922630178470299\n  Bound result 834251616620299903248850\n\n[PASS] testFuzz_transferConservesSupply(address,uint256) (runs: 256, μ: 87570, ~: 87779)\nLogs:\n  Bound result 1798723624928758130677079\n\n[PASS] test_RevertWhen_approveZeroAddressSpender() (gas: 32887)\n[PASS] test_RevertWhen_sendingEther() (gas: 35882)\n[PASS] test_RevertWhen_strangerPullsFromDeployer() (gas: 39702)\n[PASS] test_RevertWhen_transferExceedsBalance() (gas: 95828)\n[PASS] test_RevertWhen_transferFromEmptyAccount() (gas: 37629)\n[PASS] test_RevertWhen_transferFromExceedsAllowance() (gas: 145894)\n[PASS] test_RevertWhen_transferFromExceedsBalanceDespiteAllowance() (gas: 155758)\n[PASS] test_RevertWhen_transferFromToZeroAddress() (gas: 146339)\n[PASS] test_RevertWhen_transferFromWithoutAllowance() (gas: 96272)\n[PASS] test_RevertWhen_transferToZeroAddress() (gas: 90876)\n[PASS] test_approveOverwritesPreviousAllowance() (gas: 92303)\n[PASS] test_approveSetsAllowanceAndEmits() (gas: 64922)\n[PASS] test_approveZeroClearsAllowance() (gas: 87466)\n[PASS] test_constructorEmitsMintTransfer() (gas: 5513)\n[PASS] test_constructorMintsWholeSupplyToDeployer() (gas: 25105)\n[PASS] test_deployerIsWhoeverCreatesTheContract() (gas: 14388)\n[PASS] test_eachDeploymentIsIndependent() (gas: 53752)\n[PASS] test_launchFlowsMoveExactlyWhatTheySay() (gas: 389532)\n[PASS] test_metadata() (gas: 23682)\n[PASS] test_noMintOrAdminSelectorIncreasesSupply() (gas: 645633)\n[PASS] test_noPrivilegedSelectorMovesOrFreezesAHolder() (gas: 431015)\n[PASS] test_runtimeHasNoDelegatecallCallcodeOrSelfdestruct() (gas: 712952)\n[PASS] test_supplyIsTenMillionWithEighteenDecimals() (gas: 17270)\n[PASS] test_transferBetweenOrdinaryHoldersIsExact() (gas: 134682)\n[PASS] test_transferFromExactAllowanceLeavesZero() (gas: 178971)\n[PASS] test_transferFromSpendsAllowance() (gas: 214739)\n[PASS] test_transferFromWithMaxAllowanceDoesNotDecrement() (gas: 187746)\n[PASS] test_transferMovesExactAmountAndEmits() (gas: 88642)\n[PASS] test_transferToSelfKeepsBalance() (gas: 98290)\n[PASS] test_transferWholeBalance() (gas: 129829)\n[PASS] test_transferWholeSupplyAtOnce() (gas: 72856)\n[PASS] test_transferZeroAmountSucceeds() (gas: 44309)\n[PASS] test_unknownSelectorReverts() (gas: 26650)\nSuite result: ok. 36 passed; 0 failed; 0 skipped; finished in 10.12ms (40.49ms CPU time)\n\nRan 2 test suites in 10.89ms (10.65ms CPU time): 37 tests passed, 0 failed, 0 skipped (37 total tests)\n","passed":true},{"durationMs":60,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"BITESToken.approve(address,uint256)\",\"BITESToken.transfer(address,uint256)\",\"BITESToken.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":6,\"README.md\":123,\"foundry.toml\":21,\"launch.json\":24,\"remappings.txt\":1,\"script/DeployBITESToken.s.sol\":26,\"src/BITESToken.sol\":166,\"test/BITESToken.t.sol\":443,\"test/DeployBITESToken.t.sol\":20},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"5689b8b06304c28660909d103ac3aefc1758fc097500f888cc375e8d55bbf358","verifiedTreeHash":"278a76bf5de313fcae6988d1505eecf99674d2e3","verifierVersion":"0.1.0+788bb33f"},{"checks":[{"durationMs":1554,"exitCode":0,"name":"build","output":"Compiling 24 files with Solc 0.8.26\nSolc 0.8.26 finished in 1.41s\nCompiler run successful!\n","passed":true},{"durationMs":111,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 1 test for test/DeployBITESToken.t.sol:DeployBITESTokenTest\n[PASS] test_deployMintsSupplyToTheScriptCaller() (gas: 1111168)\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 436.68µs (218.81µs CPU time)\n\nRan 36 tests for test/BITESToken.t.sol:BITESTokenTest\n[PASS] testFuzz_allowanceAccounting(uint256,uint256) (runs: 256, μ: 185670, ~: 202444)\nLogs:\n  Bound result 58682994672735770928437940653742\n  Bound result 3\n\n[PASS] testFuzz_transferAboveBalanceReverts(uint256,uint256) (runs: 256, μ: 102823, ~: 103510)\nLogs:\n  Bound result 1123287340538852230764\n  Bound result 7428768769355832307737560\n\n[PASS] testFuzz_transferConservesSupply(address,uint256) (runs: 256, μ: 87667, ~: 87779)\nLogs:\n  Bound result 9999999999999999999999997\n\n[PASS] test_RevertWhen_approveZeroAddressSpender() (gas: 32887)\n[PASS] test_RevertWhen_sendingEther() (gas: 35882)\n[PASS] test_RevertWhen_strangerPullsFromDeployer() (gas: 39702)\n[PASS] test_RevertWhen_transferExceedsBalance() (gas: 95828)\n[PASS] test_RevertWhen_transferFromEmptyAccount() (gas: 37629)\n[PASS] test_RevertWhen_transferFromExceedsAllowance() (gas: 145894)\n[PASS] test_RevertWhen_transferFromExceedsBalanceDespiteAllowance() (gas: 155758)\n[PASS] test_RevertWhen_transferFromToZeroAddress() (gas: 146339)\n[PASS] test_RevertWhen_transferFromWithoutAllowance() (gas: 96272)\n[PASS] test_RevertWhen_transferToZeroAddress() (gas: 90876)\n[PASS] test_approveOverwritesPreviousAllowance() (gas: 92303)\n[PASS] test_approveSetsAllowanceAndEmits() (gas: 64922)\n[PASS] test_approveZeroClearsAllowance() (gas: 87466)\n[PASS] test_constructorEmitsMintTransfer() (gas: 5513)\n[PASS] test_constructorMintsWholeSupplyToDeployer() (gas: 25105)\n[PASS] test_deployerIsWhoeverCreatesTheContract() (gas: 14388)\n[PASS] test_eachDeploymentIsIndependent() (gas: 53752)\n[PASS] test_launchFlowsMoveExactlyWhatTheySay() (gas: 389532)\n[PASS] test_metadata() (gas: 23682)\n[PASS] test_noMintOrAdminSelectorIncreasesSupply() (gas: 645633)\n[PASS] test_noPrivilegedSelectorMovesOrFreezesAHolder() (gas: 431015)\n[PASS] test_runtimeHasNoDelegatecallCallcodeOrSelfdestruct() (gas: 712952)\n[PASS] test_supplyIsTenMillionWithEighteenDecimals() (gas: 17270)\n[PASS] test_transferBetweenOrdinaryHoldersIsExact() (gas: 134682)\n[PASS] test_transferFromExactAllowanceLeavesZero() (gas: 178971)\n[PASS] test_transferFromSpendsAllowance() (gas: 214739)\n[PASS] test_transferFromWithMaxAllowanceDoesNotDecrement() (gas: 187746)\n[PASS] test_transferMovesExactAmountAndEmits() (gas: 88642)\n[PASS] test_transferToSelfKeepsBalance() (gas: 98290)\n[PASS] test_transferWholeBalance() (gas: 129829)\n[PASS] test_transferWholeSupplyAtOnce() (gas: 72856)\n[PASS] test_transferZeroAmountSucceeds() (gas: 44309)\n[PASS] test_unknownSelectorReverts() (gas: 26650)\nSuite result: ok. 36 passed; 0 failed; 0 skipped; finished in 10.90ms (38.66ms CPU time)\n\nRan 2 test suites in 11.76ms (11.34ms CPU time): 37 tests passed, 0 failed, 0 skipped (37 total tests)\n","passed":true},{"durationMs":44,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"BITESToken.approve(address,uint256)\",\"BITESToken.transfer(address,uint256)\",\"BITESToken.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":6,\"README.md\":123,\"foundry.toml\":21,\"remappings.txt\":1,\"script/DeployBITESToken.s.sol\":26,\"src/BITESToken.sol\":166,\"test/BITESToken.t.sol\":443,\"test/DeployBITESToken.t.sol\":20},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true},{"durationMs":502,"exitCode":0,"name":"slither","output":"slither: no results at low impact or above","passed":true},{"durationMs":188,"exitCode":0,"name":"aderyn","output":"[low] large-numeric-literal at src/BITESToken.sol:47: Large Numeric Literal","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"71e25ac762283a0d5d4bec10aa36bffc718c46fea663e80025787195b32ef7dc","verifiedTreeHash":"fcc5597f136d036e047697cba7468bf8a59d1d1c","verifierVersion":"0.1.0+788bb33f"},{"checks":[{"durationMs":2450,"exitCode":0,"name":"build","output":"Compiling 27 files with Solc 0.8.26\nSolc 0.8.26 finished in 2.29s\nCompiler run successful!\n","passed":true},{"durationMs":17893,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 1 test for test/DeployBITESToken.t.sol:DeployBITESTokenTest\n[PASS] test_deployMintsSupplyToTheScriptCaller() (gas: 1111168)\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 472.97µs (219.90µs CPU time)\n\nRan 18 tests for test/BITESToken.Properties.t.sol:BITESTokenPropertiesTest\n[PASS] testFuzz_approvalOverwriteIsIdempotentAndDoesNotMoveFunds(uint256,uint256) (runs: 1000, μ: 751507, ~: 751598)\n[PASS] testFuzz_insufficientAllowanceDoesNotMoveFunds(uint256,uint256) (runs: 1000, μ: 730562, ~: 731007)\nLogs:\n  Bound result 3624439005155845556924174\n  Bound result 6375560994844154499376839\n\n[PASS] testFuzz_insufficientBalanceRollsBackFiniteAllowance(uint256,uint256) (runs: 1000, μ: 788512, ~: 789294)\nLogs:\n  Bound result 8100\n  Bound result 115792089237316195423570985008687907853269984665640564039457584007913129631846\n\n[PASS] testFuzz_selfTransferPreservesBalancesButDelegatedSpendConsumesAllowance(uint256,uint256,uint256) (runs: 1000, μ: 814435, ~: 814919)\nLogs:\n  Bound result 7987431754569502406401601\n  Bound result 5941684458491414341053429\n  Bound result 115792089237316195423570985008687907853269984665640558097773126095772958552371\n\n[PASS] testFuzz_splitDelegatedSpendingCannotExceedGrant(uint256,uint256) (runs: 1000, μ: 836685, ~: 839241)\nLogs:\n  Bound result 5663857238702725065239\n  Bound result 4107822214141541150278\n\n[PASS] testFuzz_transferRoundTripRestoresBalances(uint256,uint256) (runs: 1000, μ: 755810, ~: 757704)\nLogs:\n  Bound result 8\n  Bound result 1\n\n[PASS] testFuzz_zeroRecipientPullRollsBackAnyAllowance(uint256,bool) (runs: 1000, μ: 676726, ~: 675864)\nLogs:\n  Bound result 8207242130035153131051663\n\n[PASS] test_allThreeTransferFromRolesMayBeTheSameAddress() (gas: 107981)\n[PASS] test_allowancesBelongToAnOrderedOwnerSpenderPair() (gas: 1599343)\n[PASS] test_failedZeroRecipientPullPreservesAllowanceForValidRetry() (gas: 754433)\n[PASS] test_fullSupplyDelegatedTransferExhaustsFiniteAllowance() (gas: 808916)\n[PASS] test_maximumMinusOneAllowanceIsFinite() (gas: 223525)\n[PASS] test_maximumTransferCannotWrapBalances() (gas: 1310114)\n[PASS] test_oneWeiCanMoveThroughEveryHolderAndReturnToDeployer() (gas: 245498)\n[PASS] test_selfTransferStillRequiresSufficientBalance() (gas: 1295874)\n[PASS] test_unlimitedAllowanceSurvivesRepeatedSpendsThenCanBeRevoked() (gas: 990222)\n[PASS] test_zeroAmountsStillRejectZeroReceiverAndSpender() (gas: 1853627)\n[PASS] test_zeroTransfersEmitEvenWithNoBalanceOrApproval() (gas: 663993)\nSuite result: ok. 18 passed; 0 failed; 0 skipped; finished in 418.31ms (2.89s CPU time)\n\nRan 36 tests for test/BITESToken.t.sol:BITESTokenTest\n[PASS] testFuzz_allowanceAccounting(uint256,uint256) (runs: 256, μ: 181112, ~: 202378)\nLogs:\n  Bound result 1445472508495433833756293257456605870430189814158877332998986\n  Bound result 4898227180943543632403851\n\n[PASS] testFuzz_transferAboveBalanceReverts(uint256,uint256) (runs: 256, μ: 102560, ~: 103462)\nLogs:\n  Bound result 430189814158877332998986\n  Bound result 7421949099918598402768699\n\n[PASS] testFuzz_transferConservesSupply(address,uint256) (runs: 256, μ: 87783, ~: 87767)\nLogs:\n  Bound result 1000000000000000000000\n\n[PASS] test_RevertWhen_approveZeroAddressSpender() (gas: 32887)\n[PASS] test_RevertWhen_sendingEther() (gas: 35882)\n[PASS] test_RevertWhen_strangerPullsFromDeployer() (gas: 39702)\n[PASS] test_RevertWhen_transferExceedsBalance() (gas: 95828)\n[PASS] test_RevertWhen_transferFromEmptyAccount() (gas: 37629)\n[PASS] test_RevertWhen_transferFromExceedsAllowance() (gas: 145894)\n[PASS] test_RevertWhen_transferFromExceedsBalanceDespiteAllowance() (gas: 155758)\n[PASS] test_RevertWhen_transferFromToZeroAddress() (gas: 146339)\n[PASS] test_RevertWhen_transferFromWithoutAllowance() (gas: 96272)\n[PASS] test_RevertWhen_transferToZeroAddress() (gas: 90876)\n[PASS] test_approveOverwritesPreviousAllowance() (gas: 92303)\n[PASS] test_approveSetsAllowanceAndEmits() (gas: 64922)\n[PASS] test_approveZeroClearsAllowance() (gas: 87466)\n[PASS] test_constructorEmitsMintTransfer() (gas: 5513)\n[PASS] test_constructorMintsWholeSupplyToDeployer() (gas: 25105)\n[PASS] test_deployerIsWhoeverCreatesTheContract() (gas: 14388)\n[PASS] test_eachDeploymentIsIndependent() (gas: 53752)\n[PASS] test_launchFlowsMoveExactlyWhatTheySay() (gas: 389532)\n[PASS] test_metadata() (gas: 23682)\n[PASS] test_noMintOrAdminSelectorIncreasesSupply() (gas: 645633)\n[PASS] test_noPrivilegedSelectorMovesOrFreezesAHolder() (gas: 431015)\n[PASS] test_runtimeHasNoDelegatecallCallcodeOrSelfdestruct() (gas: 712952)\n[PASS] test_supplyIsTenMillionWithEighteenDecimals() (gas: 17270)\n[PASS] test_transferBetweenOrdinaryHoldersIsExact() (gas: 134682)\n[PASS] test_transferFromExactAllowanceLeavesZero() (gas: 178971)\n[PASS] test_transferFromSpendsAllowance() (gas: 214739)\n[PASS] test_transferFromWithMaxAllowanceDoesNotDecrement() (gas: 187746)\n[PASS] test_transferMovesExactAmountAndEmits() (gas: 88642)\n[PASS] test_transferToSelfKeepsBalance() (gas: 98290)\n[PASS] test_transferWholeBalance() (gas: 129829)\n[PASS] test_transferWholeSupplyAtOnce() (gas: 72856)\n[PASS] test_transferZeroAmountSucceeds() (gas: 44309)\n[PASS] test_unknownSelectorReverts() (gas: 26650)\nSuite result: ok. 36 passed; 0 failed; 0 skipped; finished in 418.37ms (996.49ms CPU time)\n\nRan 1 test for test/BITESToken.Invariant.t.sol:BITESTokenInvariantTest\n[PASS]\nBITESTokenInvariantTest invariants:\n[PASS] invariant_allowancesEqualLatestGrantLessSuccessfulSpending\n[PASS] invariant_eachHolderOwnsExactlyItsAuthorizedNetReceipts\n[PASS] invariant_fixedSupplyEqualsAllHolderBalances\n BITESTokenInvariantTest invariants (runs: 256, calls: 32768, reverts: 0)\n\n╭-------------------+----------------------------+-------+---------+----------╮\n| Contract          | Selector                   | Calls | Reverts | Discards |\n+=============================================================================+\n| BITESTokenHandler | approve                    | 3303  | 0       | 0        |\n|-------------------+----------------------------+-------+---------+----------|\n| BITESTokenHandler | approveAndTransferFrom     | 3228  | 0       | 0        |\n|-------------------+----------------------------+-------+---------+----------|\n| BITESTokenHandler | rejectPullAboveBalance     | 3313  | 0       | 0        |\n|-------------------+----------------------------+-------+---------+----------|\n| BITESTokenHandler | rejectTransferAboveBalance | 3279  | 0       | 0        |\n|-------------------+----------------------------+-------+---------+----------|\n| BITESTokenHandler | rejectZeroReceiver         | 3197  | 0       | 0        |\n|-------------------+----------------------------+-------+---------+----------|\n| BITESTokenHandler | rejectZeroSpender          | 3225  | 0       | 0        |\n|-------------------+----------------------------+-------+---------+----------|\n| BITESTokenHandler | revokeAndRejectPull        | 3349  | 0       | 0        |\n|-------------------+----------------------------+-------+---------+----------|\n| BITESTokenHandler | transfer                   | 3262  | 0       | 0        |\n|-------------------+----------------------------+-------+---------+----------|\n| BITESTokenHandler | transferAll                | 3201  | 0       | 0        |\n|-------------------+----------------------------+-------+---------+----------|\n| BITESTokenHandler | transferFrom               | 3411  | 0       | 0        |\n╰-------------------+----------------------------+-------+---------+----------╯\n\nLogs:\n  Bound result 2\n  Bound result 0\n  Bound result 7404\n  Bound result 2\n  Bound result 0\n  Bound result 0\n  Bound result 5000000000000000000007406\n  Bound result 3\n  Bound result 0\n  Bound result 2\n  Bound result 2000000000000000000\n  Bound result 1\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 869\n  Bound result 2\n  Bound result 2\n  Bound result 2\n  Bound result 3310\n  Bound result 0\n  Bound result 0\n  Bound result 3\n  Bound result 0\n  Bound result 1\n  Bound result 1\n  Bound result 2\n  Bound result 0\n  Bound result 1\n  Bound result 0\n  Bound result 2\n  Bound result 115792089237316195423570985008687907853269984665640561539517584007913129647339\n  Bound result 2\n  Bound result 3\n  Bound result 2\n  Bound result 8485411765816238783738993177494355896042477855744708346372923027154\n  Bound result 1\n  Bound result 3\n  Bound result 1\n  Bound result 963\n  Bound result 0\n  Bound result 2\n  Bound result 1\n  Bound result 0\n  Bound result 3\n  Bound result 4\n  Bound result 1\n  Bound result 1\n  Bound result 2000000000000000000\n  Bound result 3\n  Bound result 2\n  Bound result 1\n  Bound result 1\n  Bound result 0\n  Bound result 1\n  Bound result 0\n  Bound result 1\n  Bound result 2\n  Bound result 2\n  Bound result 1\n  Bound result 3\n  Bound result 1\n  Bound result 1\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 3\n  Bound result 2\n  Bound result 409\n  Bound result 1\n  Bound result 0\n  Bound result 2\n  Bound result 2\n  Bound result 14\n  Bound result 3\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 5000000000000000001\n  Bound result 1\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 1\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 3\n  Bound result 2\n  Bound result 0\n  Bound result 3\n  Bound result 0\n  Bound result 0\n  Bound result 406\n  Bound result 3\n  Bound result 0\n  Bound result 0\n  Bound result 244\n  Bound result 0\n  Bound result 2\n  Bound result 1\n  Bound result 4132228330\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 255\n  Bound result 0\n  Bound result 0\n  Bound result 2\n  Bound result 1\n  Bound result 0\n  Bound result 1\n  Bound result 1\n  Bound result 0\n  Bound result 1\n  Bound result 2\n  Bound result 0\n  Bound result 2\n  Bound result 0\n  Bound result 2\n  Bound result 0\n  Bound result 1\n  Bound result 0\n  Bound result 1\n  Bound result 2\n  Bound result 0\n  Bound result 0\n  Bound result 2\n  Bound result 46229466542088147770734611903496552178369094106944315894641\n  Bound result 2\n  Bound result 2\n  Bound result 0\n  Bound result 0\n  Bound result 3\n  Bound result 9103\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 3\n  Bound result 3\n  Bound result 0\n  Bound result 0\n  Bound result 2\n  Bound result 0\n  Bound result 3\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 5000000000000000000\n  Bound result 2\n  Bound result 1\n  Bound result 3301\n  Bound result 1\n  Bound result 1\n  Bound result 0\n  Bound result 115792089237316195423570985008687907853269984665640554039457584007913129639942\n  Bound result 2\n  Bound result 0\n  Bound result 0\n  Bound result 96\n  Bound result 3\n  Bound result 1\n  Bound result 3\n  Bound result 1323\n  Bound result 1\n  Bound result 1\n  Bound result 300000000000000000000\n  Bound result 0\n  Bound result 0\n  Bound result 3\n  Bound result 0\n  Bound result 1\n  Bound result 0\n  Bound result 0\n  Bound result 1\n  Bound result 0\n  Bound result 1\n  Bound result 3\n  Bound result 673214595354857301401848920225568730594082113641163092959568178766580\n  Bound result 0\n  Bound result 1\n  Bound result 0\n  Bound result 115792089237316195423570985008687907853269984665640554039457584007913129642882\n  Bound result 0\n  Bound result 3\n  Bound result 0\n  Bound result 3\n  Bound result 2\n  Bound result 1\n  Bound result 115792089237316195423570985008687907853269984665640554039457584007913129641503\n  Bound result 3\n  Bound result 0\n  Bound result 0\n  Bound result 100000000000000000000\n  Bound result 1\n  Bound result 1\n  Bound result 1\n  Bound result 0\n  Bound result 2\n  Bound result 1193\n  Bound result 1\n  Bound result 0\n  Bound result 8275\n  Bound result 1\n  Bound result 3\n  Bound result 3\n  Bound result 0\n  Bound result 0\n  Bound result 127\n  Bound result 1\n  Bound result 3\n  Bound result 211801473\n  Bound result 2\n  Bound result 1\n  Bound result 3\n  Bound result 0\n  Bound result 2\n  Bound result 1\n  Bound result 0\n  Bound result 0\n  Bound result 2\n  Bound result 0\n  Bound result 1\n  Bound result 2\n  Bound result 2\n  Bound result 2\n  Bound result 2\n  Bound result 0\n  Bound result 0\n  Bound result 115\n  Bound result 0\n  Bound result 3\n  Bound result 3\n  Bound result 0\n  Bound result 244\n  Bound result 0\n  Bound result 1\n  Bound result 219\n  Bound result 3\n  Bound result 200000000000000000000\n  Bound result 2\n  Bound result 1\n  Bound result 2\n  Bound result 5091405235811787365042171\n  Bound result 0\n  Bound result 0\n  Bound result 127\n  Bound result 0\n  Bound result 2\n  Bound result 3309720243313899475007193\n  Bound result 2\n  Bound result 0\n  Bound result 7755\n  Bound result 2\n  Bound result 0\n  Bound result 1\n  Bound result 1\n  Bound result 2\n  Bound result 1\n  Bound result 8100\n  Bound result 1\n  Bound result 1\n  Bound result 3721\n  Bound result 1\n  Bound result 1\n  Bound result 4908594764188212423164702\n  Bound result 1\n  Bound result 3\n  Bound result 3\n  Bound result 5\n  Bound result 1\n  Bound result 2\n  Bound result 0\n  Bound result 2\n  Bound result 3\n  Bound result 3\n  Bound result 0\n  Bound result 100\n  Bound result 1\n  Bound result 0\n  Bound result 1\n  Bound result 2\n  Bound result 4973313763544551823143406211387587930849241988850840818009769149814660\n  Bound result 0\n  Bound result 0\n  Bound result 2\n  Bound result 535796229078821971320105\n  Bound result 3\n  Bound result 2\n  Bound result 6253667669229273119571982861386594547503151821673443064947029\n  Bound result 2\n  Bound result 0\n  Bound result 2\n  Bound result 2\n  Bound result 215\n  Bound result 0\n  Bound result 115792089237316195423570985008687907853269984665640559666659048898522677795699\n  Bound result 2\n  Bound result 2\n  Bound result 3\n  Bound result 2\n  Bound result 115792089237316195423570985008687907853269984665640563503661354929090946526314\n  Bound result 3\n  Bound result 2\n  Bound result 3\n  Bound result 1808\n  Bound result 0\n  Bound result 1\n  Bound result 0\n  Bound result 0\n  Bound result 3\n  Bound result 2\n  Bound result 2351\n  Bound result 0\n  Bound result 1\n  Bound result 0\n  Bound result 3\n  Bound result 115792089237316195423570985008687907853269984665640564039457584007913129639934\n  Bound result 3\n  Bound result 0\n  Bound result 2\n  Bound result 1\n  Bound result 1\n  Bound result 1\n  Bound result 3\n  Bound result 0\n  Bound result 115792089237316195423570985008687907853269984665640559666659048898522677793112\n  Bound result 2\n  Bound result 0\n  Bound result 3\n  Bound result 10000\n  Bound result 2\n  Bound result 3\n  Bound result 1\n  Bound result 2000000000000000000\n  Bound result 2\n  Bound result 2\n  Bound result 6000383563883855583610\n  Bound result 1\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 1000\n  Bound result 0\n  Bound result 2\n  Bound result 3\n  Bound result 512\n  Bound result 0\n  Bound result 3\n  Bound result 284\n  Bound result 3\n  Bound result 0\n  Bound result 1\n  Bound result 2129247630085467158595967\n  Bound result 3\n  Bound result 1\n  Bound result 0\n  Bound result 0\n  Bound result 1\n  Bound result 0\n  Bound result 2\n  Bound result 0\n  Bound result 3\n  Bound result 0\n\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 17.79s (17.78s CPU time)\n\nRan 4 test suites in 17.79s (18.62s CPU time): 56 tests passed, 0 failed, 0 skipped (56 total tests)\n","passed":true},{"durationMs":56,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"BITESToken.approve(address,uint256)\",\"BITESToken.transfer(address,uint256)\",\"BITESToken.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":6,\"README.md\":123,\"foundry.toml\":21,\"remappings.txt\":1,\"script/DeployBITESToken.s.sol\":26,\"src/BITESToken.sol\":166,\"test/BITESToken.Invariant.t.sol\":87,\"test/BITESToken.Properties.t.sol\":350,\"test/BITESToken.t.sol\":443,\"test/DeployBITESToken.t.sol\":20,\"test/README.md\":42,\"test/handlers/BITESTokenHandler.sol\":190},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"9399181cc80795cddcc42b4fcdf68374afc2285a3b21cb57ac534a8e62a896fb","verifiedTreeHash":"52096106ab400fcc2ece0fbcb4ac68c0ab5d15e3","verifierVersion":"0.1.0+788bb33f"}]}