{"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":"fca92127-43da-43c7-be65-f6569d2ca679","kind":"shape:chain","nodes":[{"acceptedSubmissionHash":"c302bc35240ebd00509287ac322be743881c3e688898d41910e571a1c1b3386a","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":"316eaccae36ac66ad1c10aa9075f60ec041f7e3df4cab30a8be89099a8550731","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":"b553551e882b74409a2b26f7f0afb5ad1a95adbfecfd2a2cac3514db3a1732f1","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":"d3e2fbbbcd8aa3ecc0f12bf04e638e057022c96a37cf768d8a9668c5e98efab2","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":"2033ffe860c43cbe599441f9d221d8b03a2763f14763acdf5db535ed4e4e3ab8","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":"445947ff4ee273ebb3dac6d5e5796eb86670ed28a17acb486d452f40680bffc9","dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"d59561da3b378461b7c749f6bd5084477d44993aa94972ddea90f542535751df","skillId":"build-contract-project","tools":[]},"key":"build_contract_project","kind":"code","role":"implement","skillHash":"d59561da3b378461b7c749f6bd5084477d44993aa94972ddea90f542535751df","skillId":"build-contract-project","state":"accepted"},{"acceptedSubmissionHash":"84082da4c23937c0a2444d3bdc84aea939ed9a4d9cdd0a56dde83639c7352355","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"tools":[]},"key":"manifest","kind":"code","role":"integrate","skillHash":null,"skillId":null,"state":"accepted"},{"acceptedSubmissionHash":"449bfd7f7f042c3af71a4a006888a3b5406df4541d6a27bbb3f0736334c18332","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"4c76766b00591dfe982fe85d3de589fdb2f810e5137c301155d1c5e36a1d3b23","skillId":"write-foundry-tests","tools":[]},"key":"write_foundry_tests","kind":"code","role":"tests","skillHash":"4c76766b00591dfe982fe85d3de589fdb2f810e5137c301155d1c5e36a1d3b23","skillId":"write-foundry-tests","state":"accepted"}],"objective":"A custom token: SwarmCore (SWARMCORE).\nToken name: SwarmCore\nToken symbol: SWARMCORE\nToken supply: 1,000,000,000 with 18 decimals, all minted once to the deployer in the constructor.","parentJobId":null,"planHash":"34ececd97224efdb7a3f01b0cc8d8fcf9f6275eabdbc1d43175e5f54700e29c0","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"fca92127-43da-43c7-be65-f6569d2ca679","publication":{"commit":null,"deliveredAt":null,"repoUrl":"https://github.com/identity-md-launches/launch-1966-swarmcore"},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[],"schema":"identitymd-work-v1","signals":[{"agentId":"52605","feedbackHash":"811d71d06771f37610b14752433719d15d584cb42dd2762ba4a85c41736fa4c8","nodeKey":"audit_economics","submissionHash":"c302bc35240ebd00509287ac322be743881c3e688898d41910e571a1c1b3386a","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52624","feedbackHash":"529f9810045d475560b54e34b0c82d6f6bac74b73a16b47d4d14c96e99d5c47a","nodeKey":"audit_flow","submissionHash":"316eaccae36ac66ad1c10aa9075f60ec041f7e3df4cab30a8be89099a8550731","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51465","feedbackHash":"1c321152eaa5e700146e7035bf588d0533c57ad5cc379a6a0aff000d4d25ec91","nodeKey":"audit_judge","submissionHash":"b553551e882b74409a2b26f7f0afb5ad1a95adbfecfd2a2cac3514db3a1732f1","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52617","feedbackHash":"7655016180e452a1536a4f56a29b1328cc3643cb6b80cb97723aeb54f8555d9e","nodeKey":"audit_math","submissionHash":"d3e2fbbbcd8aa3ecc0f12bf04e638e057022c96a37cf768d8a9668c5e98efab2","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52627","feedbackHash":"43ad220f3c5e79185755d0e9d2dce09f57600193fb86583ac90923d1d728020b","nodeKey":"audit_permissions","submissionHash":"2033ffe860c43cbe599441f9d221d8b03a2763f14763acdf5db535ed4e4e3ab8","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52257","feedbackHash":"dc32681ffbd70ecbac471bd02c83bd6d96f0c3b4e1fbaf66ef722bc5b330cde9","nodeKey":"build_contract_project","submissionHash":"445947ff4ee273ebb3dac6d5e5796eb86670ed28a17acb486d452f40680bffc9","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"52611","feedbackHash":"76fdc0adc859e78e75e0eece168c8b25ab5cd35867598441a9116bc3884eedae","nodeKey":"manifest","submissionHash":"84082da4c23937c0a2444d3bdc84aea939ed9a4d9cdd0a56dde83639c7352355","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"52623","feedbackHash":"ca97615a6f1f99e231d51d8630fc7493d66f79abb6c0a379e7419f4b88be314f","nodeKey":"write_foundry_tests","submissionHash":"449bfd7f7f042c3af71a4a006888a3b5406df4541d6a27bbb3f0736334c18332","tag1":"verification:checks","tag2":"acceptance-v2","value":1}],"site":null,"snapshotHash":"eb72d754d2c04cb99d45201164174c4ea59dd2176be4c86aee8dead7dcfa0ba8","state":"completed","submissions":[{"artifacts":[],"attempt":1,"bundleHash":null,"device":"aefe32dd2527eb68","findings":[{"citation":"resolved","description":"Asymmetry between the paired surfaces: approve() rejects the zero address as spender (line 87) and _transfer() rejects the zero address as receiver (line 103), but neither transferFrom() nor _transfer() rejects the zero address as the sender. OpenZeppelin v5, whose ERC-6093 error names this contract adopts, reverts with ERC20InvalidSender(address(0)) on this path. Here _spendAllowance(address(0), msg.sender, 0) passes (allowance 0 is not < 0), _transfer(address(0), to, 0) passes the balance check (0 < 0 is false), and a Transfer(address(0), to, 0) event is emitted. By ERC-20 convention a Transfer whose from is the zero address denotes a mint, so any unprivileged caller can write a zero-value, mint-shaped event naming any address into the token's log. No balance or supply changes and no value is moved, so there is no loss; the exposure is limited to log spoofing against indexers, explorers or off-chain accounting that interpret from == address(0) as issuance, and to a deviation from the OpenZeppelin semantics the contract otherwise mirrors. Not a launch-floor failure; reported so the author can decide whether to add the ERC20InvalidSender guard (if (from == address(0)) revert ERC20InvalidSender(address(0)); in _transfer, with the matching ERC-6093 error declared). A non-zero value on this path is correctly refused by the allowance check (ERC20InsufficientAllowance(spender, 0, value)), verified.","line":96,"path":"src/SwarmCore.sol","reproduction":"State: fresh deployment, any caller ATTACKER=0xBEEF with no balance and no allowance. Call: vm.prank(0xBEEF); token.transferFrom(address(0), 0xA11CE, 0). Expected (OpenZeppelin v5 semantics, and symmetric with the zero-address checks in approve and _transfer): revert ERC20InvalidSender(address(0)). Actual: returns true and emits Transfer(from=0x0000000000000000000000000000000000000000, to=0xA11CE, value=0); totalSupply and all balances unchanged. Control: token.transferFrom(address(0), 0xA11CE, 1) from the same caller reverts with ERC20InsufficientAllowance(0xBEEF, 0, 1). Both verified with a Foundry test under test/scratch (3 tests, all pass on this code; the first asserts exactly one Transfer log with topics[1] == bytes32(0)).","severity":"info","snippet":"    function transferFrom(address from, address to, uint256 value) external returns (bool) {\n        _spendAllowance(from, msg.sender, value);\n        _transfer(from, to, value);","title":"transferFrom accepts from == address(0) for value 0, letting anyone emit a mint-shaped Transfer(address(0), x, 0) event"}],"hash":"2033ffe860c43cbe599441f9d221d8b03a2763f14763acdf5db535ed4e4e3ab8","nodeId":"22f9d148-2a5a-4385-88dc-3d4c6f5bae74","outcome":"completed","summary":"The review is complete. The findings file is written and validated, the snippet matches the source lines exactly, and the scratch test is removed so the tree is unchanged.\n\n**Outcome.** SwarmCore holds up under the Access Control, Trust Gap and Asymmetry guides. One informational finding is recorded, nothing at medium or above.\n\n**What I checked**\n\n- **Access control.** The token has no owner, roles, modifiers, initializer, fallback or receive. Every state write is gated on the caller's own balance or allowance. The deployer cannot pull from a holder, and a holder cannot pull from the deployer. This was confirmed by the project's 30 tests and my own scratch test.\n- **Trust gap.** There is no privileged actor, no price or fee formula and no settable parameter, so none of the four seams has an actor or value flow to combine.\n- **Asymmetry.** I diffed `approve` against `_spendAllowance`, `transfer` against `transferFrom`, and all writers and readers of the two mappings. The only mismatch is the finding below.\n- **Launch floor.** The constructor takes no arguments, calls nothing, and mints exactly the manifest supply to `msg.sender`. Transfers move whole amounts, so the distributor, pool seed and swap flows arrive exact. The opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT passes.\n- **Static analysis leads.** Slither reported nothing. Aderyn's large-numeric-literal note on the supply constant is a style remark, not a defect.\n\n**The one finding (info).** The function `transferFrom` accepts the zero address as the sender when the value is zero. The allowance check passes because zero is not below zero, and the balance check passes the same way. Any unprivileged caller can therefore emit a mint-shaped event of the form Transfer from the zero address to any target with value zero. No balance or supply changes. OpenZeppelin v5, whose error names the contract adopts, rejects this path with ERC20InvalidSender. A non-zero value on the same path is correctly refused by the allowance check. I verified both with a Foundry test before reporting.\n\n**Coverage.** All three ABI entry points have rows. The approve and transfer rows hold. The transferFrom row points to the info finding. Four further rows record the constructor, the no-privileged-role invariant, the supply conservation invariant, the opcode invariant and the trust-gap seams, all holding.\n\n**Not reached.** Nothing within the assigned area was left unexamined. I did not exercise a live Uniswap v4 PoolManager swap, since the protected floor test does that with its own harness and the token has no transfer rules that could affect it.","treeHash":null,"usage":{"cachedInputTokens":586715,"inputTokens":258,"model":"claude-fable-5-1","outputTokens":12033,"runtime":"claude","turns":25,"wallClockMs":184260}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"af4be7a5238dbcbf","findings":[],"hash":"316eaccae36ac66ad1c10aa9075f60ec041f7e3df4cab30a8be89099a8550731","nodeId":"7ca1fddc-23f8-4f14-82f7-8815e490287c","outcome":"completed","summary":"The review is complete and the findings file is written.\n\n**Result: no defects found.** `.imd-findings.json` holds an empty findings list and eight coverage rows, one for each of the three state-changing entry points plus the constructor and four invariant and periphery rows.\n\n**What I checked, against the Execution Trace, Periphery and First Principles guides:**\n- `transfer` and `transferFrom` reject the zero receiver, check balance before the unchecked subtraction, and handle self-transfers correctly despite the cached balance read. No external calls exist, so there are no stale reads, callbacks or untrusted return values.\n- `approve` overwrites rather than adds, rejects a zero spender, and the unlimited-allowance sentinel in `_spendAllowance` only skips the decrement, never the balance check.\n- The constructor mints exactly 1e27 to `msg.sender`, which I confirmed equals the README literal, with one Transfer event and no arguments.\n- The runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, and in fact no CALL, STATICCALL or CREATE at all. Storage holds only balances and allowances, so there is no owner or pause slot to abuse.\n- A scratch fuzz suite I wrote and then removed ran 256 interleaved sequences of transfer, approve and transferFrom across four actors and always conserved the supply. Settle-style balance-difference checks showed exact arrivals for the launch flows.\n- The test harness in `test/utils/Harness.sol` was reviewed as periphery. Its cheatcode signatures, `bound` helper and opcode scanner are correct, and all 30 project tests plus `forge fmt --check` pass on forge 1.8.3.\n\n**Not run locally:** a real Uniswap v4 PoolManager seed and swap, since the tree has no `lib/`. The token has no code path that could make those flows differ from a plain transfer, and the protected floor tests exercise them.\n\nThe approve front-running race is inherent to ERC-20, is documented in the README, and is not reported as a defect. The static-analysis lead about a large numeric literal resolved to the correct value.","treeHash":null,"usage":{"cachedInputTokens":808070,"inputTokens":450,"model":"claude-fable-5-1","outputTokens":12594,"runtime":"claude","turns":15,"wallClockMs":184676}},{"artifacts":[],"attempt":1,"bundleHash":"b32627aeae20f967d09e8b9c6415a501a6f4505a2cddddca30dc3cea337d0914","device":"22c9b760d0a15149","findings":[],"hash":"445947ff4ee273ebb3dac6d5e5796eb86670ed28a17acb486d452f40680bffc9","nodeId":"7ec3dee2-00db-4351-bfa2-042351e58e66","outcome":"completed","summary":"The SwarmCore token project is written and complete, but I could not run forge on this machine: every Bash command failed before starting with the sandbox error below, so build, test and fmt checks are unverified here.\n\n```\napply-seccomp: write /proc/self/setgroups (nested userns is capability-restricted; caller must provide CAP_SYS_ADMIN): Permission denied\n```\n\n**What was delivered** (all at the repository root, self-contained, no vendored dependencies):\n\n- `src/SwarmCore.sol` is a plain fixed-supply ERC-20. The constructor takes no arguments, calls nothing, and mints 1,000,000,000 × 10^18 to `msg.sender` once. There is no owner, mint, burn, pause, blocklist, fee, delegatecall or selfdestruct, and failures revert with ERC-6093 custom errors. This satisfies every check in the pinned protected floor test: exact launch flows, no supply growth, no privileged hand, no forbidden opcodes.\n- `test/SwarmCore.t.sol` holds 29 tests covering metadata, the single mint event, transfer and transferFrom success and failure paths, allowance semantics including the unlimited case, the same admin and freeze selector lists the floor uses, the launch flows arriving whole, the opcode scan, and five fuzz tests on supply conservation and revert bounds.\n- `test/utils/Harness.sol` declares the handful of cheatcodes used against the hevm cheatcode address and a small assertion base, so no `lib/` or submodule is needed and the offline verifier has nothing to resolve.\n- `foundry.toml` pins solc 0.8.26, sets bytecode_hash to none, keeps ffi off and fs_permissions empty.\n- `README.md` documents assumptions, the launch's deployment parameters, the empty \"After launch\" section, operational responsibilities and the security checklist mapping.\n\n**What is unverified.** The code was reviewed by eye for compile errors, overload resolution and fuzz bounds, but `forge build`, `forge test` and `forge fmt --check` never ran because the shell sandbox could not start. If the verifier's run surfaces a compile error, the most likely spots are the hand-declared `Vm` interface in the harness and the inline string array literals in the two selector-list tests. Slither and Mythril were not available and were not run.","treeHash":"bf76a811b15732215b3d4f846530377029035a88","usage":{"cachedInputTokens":806548,"inputTokens":418,"model":"claude-fable-5-1","outputTokens":41011,"runtime":"claude","turns":26,"wallClockMs":443294}},{"artifacts":[],"attempt":1,"bundleHash":"455596298c42eb34bbdc752aa19ae3af3ed810adcce4b06f6475086b10f8f32b","device":"a800aae85243bc87","findings":[{"description":"_transfer checks the receiver but never the sender. Because _spendAllowance passes when value is 0 (0 < 0 is false) and _balances[address(0)] is 0, anyone can call transferFrom(address(0), anyone, 0) and it succeeds, emitting Transfer(address(0), anyone, 0). No balance or supply changes, so conservation holds and nothing of value is at risk; but the event has exactly the shape indexers and explorers read as a mint, and the contract's documentation says the only Transfer from the zero address is the single mint at deployment. OpenZeppelin v5, whose ERC-6093 errors this contract adopts, rejects this with ERC20InvalidSender(address(0)). A one-line check at the top of _transfer (if (from == address(0)) revert ERC20InvalidSender(address(0));) closes it. The invariant and unit suites submitted do not assert the current behaviour as correct; they leave it uncovered and report it here instead.","line":102,"path":"src/SwarmCore.sol","reproduction":"Deploy SwarmCore from 0xFAC7. From 0xBEEF call transferFrom(address(0), 0xBEEF, 0). Expected (per the contract's own documentation and OpenZeppelin v5 semantics): revert. Actual: returns true and emits Transfer(from=0x0, to=0xBEEF, value=0); totalSupply and every balance are unchanged. Verified with forge 1.8.3 in a scratch test: the call succeeds and exactly one Transfer log is emitted with topics[1] == bytes32(0).","severity":"info","title":"transferFrom accepts the zero address as sender for a zero amount and emits a mint-shaped Transfer event"}],"hash":"449bfd7f7f042c3af71a4a006888a3b5406df4541d6a27bbb3f0736334c18332","nodeId":"6bfd3046-00dc-422e-a243-3d41643519b6","outcome":"completed","summary":"Done. The suite builds and passes with the verifier's seed: 55 tests across three files, no failures.\n\n**What I added** (all under `test/`, nothing else touched):\n\n- `test/SwarmCore.invariant.t.sol`: a handler that drives the token from a closed set of 8 actors (deployer, holders, a distributor and claimant stand-in, a spender, a cold wallet) with bounded inputs and a ghost ledger of balances, allowances, inflows and outflows. Happy paths are mirrored in the ledger. Failure paths (transfer above balance, to the zero address, transferFrom above allowance or balance, approving the zero spender, any selector outside the ERC-20 interface) are asserted to revert with the exact ERC-6093 error and move nothing. Seven invariants run after every call: balances sum to the fixed supply, totalSupply and decimals never change, balances and allowances match the ledger, nobody holds more than they received, outsiders and the token itself hold nothing, and the deployer's balance equals supply less net outflow. Config is inline: 256 runs, depth 64, fail on revert.\n- `test/SwarmCore.edges.t.sol`: 24 unit and fuzz tests for the inputs the existing suite did not pin. Allowance of max minus one is spent down, not treated as unlimited. Transfers of the maximum uint and supply plus one revert with the right arguments. The same transfer or transferFrom twice fails once exhausted. Allowance is checked before balance, receiver before balance. Self-approval, spender sending to itself, round trips to the owner. Truncated calldata, dirty address bits, empty calldata and random selectors are refused. A helper contract deploys the token and performs the three launch flows inside one constructor, so the launch is exercised as one transaction.\n- `test/utils/InvariantHarness.sol`: the target-contract and target-selector plumbing forge's invariant runner reads, since the project deliberately vendors no forge-std.\n\n**Verification**: I mutation-checked the invariant suite in scratch. A token that burns one wei per transfer fails at the first handler call. A token that treats an allowance of max minus one as unlimited was initially missed, so I added a near-unlimited approve path to the handler and a pinned unit test. Both mutants now fail the suite.\n\n**Finding reported** in `.imd-findings.json` as info, not asserted in tests: `transferFrom(address(0), anyone, 0)` succeeds and emits a Transfer from the zero address, indistinguishable in shape from a mint. No balance or supply changes, so nothing of value is at risk. OpenZeppelin v5 rejects this with ERC20InvalidSender, and a one-line sender check in `_transfer` closes it. The repository's own exclude rule keeps that file out of git status, which is expected.\n\nNo defects of medium or higher severity were found in the token.","treeHash":"03779c42de27ef5124301ea2b2951a19279804c6","usage":{"cachedInputTokens":988477,"inputTokens":418,"model":"claude-fable-5-1","outputTokens":33724,"runtime":"claude","turns":27,"wallClockMs":653915}},{"artifacts":[],"attempt":1,"bundleHash":"0b83e99ec8d33a7a001918ca2cb4aed2aa6cf9dafed2b8cc5f28a9ba3d9754f2","device":"2a4ad9be53991100","findings":[],"hash":"84082da4c23937c0a2444d3bdc84aea939ed9a4d9cdd0a56dde83639c7352355","nodeId":"3c71d75d-e9c4-4a3a-a6fd-4b560b6a22bb","outcome":"completed","summary":"Done. I wrote `launch.json` as the only new file; nothing else in the tree changed.\n\n**What the manifest says**\n\n- Kind is `custom_token`, token contract `SwarmCore`, name SwarmCore, symbol SWARMCORE, 18 decimals.\n- Constructor arguments are an empty list, matching the accepted contract's argument-free constructor.\n- Total supply is the exact amount the constructor mints to the deployer, in minor units.\n- The contracts list is empty, since the accepted tree contains only the token and no application contracts.\n- Pool and economics are copied verbatim from the launch reference: IMD as paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.\n- Notes describe the fixed supply, the absence of owner or transfer rules, and why no launch placeholders are needed.\n\n**Verification**\n\n- The file parses as JSON with only the six schema keys, and the notes are well under the 4,000 character limit.\n- The supply string and economics object were checked programmatically against the expected values.\n- The build compiles cleanly and all 30 tests pass with the verifier's fuzz seed.\n- `git status` shows `launch.json` as the only change.","treeHash":"557bdb3f8c6e2c384ac146e1a2ae96c2e21a886d","usage":{"cachedInputTokens":198903,"inputTokens":130,"model":"claude-fable-5-1","outputTokens":2964,"runtime":"claude","turns":11,"wallClockMs":42389}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"f0c4ae5b8ada215c","findings":[{"citation":"resolved","description":"Merged from audit_math, audit_permissions, audit_economics and write_foundry_tests, which all report the same root cause. `_transfer` (src/SwarmCore.sol:102-113) rejects the zero address only as receiver, never as sender, and `_spendAllowance` (lines 115-122) lets value 0 pass with allowance 0 because `0 < 0` is false. `transferFrom(address(0), to, 0)` therefore succeeds from any unprivileged caller and emits `Transfer(address(0), to, 0)`, the exact event shape of a mint. The contract's own NatSpec (line 16) says the only Transfer from the zero address is the single mint at deployment, and line 14 says errors follow OpenZeppelin v5 / ERC-6093, whose `_transfer` reverts here with `ERC20InvalidSender(address(0))`. No balance or supply changes (the sum of balances stays TOTAL_SUPPLY, `balanceOf(address(0))` stays 0, `totalSupply()` is a constant), nobody loses funds, and the launch floor is not affected. Impact is limited to off-chain consumers: explorers, indexers or accounting that classify a Transfer from the zero address as issuance will record phantom mints for arbitrary recipients at will, for a token whose documentation says nothing can mint after deployment. Severity low rather than info because it is a repeatable, permissionless deviation from the documented event semantics; not higher because value is always zero and nothing on-chain moves. Minimal fix that preserves the design: declare `error ERC20InvalidSender(address sender);` and add `if (from == address(0)) revert ERC20InvalidSender(address(0));` as the first line of `_transfer`. A control case verified the only input that slips past: `transferFrom(address(0), to, 1)` reverts with `ERC20InsufficientAllowance(caller, 0, 1)`.","line":103,"path":"src/SwarmCore.sol","reproduction":"State: fresh SwarmCore deployed by 0xFAC7 (holds 1e27). Caller 0xBEEF has no balance and no allowance. Call: vm.prank(0xBEEF); token.transferFrom(address(0), 0xB0B, 0). Expected (per the contract's stated OpenZeppelin v5 / ERC-6093 semantics and its line-16 NatSpec): revert ERC20InvalidSender(address(0)). Actual: returns true and emits exactly one log, Transfer with topics[1] == bytes32(0), topics[2] == bytes32(uint256(uint160(0xB0B))) and data == abi.encode(uint256(0)); balanceOf(0xB0B) == 0, balanceOf(address(0)) == 0, totalSupply() == 1e27. Control: vm.prank(0xBEEF); token.transferFrom(address(0), 0xB0B, 1) reverts with ERC20InsufficientAllowance(0xBEEF, 0, 1). Reproduced with forge 1.8.3 in test/scratch/ZeroFrom.t.sol (4 tests using the project's own test/utils/Harness.sol with vm.recordLogs; all assertions above pass against the current code).","severity":"low","snippet":"        if (to == address(0)) revert ERC20InvalidReceiver(address(0));","title":"transferFrom accepts address(0) as `from` for a zero value, so anyone can emit a mint-shaped Transfer(address(0), to, 0) event"}],"hash":"b553551e882b74409a2b26f7f0afb5ad1a95adbfecfd2a2cac3514db3a1732f1","nodeId":"8336616c-27d8-4b16-8daf-f6ba50c26cb4","outcome":"completed","summary":"The review is complete and `.imd-findings.json` is written. No tracked files were changed; the scratch test under test/scratch/ is ignored by git and not part of the submission.\n\n**Outcome.** One finding, severity low. All four specialists reported the same root cause, and I merged them into a single entry after reproducing it.\n\n- **The finding.** `_transfer` in src/SwarmCore.sol rejects the zero address only as receiver, and the allowance check passes a zero value with a zero allowance. Any caller can therefore run a zero-value `transferFrom` with the zero address as sender and emit a mint-shaped Transfer event. Nothing moves on chain and the supply stays constant. The impact is limited to explorers and indexers that read Transfer-from-zero as issuance, which contradicts the contract's own NatSpec and the OpenZeppelin v5 semantics it claims. The one-line fix is a sender-zero check with an ERC20InvalidSender error.\n- **Reproduction.** Confirmed with a scratch test using the project's own harness and recorded logs. The nonzero-value control reverts with ERC20InsufficientAllowance as expected, so this is the single input that slips past. No proof file is attached, since the severity is low and the tree vendors no forge-std.\n\n**Coverage.** All three ABI entry points are answered: approve and transfer hold, transferFrom carries the finding. I also recorded rows for the supply invariant, the launch floor (argless constructor, 18 decimals, no CALL-family opcodes in the runtime), the manifest schema, and the aderyn numeric-literal lead, all of which hold. The project's existing 55 tests, including the invariant suite, pass on this code.","treeHash":null,"usage":{"cachedInputTokens":365962,"inputTokens":194,"model":"claude-fable-5-1","outputTokens":8636,"runtime":"claude","turns":14,"wallClockMs":144944}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"c79042525fc4a50d","findings":[{"citation":"resolved","description":"The contract states (line 14) that its errors follow the ERC-6093 names used by OpenZeppelin v5, and OpenZeppelin v5's _transfer rejects from == address(0) with ERC20InvalidSender. SwarmCore has no such check: _transfer (lines 102-113) only rejects to == address(0). The only guard between an arbitrary `from` and the Transfer event is _spendAllowance, and for value == 0 it passes (0 < 0 is false) because nobody can ever set an allowance for owner address(0). So any unprivileged caller can make the token emit Transfer(address(0), anyAddress, 0), the exact shape of a mint event, at will and indefinitely after launch. No balance or supply changes (Invariant and Economic Security: sum of balances == TOTAL_SUPPLY holds; no funds move), so impact is limited to off-chain consumers: explorers and indexers that classify Transfer-from-zero as mints will show mint activity for a token whose documentation and launch floor say nothing can mint afterwards, and any accounting that counts mint events (rather than summing values) sees phantom mints. For value >= 1 the same call reverts with ERC20InsufficientAllowance(spender, 0, value), so this is the single input that slips past. Minimal fix that preserves the design: add `if (from == address(0)) revert ERC20InvalidSender(address(0));` to _transfer (declaring the ERC-6093 error), matching the stated OpenZeppelin v5 semantics.","line":96,"path":"src/SwarmCore.sol","reproduction":"State: fresh SwarmCore deployed by any deployer. Call: vm.prank(0xBEEF); token.transferFrom(address(0), 0xB0B, 0). Expected (per ERC-6093 / OpenZeppelin v5 semantics the contract claims): revert ERC20InvalidSender(address(0)). Actual: returns true and emits exactly one log Transfer(from=0x0000000000000000000000000000000000000000, to=0xB0B, value=0); totalSupply still 1e27, balanceOf(0xB0B) still 0. Verified with a Foundry test using vm.recordLogs (topics[1] == bytes32(0), topics[2] == 0xB0B, data == 0). Control: transferFrom(address(0), 0xB0B, 1) reverts with ERC20InsufficientAllowance(0xBEEF, 0, 1).","severity":"low","snippet":"    function transferFrom(address from, address to, uint256 value) external returns (bool) {\n        _spendAllowance(from, msg.sender, value);\n        _transfer(from, to, value);\n        return true;\n    }","title":"transferFrom accepts address(0) as `from` for a zero value and emits a spurious mint-shaped Transfer event"}],"hash":"c302bc35240ebd00509287ac322be743881c3e688898d41910e571a1c1b3386a","nodeId":"af86f918-cfcd-4c29-ba74-cd5d111c8b4d","outcome":"completed","summary":"The review is complete and `.imd-findings.json` is written. It validates as JSON, the snippet matches the tree at the cited line, and the scratch tests are removed so the working tree holds only the findings file.\n\n**Outcome.** SwarmCore holds up against the Economic Security, Invariant and Flow Gap guides. One low-severity defect was substantiated, no critical, high or medium.\n\n**Finding 1, low.** `transferFrom(address(0), to, 0)` succeeds for any caller and emits a zero-value `Transfer` from the zero address. The allowance check passes because zero is not less than zero, and `_transfer` only rejects a zero `to`. The contract says its errors follow OpenZeppelin v5's ERC-6093 set, but it lacks the `ERC20InvalidSender` guard that set includes. No balance or supply changes, so the harm is confined to indexers and explorers that treat transfers from zero as mints. Reproduced with a Foundry test capturing the log, with a control showing value 1 reverts as expected. The suggested fix is a one-line sender check in `_transfer`.\n\n**Coverage.** All three entry points have rows. `approve` and `transfer` hold. `transferFrom` carries the finding. I added rows for the invariants I checked: sum of balances equals the fixed supply under fuzzed random walks, no path grows or privilege-moves the supply, the launch flows arrive whole without exemptions, and the sentinel and dependency checks. The supply constant matches the manifest string in the README.\n\n**Checks run.** The project's 30 tests pass. My scratch probes passed on the quirk, self-transferFrom conservation, a four-actor random walk, and the max-minus-one allowance decrement. Both static analysis leads were benign: Slither reported nothing, and the aderyn large-literal note is the supply constant itself.\n\n**Not reached.** Nothing in the assigned area was left unexamined. The real PoolManager seed and swap could not be executed here since the protected harness imports v4-core and forge-std, which this repository does not vendor. The token's exact-transfer semantics make that flow mechanical, and the floor's own tests exercise it.","treeHash":null,"usage":{"cachedInputTokens":562435,"inputTokens":258,"model":"claude-fable-5-1","outputTokens":11449,"runtime":"claude","turns":20,"wallClockMs":173629}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"76df9026b98e4277","findings":[{"citation":"resolved","description":"Boundary guide, sentinel-address branch: `_transfer` checks the `to` side of the zero-address sentinel but not the `from` side, and `_spendAllowance` lets a zero `value` pass with a zero allowance (`0 < 0` is false). Through `transferFrom(address(0), to, 0)` any caller therefore emits `Transfer(address(0), to, 0)`, the exact event shape of a mint, with no balance change. OpenZeppelin v5's `_transfer` rejects this with `ERC20InvalidSender(address(0))`, and the token's own errors follow ERC-6093 so the omission is a divergence from the reference it mirrors. No tokens move and `totalSupply()` is a constant, so there is no loss and no supply drift; the only effect is that off-chain indexers or explorers that reconstruct mints from `Transfer` events from the zero address see spurious zero-value mint events for arbitrary recipients. Reported as informational because the value is always zero. Minimal fix that preserves behaviour: add `if (from == address(0)) revert ERC20InvalidSender(address(0));` at the top of `_transfer` (declaring the ERC-6093 error).","line":103,"path":"src/SwarmCore.sol","reproduction":"State: fresh SwarmCore deployed by 0xFAC7. Call as any account, e.g. 0xA11CE: `token.transferFrom(address(0), 0xB0B, 0)`. Expected (per OZ v5 / ERC-6093): revert ERC20InvalidSender(address(0)). Actual: returns true and emits exactly one log, Transfer with topics[1] == bytes32(0) and topics[2] == 0xB0B and data == 0. balanceOf(0xB0B) stays 0 and totalSupply() stays 1e27. Verified in a scratch test: test_zeroValueTransferFromFromAnyAccountEmits passed with these assertions against the current code.","severity":"info","snippet":"        if (to == address(0)) revert ERC20InvalidReceiver(address(0));","title":"transferFrom accepts address(0) as `from`, so anyone can emit a zero-value Transfer(address(0), to, 0) that looks like a mint"}],"hash":"d3e2fbbbcd8aa3ecc0f12bf04e638e057022c96a37cf768d8a9668c5e98efab2","nodeId":"61c38701-cf95-4ff5-812e-e5489f31af2c","outcome":"completed","summary":"The findings file is valid, the cited snippet matches line 103 exactly, and the scratch directory is removed. The tree shows no changes to tracked files; only the untracked `.imd-findings.json` output exists.\n\n## Review result\n\n**No math, boundary or numerical-gap defect found in SwarmCore.** The token has no division, no runtime multiplication, no external calls, no payable path and no bytes decoding, so most failure modes in the three guides have nothing to attach to. One informational divergence from the ERC-20 reference is recorded.\n\n**What I verified**\n\n- The supply literal on line 34 is a compile-time constant equal to exactly 1e27. This closes the aderyn large-numeric-literal lead.\n- The unchecked subtraction in `_transfer` is guarded by the balance check, and the unchecked addition cannot wrap because balances always sum to the fixed supply. Whole-balance self-transfer, zero value, and a value of max uint256 all behave correctly.\n- Allowance handling holds at every edge. Max is unlimited and never decremented, max minus one is finite and decremented, and the balance check still governs under an unlimited allowance.\n- A fuzzed sum-of-balances invariant over 8-step transfer chains with self-transfers passed 256 runs. The existing 30-test suite also passes.\n\n**One informational finding**\n\n`transferFrom(address(0), to, 0)` succeeds for any caller and emits a zero-value `Transfer` from the zero address, which has the exact shape of a mint event. OpenZeppelin v5 rejects this with `ERC20InvalidSender`. No tokens move and the supply is a constant, so the only effect is spurious zero-value mint events for indexers. The suggested fix is a single `from == address(0)` check at the top of `_transfer`.\n\n**Coverage** has rows for all three entry points plus four invariant rows. One limit: the protected pool-seed and swap test could not be run here because v4-core and the platform's launch sources are not vendored in this tree. The token transfers exact amounts, so nothing in my area threatens those flows.","treeHash":null,"usage":{"cachedInputTokens":671407,"inputTokens":418,"model":"claude-fable-5-1","outputTokens":10271,"runtime":"claude","turns":14,"wallClockMs":172439}}],"verification":[{"checks":[{"durationMs":354,"exitCode":0,"name":"build","output":"Compiling 3 files with Solc 0.8.26\nSolc 0.8.26 finished in 302.48ms\nCompiler run successful!\n","passed":true},{"durationMs":63,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 30 tests for test/SwarmCore.t.sol:SwarmCoreTest\n[PASS] testFuzz_aChainOfTransfersConservesTheSupply(uint256,uint256,uint256) (runs: 256, μ: 221606, ~: 226939)\n[PASS] testFuzz_transferAboveTheBalanceReverts(uint256,uint256) (runs: 256, μ: 90071, ~: 90710)\n[PASS] testFuzz_transferConservesTheSupply(address,uint256) (runs: 256, μ: 75718, ~: 76928)\n[PASS] testFuzz_transferFromAboveTheAllowanceReverts(uint256,uint256) (runs: 256, μ: 85531, ~: 86094)\n[PASS] testFuzz_transferFromSpendsExactlyTheAmount(uint256,uint256) (runs: 256, μ: 130501, ~: 131862)\n[PASS] test_approveSetsTheAllowanceAndEmits() (gas: 100180)\n[PASS] test_approveTheZeroAddressReverts() (gas: 30629)\n[PASS] test_constructorEmitsOneMintTransfer() (gas: 10790)\n[PASS] test_constructorMintsTheWholeSupplyToTheDeployer() (gas: 23189)\n[PASS] test_launchFlowsArriveWhole() (gas: 198740)\n[PASS] test_metadata() (gas: 33748)\n[PASS] test_noCommonAdminCallIncreasesSupply() (gas: 613723)\n[PASS] test_noOwnerAndNoPauseState() (gas: 70765)\n[PASS] test_noPrivilegedHandMovesOrFreezesAHolder() (gas: 437776)\n[PASS] test_plainEtherIsRefused() (gas: 33221)\n[PASS] test_runtimeHasNoDelegatecallOrSelfdestructAndFitsEip170() (gas: 547759)\n[PASS] test_transferFromAboveAllowanceReverts() (gas: 92515)\n[PASS] test_transferFromAboveBalanceRevertsEvenWithAllowance() (gas: 135309)\n[PASS] test_transferFromByTheOwnerStillNeedsAnAllowance() (gas: 33418)\n[PASS] test_transferFromSpendsTheAllowanceAndMovesTheTokens() (gas: 140806)\n[PASS] test_transferFromToTheZeroAddressReverts() (gas: 83487)\n[PASS] test_transferFromWithUnlimitedAllowanceKeepsIt() (gas: 120279)\n[PASS] test_transferFromWithoutAllowanceReverts() (gas: 37501)\n[PASS] test_transferMovesExactlyTheAmountAndEmits() (gas: 77980)\n[PASS] test_transferOfTheWholeBalanceSucceeds() (gas: 65437)\n[PASS] test_transferOfZeroSucceedsAndEmits() (gas: 42084)\n[PASS] test_transferRevertsFromAnEmptyAccount() (gas: 33123)\n[PASS] test_transferRevertsOnInsufficientBalance() (gas: 97107)\n[PASS] test_transferToSelfKeepsTheBalance() (gas: 95291)\n[PASS] test_transferToTheZeroAddressReverts() (gas: 34813)\nSuite result: ok. 30 passed; 0 failed; 0 skipped; finished in 14.58ms (64.77ms CPU time)\n\nRan 1 test suite in 15.64ms (14.58ms CPU time): 30 tests passed, 0 failed, 0 skipped (30 total tests)\n","passed":true},{"durationMs":33,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"SwarmCore.approve(address,uint256)\",\"SwarmCore.transfer(address,uint256)\",\"SwarmCore.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":4,\"README.md\":123,\"foundry.toml\":19,\"src/SwarmCore.sol\":123,\"test/SwarmCore.t.sol\":447,\"test/utils/Harness.sol\":76},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true},{"durationMs":587,"exitCode":0,"name":"slither","output":"slither: no results at low impact or above","passed":true},{"durationMs":327,"exitCode":0,"name":"aderyn","output":"[low] large-numeric-literal at src/SwarmCore.sol:34: Large Numeric Literal","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"445947ff4ee273ebb3dac6d5e5796eb86670ed28a17acb486d452f40680bffc9","verifiedTreeHash":"bf76a811b15732215b3d4f846530377029035a88","verifierVersion":"0.1.0+d952fceb"},{"checks":[{"durationMs":757,"exitCode":0,"name":"build","output":"Compiling 6 files with Solc 0.8.26\nSolc 0.8.26 finished in 712.31ms\nCompiler run successful!\n","passed":true},{"durationMs":15399,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 24 tests for test/SwarmCore.edges.t.sol:SwarmCoreEdgesTest\n[PASS] testFuzz_approveStoresAnyValueExactly(uint256) (runs: 1000, μ: 73179, ~: 73321)\n[PASS] testFuzz_launchInOneTransactionWithAnyPoolShare(uint256) (runs: 1000, μ: 243912, ~: 244253)\n[PASS] testFuzz_manySmallTransfersAmongThreeConserveTheSupply(uint8,uint256) (runs: 1000, μ: 2565223, ~: 625070)\n[PASS] testFuzz_nearUnlimitedAllowanceIsSpentDown(uint256,uint256) (runs: 1000, μ: 116550, ~: 117003)\n[PASS] testFuzz_unknownSelectorsAreRefused(bytes4,bytes,address) (runs: 1000, μ: 32021, ~: 31818)\n[PASS] test_allowanceIsCheckedBeforeBalance() (gas: 117514)\n[PASS] test_allowanceOfMaxMinusOneIsNotUnlimited() (gas: 170312)\n[PASS] test_approveEmitsEveryTimeEvenWhenUnchanged() (gas: 89115)\n[PASS] test_approveResetToZeroBlocksTheSpender() (gas: 105665)\n[PASS] test_dirtyAddressBitsAreRefused() (gas: 40862)\n[PASS] test_emptyCalldataIsRefused() (gas: 57219)\n[PASS] test_holderMayApproveAndSpendFromThemself() (gas: 118391)\n[PASS] test_launchInOneTransactionDeliversEveryFlowWhole() (gas: 255635)\n[PASS] test_receiverIsCheckedBeforeBalance() (gas: 30773)\n[PASS] test_spenderMaySendToThemself() (gas: 118062)\n[PASS] test_theSameTransferFromTwiceFailsOnceTheAllowanceIsSpent() (gas: 137491)\n[PASS] test_theSameTransferTwiceFailsOnceTheBalanceIsSpent() (gas: 136715)\n[PASS] test_transferFromOfMaxUintWithUnlimitedAllowanceReverts() (gas: 87707)\n[PASS] test_transferFromOfZeroNeedsNoAllowanceAndMovesNothing() (gas: 60689)\n[PASS] test_transferFromToTheOwnerSpendsTheAllowanceAndChangesNothingElse() (gas: 94253)\n[PASS] test_transferOfMaxUintReverts() (gas: 60721)\n[PASS] test_transferOfSupplyPlusOneReverts() (gas: 37481)\n[PASS] test_truncatedCalldataIsRefused() (gas: 39868)\n[PASS] test_unknownAccountsReadAsZero() (gas: 39171)\nSuite result: ok. 24 passed; 0 failed; 0 skipped; finished in 195.01ms (894.36ms CPU time)\n\nRan 30 tests for test/SwarmCore.t.sol:SwarmCoreTest\n[PASS] testFuzz_aChainOfTransfersConservesTheSupply(uint256,uint256,uint256) (runs: 256, μ: 222559, ~: 226927)\n[PASS] testFuzz_transferAboveTheBalanceReverts(uint256,uint256) (runs: 256, μ: 90429, ~: 90722)\n[PASS] testFuzz_transferConservesTheSupply(address,uint256) (runs: 256, μ: 76523, ~: 76916)\n[PASS] testFuzz_transferFromAboveTheAllowanceReverts(uint256,uint256) (runs: 256, μ: 85846, ~: 86106)\n[PASS] testFuzz_transferFromSpendsExactlyTheAmount(uint256,uint256) (runs: 256, μ: 130642, ~: 131874)\n[PASS] test_approveSetsTheAllowanceAndEmits() (gas: 100180)\n[PASS] test_approveTheZeroAddressReverts() (gas: 30629)\n[PASS] test_constructorEmitsOneMintTransfer() (gas: 10790)\n[PASS] test_constructorMintsTheWholeSupplyToTheDeployer() (gas: 23189)\n[PASS] test_launchFlowsArriveWhole() (gas: 198740)\n[PASS] test_metadata() (gas: 33748)\n[PASS] test_noCommonAdminCallIncreasesSupply() (gas: 613723)\n[PASS] test_noOwnerAndNoPauseState() (gas: 70765)\n[PASS] test_noPrivilegedHandMovesOrFreezesAHolder() (gas: 437776)\n[PASS] test_plainEtherIsRefused() (gas: 33221)\n[PASS] test_runtimeHasNoDelegatecallOrSelfdestructAndFitsEip170() (gas: 547759)\n[PASS] test_transferFromAboveAllowanceReverts() (gas: 92515)\n[PASS] test_transferFromAboveBalanceRevertsEvenWithAllowance() (gas: 135309)\n[PASS] test_transferFromByTheOwnerStillNeedsAnAllowance() (gas: 33418)\n[PASS] test_transferFromSpendsTheAllowanceAndMovesTheTokens() (gas: 140806)\n[PASS] test_transferFromToTheZeroAddressReverts() (gas: 83487)\n[PASS] test_transferFromWithUnlimitedAllowanceKeepsIt() (gas: 120279)\n[PASS] test_transferFromWithoutAllowanceReverts() (gas: 37501)\n[PASS] test_transferMovesExactlyTheAmountAndEmits() (gas: 77980)\n[PASS] test_transferOfTheWholeBalanceSucceeds() (gas: 65437)\n[PASS] test_transferOfZeroSucceedsAndEmits() (gas: 42084)\n[PASS] test_transferRevertsFromAnEmptyAccount() (gas: 33123)\n[PASS] test_transferRevertsOnInsufficientBalance() (gas: 97107)\n[PASS] test_transferToSelfKeepsTheBalance() (gas: 95291)\n[PASS] test_transferToTheZeroAddressReverts() (gas: 34813)\nSuite result: ok. 30 passed; 0 failed; 0 skipped; finished in 195.07ms (427.42ms CPU time)\n\nRan 1 test for test/SwarmCore.invariant.t.sol:SwarmCoreInvariantTest\n[PASS]\nSwarmCoreInvariantTest invariants:\n[PASS] invariant_allowancesMatchTheGhostLedger\n[PASS] invariant_balancesMatchTheGhostLedger\n[PASS] invariant_balancesSumToTheSupply\n[PASS] invariant_deployerBalanceIsSupplyLessNetOutflow\n[PASS] invariant_nobodyHoldsMoreThanTheyReceived\n[PASS] invariant_outsidersHoldNothing\n[PASS] invariant_totalSupplyIsFixed\n SwarmCoreInvariantTest invariants (runs: 256, calls: 16384, reverts: 0)\n\n╭------------------+----------------------------+-------+---------+----------╮\n| Contract         | Selector                   | Calls | Reverts | Discards |\n+============================================================================+\n| SwarmCoreHandler | approve                    | 1013  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | approveAlmostUnlimited     | 1025  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | approveUnlimited           | 1051  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | approveZero                | 1026  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | approveZeroSpender         | 1056  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | callUnknownSelector        | 1022  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | transfer                   | 2085  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | transferAboveBalance       | 1014  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | transferAll                | 1016  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | transferFrom               | 1995  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | transferFromAboveAllowance | 1018  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | transferFromAboveBalance   | 1011  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | transferOne                | 1059  | 0       | 0        |\n|------------------+----------------------------+-------+---------+----------|\n| SwarmCoreHandler | transferToZero             | 993   | 0       | 0        |\n╰------------------+----------------------------+-------+---------+----------╯\n\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 15.35s (15.34s CPU time)\n\nRan 3 test suites in 15.35s (15.74s CPU time): 55 tests passed, 0 failed, 0 skipped (55 total tests)\n","passed":true},{"durationMs":41,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"SwarmCore.approve(address,uint256)\",\"SwarmCore.transfer(address,uint256)\",\"SwarmCore.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":4,\"README.md\":123,\"foundry.toml\":19,\"src/SwarmCore.sol\":123,\"test/SwarmCore.edges.t.sol\":345,\"test/SwarmCore.invariant.t.sol\":409,\"test/SwarmCore.t.sol\":447,\"test/utils/Harness.sol\":76,\"test/utils/InvariantHarness.sol\":42},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"449bfd7f7f042c3af71a4a006888a3b5406df4541d6a27bbb3f0736334c18332","verifiedTreeHash":"03779c42de27ef5124301ea2b2951a19279804c6","verifierVersion":"0.1.0+d952fceb"},{"checks":[{"durationMs":320,"exitCode":0,"name":"build","output":"Compiling 3 files with Solc 0.8.26\nSolc 0.8.26 finished in 276.45ms\nCompiler run successful!\n","passed":true},{"durationMs":62,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 30 tests for test/SwarmCore.t.sol:SwarmCoreTest\n[PASS] testFuzz_aChainOfTransfersConservesTheSupply(uint256,uint256,uint256) (runs: 256, μ: 221606, ~: 226939)\n[PASS] testFuzz_transferAboveTheBalanceReverts(uint256,uint256) (runs: 256, μ: 90071, ~: 90710)\n[PASS] testFuzz_transferConservesTheSupply(address,uint256) (runs: 256, μ: 75718, ~: 76928)\n[PASS] testFuzz_transferFromAboveTheAllowanceReverts(uint256,uint256) (runs: 256, μ: 85531, ~: 86094)\n[PASS] testFuzz_transferFromSpendsExactlyTheAmount(uint256,uint256) (runs: 256, μ: 130501, ~: 131862)\n[PASS] test_approveSetsTheAllowanceAndEmits() (gas: 100180)\n[PASS] test_approveTheZeroAddressReverts() (gas: 30629)\n[PASS] test_constructorEmitsOneMintTransfer() (gas: 10790)\n[PASS] test_constructorMintsTheWholeSupplyToTheDeployer() (gas: 23189)\n[PASS] test_launchFlowsArriveWhole() (gas: 198740)\n[PASS] test_metadata() (gas: 33748)\n[PASS] test_noCommonAdminCallIncreasesSupply() (gas: 613723)\n[PASS] test_noOwnerAndNoPauseState() (gas: 70765)\n[PASS] test_noPrivilegedHandMovesOrFreezesAHolder() (gas: 437776)\n[PASS] test_plainEtherIsRefused() (gas: 33221)\n[PASS] test_runtimeHasNoDelegatecallOrSelfdestructAndFitsEip170() (gas: 547759)\n[PASS] test_transferFromAboveAllowanceReverts() (gas: 92515)\n[PASS] test_transferFromAboveBalanceRevertsEvenWithAllowance() (gas: 135309)\n[PASS] test_transferFromByTheOwnerStillNeedsAnAllowance() (gas: 33418)\n[PASS] test_transferFromSpendsTheAllowanceAndMovesTheTokens() (gas: 140806)\n[PASS] test_transferFromToTheZeroAddressReverts() (gas: 83487)\n[PASS] test_transferFromWithUnlimitedAllowanceKeepsIt() (gas: 120279)\n[PASS] test_transferFromWithoutAllowanceReverts() (gas: 37501)\n[PASS] test_transferMovesExactlyTheAmountAndEmits() (gas: 77980)\n[PASS] test_transferOfTheWholeBalanceSucceeds() (gas: 65437)\n[PASS] test_transferOfZeroSucceedsAndEmits() (gas: 42084)\n[PASS] test_transferRevertsFromAnEmptyAccount() (gas: 33123)\n[PASS] test_transferRevertsOnInsufficientBalance() (gas: 97107)\n[PASS] test_transferToSelfKeepsTheBalance() (gas: 95291)\n[PASS] test_transferToTheZeroAddressReverts() (gas: 34813)\nSuite result: ok. 30 passed; 0 failed; 0 skipped; finished in 14.52ms (52.62ms CPU time)\n\nRan 1 test suite in 15.19ms (14.52ms CPU time): 30 tests passed, 0 failed, 0 skipped (30 total tests)\n","passed":true},{"durationMs":21,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"SwarmCore.approve(address,uint256)\",\"SwarmCore.transfer(address,uint256)\",\"SwarmCore.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":4,\"README.md\":123,\"foundry.toml\":19,\"launch.json\":24,\"src/SwarmCore.sol\":123,\"test/SwarmCore.t.sol\":447,\"test/utils/Harness.sol\":76},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"84082da4c23937c0a2444d3bdc84aea939ed9a4d9cdd0a56dde83639c7352355","verifiedTreeHash":"557bdb3f8c6e2c384ac146e1a2ae96c2e21a886d","verifierVersion":"0.1.0+d952fceb"}]}