{"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":"3fb0ebcb-9d55-42f2-9812-7d0bc084ad0c","kind":"shape:chain","nodes":[{"acceptedSubmissionHash":"4016cc836cb151de1475cd48f68eea24c2140a65a295ecccd3552a3a15626601","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":"246fb56c334536e0b53ca30cbdaf19161eca4fc73acf3ae9d49d2924b157e3f7","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":"79c7d002930381232094d266027bec60a4ae038f010cdf98ddf76bcf0e068e30","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":"7299a137b151dd352a84a54f7493adfe90bd5146d10aa900b9527e0462144863","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":"f829ebb952c03554085fbcff7b80f9b30d2a7a42a5a5263edadafcbc50c6b68e","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":"6099e3af7d44436b38467a224c34c1239c2fbcff2baa86da16ac0feb20549799","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":"6cf4de53c5be7f0afd4a835f6b53be1e5c91d16f1923248a6bbd3cd96df0974d","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"tools":[]},"key":"manifest","kind":"code","role":"integrate","skillHash":null,"skillId":null,"state":"accepted"},{"acceptedSubmissionHash":"b5d91ddb33c5578f1763cd70a5199b83167d1b870ec57ca70e013c21dc488a5e","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: Yolo (YOLO).\nToken name: Yolo\nToken symbol: YOLO\nToken supply: 1,000,000,000 with 18 decimals, all minted once to the deployer in the constructor.","parentJobId":null,"planHash":"38c7c1a7e330114385c02bbb26de2a36d1e388d5e9955cc7b93fd42e0b4227a1","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"3fb0ebcb-9d55-42f2-9812-7d0bc084ad0c","publication":{"commit":null,"deliveredAt":null,"repoUrl":"https://github.com/identity-md-launches/launch-2350-yolo"},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[],"schema":"identitymd-work-v1","signals":[{"agentId":"52680","feedbackHash":"c86be22ce9e21364c61c02c6c12f82d5a102eb3b799871494291f869482297fc","nodeKey":"audit_economics","submissionHash":"4016cc836cb151de1475cd48f68eea24c2140a65a295ecccd3552a3a15626601","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52613","feedbackHash":"9a6e84da7eab196d14086c34a027642b625d7468ba7816c7863580366b9472d2","nodeKey":"audit_flow","submissionHash":"246fb56c334536e0b53ca30cbdaf19161eca4fc73acf3ae9d49d2924b157e3f7","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51428","feedbackHash":"f6b7930e7048fc1eac738af2e9c2bbf0e679edeeccdfbe53906792cab1dcb9f3","nodeKey":"audit_judge","submissionHash":"79c7d002930381232094d266027bec60a4ae038f010cdf98ddf76bcf0e068e30","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52182","feedbackHash":"e2d4cc2b3f4e2d03ea81d6803e251a13610e8d4aff31927553a456312b0f16b3","nodeKey":"audit_math","submissionHash":"7299a137b151dd352a84a54f7493adfe90bd5146d10aa900b9527e0462144863","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51882","feedbackHash":"d850f95f60c11d0a9ab96c0e8c3d0377383569752cb4751cb36b226f34d7b094","nodeKey":"audit_permissions","submissionHash":"f829ebb952c03554085fbcff7b80f9b30d2a7a42a5a5263edadafcbc50c6b68e","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52419","feedbackHash":"3478e2a5668ad2cae66a39183543370430d356c92cab90a2359787fdbe72c793","nodeKey":"build_contract_project","submissionHash":"6099e3af7d44436b38467a224c34c1239c2fbcff2baa86da16ac0feb20549799","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"52180","feedbackHash":"39a1d1970b744f651670c09c9f14b9980c577eebf2408eba308e83fa5e194b38","nodeKey":"manifest","submissionHash":"6cf4de53c5be7f0afd4a835f6b53be1e5c91d16f1923248a6bbd3cd96df0974d","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"51512","feedbackHash":"471c478ab6b6b8be53a5b0773da235f9fb81e7818bea0c487059a8510c3ea0f4","nodeKey":"write_foundry_tests","submissionHash":"b5d91ddb33c5578f1763cd70a5199b83167d1b870ec57ca70e013c21dc488a5e","tag1":"verification:checks","tag2":"acceptance-v2","value":1}],"site":null,"snapshotHash":"4e9f1df8ee35a660d98caac2add0757ae1ee2c87cad5d33c9cd98fef20806815","state":"completed","submissions":[{"artifacts":[],"attempt":1,"bundleHash":null,"device":"7eaf1cd0fb3df712","findings":[{"citation":"resolved","description":"_transfer checks only the receiver. transferFrom forwards a caller-chosen `from`, so `from` can be address(0). With value 0, _spendAllowance passes (allowance 0 >= 0) and _transfer passes (balance 0 >= 0), so the call returns true and emits Transfer(address(0), to, 0). By ERC-20 convention a Transfer from address(0) is a mint. The contract's documented guarantee is that the supply is minted once, in the constructor, and that is the only Transfer from address(0) it should ever emit. Any caller can emit more of them, to any recipient and as often as they like. Indexers, explorers and launch monitors that rebuild supply or mint history from logs then record post-launch 'mints' of the fixed-supply token. Balances and totalSupply are not affected, so this is low. OpenZeppelin's ERC20, whose ERC-6093 error names this contract adopts, rejects this case with ERC20InvalidSender(address(0)). That error is missing here.","line":96,"path":"src/YoloToken.sol","reproduction":"Deploy YoloToken. From any EOA, call transferFrom(address(0), 0x000000000000000000000000000000000000bEEF, 0). Expected: revert (ERC20InvalidSender(address(0))), because the zero address is not a holder and only the constructor may emit Transfer from address(0). Actual: returns true and emits Transfer(from: 0x0000000000000000000000000000000000000000, to: 0x...bEEF, value: 0). Confirmed with forge -vvvv trace. Fix: in _transfer, add `if (from == address(0)) revert ERC20InvalidSender(address(0));` and declare `error ERC20InvalidSender(address sender);`. This cannot reach a launch flow, since the factory, PoolManager and distributor always transfer from their own addresses.","severity":"low","snippet":"        if (to == address(0)) revert ERC20InvalidReceiver(address(0));","title":"transferFrom accepts from == address(0) for a zero value and emits a mint-shaped Transfer(address(0), to, 0) after deployment"}],"hash":"246fb56c334536e0b53ca30cbdaf19161eca4fc73acf3ae9d49d2924b157e3f7","nodeId":"f2267061-bcd3-4f44-b3a1-9ca5e44e3543","outcome":"completed","summary":"I found one low-severity defect and nothing high or critical. The findings are written to `.imd-findings.json`, and no project files were changed.\n\n**Scope:** I reviewed all of `src/YoloToken.sol` (128 lines, no dependencies) and checked it against the Execution Trace, Periphery and First Principles guides, the token threat profile and the custom-token launch rules. The project's own 33 tests pass.\n\n**Finding 1 (low): `transferFrom` accepts the zero address as sender.** At `src/YoloToken.sol:96`, `_transfer` checks only that the receiver isn't the zero address.\n- **Reproduction:** anyone can call `transferFrom(address(0), 0x…bEEF, 0)`. No allowance or balance is needed, it returns true and emits `Transfer(address(0), 0x…bEEF, 0)`. I confirmed this with a Foundry trace.\n- **Why it matters:** by ERC-20 convention a transfer from the zero address is a mint, so any caller can make post-launch \"mint\" events appear in the logs of a token whose supply is minted once. Explorers and monitors that rebuild supply or mint history from logs would show them. Balances and the total supply are not affected, and no launch transfer can trigger this, so it stays low.\n- **Fix:** add `if (from == address(0)) revert ERC20InvalidSender(address(0));` and declare that error. This matches OpenZeppelin, whose error names the contract already uses.\n\n**Coverage:**\n\n| Entry point | Verdict | Reason |\n|---|---|---|\n| `approve` | holds | The owner is always the caller, a zero spender is rejected, and the allowance is set exactly. |\n| `transfer` | holds | The balance is checked before the subtraction; sending to yourself leaves your balance unchanged; sending to the zero address reverts. |\n| `transferFrom` | finding 1 | Allowance spending and the unlimited-allowance case are correct; the only gap is the zero-address sender above. |\n\n**Other checks, both hold:**\n- **Fixed supply:** only the constructor creates balance, minting 10⁹ × 10¹⁸ (10²⁷) to the deployer, and there is no other way to mint, burn or take control.\n- **Launch transfers:** there is no fee, burn or hook on transfer, so every launch transfer and every pool deposit or swap moves exactly the stated amount.\n\nThe static-analysis \"large numeric literal\" warning at line 27 is just the supply constant. It is correct and I didn't report it.\n\n**Limits:** the repository has no forge-std and no Uniswap v4 libraries, so I couldn't run the protected launch tests here. Instead, my scratch test stood alone, and I deleted it afterwards. No finding was high or critical, so none carries a proof.","treeHash":null,"usage":{"cachedInputTokens":308650,"inputTokens":18,"model":"claude-opus-5-5","outputTokens":4681,"runtime":"claude","turns":9,"wallClockMs":51555}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"d7e6877fd9e388bb","findings":[{"citation":"resolved","description":"_transfer validates only the receiver. It never rejects from == address(0), and _spendAllowance passes when value == 0 because `0 < 0` is false (src/YoloToken.sol:117). So an unprivileged caller can execute transferFrom(address(0), anyAddress, 0) successfully. No balance changes and no allowance changes, but the contract emits Transfer(address(0), anyAddress, 0), the exact shape of a mint event. Indexers, explorers and wallets that classify Transfer-from-zero as a mint will record spurious zero-value mints attributable to arbitrary recipients, and tooling that counts mint events (rather than summing values) will see the supply 'minted' more than once. The reference implementation this contract mirrors (OpenZeppelin v5 ERC20._transfer) reverts with ERC20InvalidSender(address(0)) on this path. Economic impact is nil: sum of balances stays exactly TOTAL_SUPPLY and totalSupply() is a constant, which I verified with a 256-run randomised fuzz over transfer and transferFrom (including unlimited allowances and self-transfers). This is reported for completeness under the Economic Security guide's 'abuse sentinel addresses' check; it does not block the launch. Minimal fix that preserves intended behaviour: add `if (from == address(0)) revert ERC20InvalidSender(address(0));` at the top of _transfer (declare the ERC-6093 error). An alternative with equivalent effect is to reject from == address(0) in transferFrom only.","line":96,"path":"src/YoloToken.sol","reproduction":"State: fresh YoloToken deployed by FACTORY. Call, from any EOA e.g. 0xBEEF: token.transferFrom(address(0), 0xBEEF, 0). Expected (per ERC-6093 reference behaviour and the contract's own 'nothing can mint' intent): revert, no event. Actual: returns true and emits Transfer(from=0x0000000000000000000000000000000000000000, to=0xBEEF, value=0); balanceOf(0xBEEF) stays 0 and balanceOf(address(0)) stays 0. Verified in a scratch Foundry test with vm.recordLogs: exactly one log, topics[1] == address(0), topics[2] == 0xBEEF, data decodes to 0. With value 1 the same call reverts ERC20InsufficientAllowance(0xBEEF, 0, 1), so only the zero-value variant is reachable.","severity":"info","snippet":"        if (to == address(0)) revert ERC20InvalidReceiver(address(0));","title":"transferFrom accepts address(0) as sender, so anyone can emit a zero-value Transfer from the zero address (a spoofable mint-shaped event)"}],"hash":"4016cc836cb151de1475cd48f68eea24c2140a65a295ecccd3552a3a15626601","nodeId":"a55d4be1-5a09-432f-a583-b74ac885c985","outcome":"completed","summary":"The findings file is valid, the quoted snippet matches line 96 of the source exactly, and the working tree shows no tracked changes. The scratch test lives under the gitignored test/scratch/ directory.\n\n**Outcome:** the Yolo token holds under every failure mode in the Economic Security, Invariant and Flow Gap guides. I reported one informational finding and no defects that block the launch.\n\n**What I checked**\n\n- Supply conservation. The constructor writes the full supply to the deployer once, and the only other balance writer is the internal transfer, which is conservative. A 256-run randomised fuzz over mixed transfer and transferFrom sequences across six actors, including self-transfers and unlimited allowances, kept the sum of balances equal to the constant supply every step.\n- Launch flows. There are no fees, hooks, callbacks, exemptions or external calls, so the factory-to-distributor, claim, seed, swap and remainder hops each move exactly the requested amount. The 10/80/10 split of the supply divides without dust.\n- Privilege and sentinel behaviour. No owner, pause, blocklist, mint or burn path exists. The deployer cannot pull from a holder without an allowance. Approve to the zero address and transfer to the zero address both revert.\n- The three ABI entry points each have a coverage row, plus six rows for the invariants and flow properties I traced.\n\n**The one finding, severity info**\n\n`transferFrom(address(0), anyone, 0)` succeeds from any caller and emits a zero-value Transfer from the zero address. The sender is never validated in the internal transfer, and a zero value passes the allowance check. No balance or allowance changes, so there is no economic impact. Indexers that classify Transfer-from-zero as a mint can record spurious zero-value mints. The reference OpenZeppelin implementation rejects this with an invalid-sender error. The reproduction and a one-line fix are in the findings file.\n\n**Not reached:** nothing in my area. The static-analysis lead about the large numeric literal at line 27 is a style note, not a defect, since the constant equals the brief's supply exactly.","treeHash":null,"usage":{"cachedInputTokens":752378,"inputTokens":322,"model":"claude-fable-5-1","outputTokens":13333,"runtime":"claude","turns":23,"wallClockMs":204010}},{"artifacts":[],"attempt":1,"bundleHash":"0139957bb01c3b64934496db17ac7422e671f6b452fac45c07dac4ecb508115d","device":"7e50667f872c7f5e","findings":[],"hash":"6099e3af7d44436b38467a224c34c1239c2fbcff2baa86da16ac0feb20549799","nodeId":"339b1955-cd13-4029-8948-77cb144e80b3","outcome":"completed","summary":"The Yolo token project is written and documented. I could not compile or run it: every shell command on this machine fails before starting with a sandbox error (`apply-seccomp: write /proc/self/setgroups ... Permission denied`), so forge build, forge test, forge fmt and git were all unavailable. The code was reviewed by hand instead.\n\n**What was delivered**\n\n- `src/YoloToken.sol`: a dependency-free ERC-20, name `Yolo`, symbol `YOLO`, 18 decimals, 1,000,000,000 tokens minted once to the constructor's msg.sender. No owner, no mint, no burn, no pause, no blocklist, no fee, no fallback, no delegatecall or selfdestruct. Unlimited allowance is not decremented. ERC-6093 error names.\n- `test/YoloToken.t.sol`: 28 tests. Success paths for transfer, approve and transferFrom with event checks. Failure paths for insufficient balance, insufficient allowance, zero receiver and zero spender. Checks that the launch flows arrive whole, that no mint or admin selector exists, that no privileged call moves or freezes a holder, and that reachable runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT. Six fuzz tests for conservation of supply and allowance accounting, with inputs bounded so any seed passes.\n- `test/utils/TestBase.sol`: a minimal cheatcode interface and assertions, so no forge-std or OpenZeppelin needed vendoring.\n- `foundry.toml`: solc pinned to 0.8.26, optimizer on, `bytecode_hash = \"none\"`, ffi off, no fs permissions.\n- `README.md`: design, assumptions, manifest values for the launch step, \"After launch\" (nothing to set), operational responsibilities and chosen constants.\n\n**What was not verified**\n\n- forge build, forge test and forge fmt --check did not run here because the Bash sandbox refused every command. The verifier's offline build is the first real compile of this code.\n- The working tree is not committed, since git could not run either. All files are plain files under the repository root.\n\n**Where the verifier's results matter most**\n\n- Overload resolution and cheatcode ordering in the tests were checked by reading, not compiling. If the build reports an error, it is most likely in `test/YoloToken.t.sol`, not in the token itself.","treeHash":"d46777f02feda2148a2f4ba0b7277cddaa8e156a","usage":{"cachedInputTokens":987071,"inputTokens":482,"model":"claude-fable-5-1","outputTokens":34481,"runtime":"claude","turns":27,"wallClockMs":417215}},{"artifacts":[],"attempt":1,"bundleHash":"e8f361cc8f709a39a69c8633ce40f719940ad184ed13226c41a27e7ea746933c","device":"c722c2e9ac9aa084","findings":[],"hash":"6cf4de53c5be7f0afd4a835f6b53be1e5c91d16f1923248a6bbd3cd96df0974d","nodeId":"cf1e08d6-28a3-4bed-b1af-bfdb804387be","outcome":"completed","summary":"Done. The manifest is written and verified against the accepted tree.\n\n**What I wrote:** `launch.json` at the repository root, kind \"custom_token\", describing the accepted YoloToken contract.\n\n- **Token:** contract YoloToken, name Yolo, symbol YOLO, 18 decimals, empty constructorArgs. The accepted constructor takes no parameters and mints the whole supply once to msg.sender.\n- **totalSupply:** 1000000000000000000000000000 minor units, exactly what the constructor's TOTAL_SUPPLY constant mints.\n- **Contracts:** an empty list. The accepted tree contains only the token, so no application contracts are named.\n- **Pool:** IMD pair address, fee 12500, tick spacing 60, initialPrice as the reference gives it.\n- **Economics:** copied verbatim from the job and checked byte for byte against the required object.\n- **Notes:** one string, well under the 4000 character limit, describing only what is in the accepted source.\n\n**Checks run:** the manifest parses with only the schema's top-level keys, the build compiles cleanly on solc 0.8.26, and all 33 existing tests pass with the verifier's fuzz seed. Git status shows launch.json as the only new or changed file.","treeHash":"bb7d1dea5161f4fb23563db2cbf0c37764c52ca5","usage":{"cachedInputTokens":193071,"inputTokens":130,"model":"claude-fable-5-1","outputTokens":2757,"runtime":"claude","turns":8,"wallClockMs":46599}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"d11ea2b5e05fa7a8","findings":[{"citation":"resolved","description":"Boundary guide, sentinel-address walk: _transfer rejects the zero address as receiver but not as sender, and the contract defines no ERC20InvalidSender error although it adopts the ERC-6093 names otherwise. transferFrom(address(0), to, 0) therefore succeeds for any caller: allowance[address(0)][caller] is 0 and value is 0, so _spendAllowance passes; balanceOf[address(0)] is 0 and value is 0, so the balance check passes; the function then emits Transfer(0x0, to, 0). ERC-20 says a Transfer with from == 0x0 indicates token creation, so indexers and explorers that count mints by that shape log a spurious zero-value mint, callable by anyone at will. No balance or supply changes: a non-zero value from the zero address reverts at the allowance check (allowance[0][caller] == 0) and could not pass the balance check either (balanceOf[0] == 0). OpenZeppelin's ERC20._transfer reverts with ERC20InvalidSender(address(0)) on this input. Severity is informational: no funds move and the supply invariant holds; only event hygiene differs from the library the error names are borrowed from.","line":96,"path":"src/YoloToken.sol","reproduction":"State: fresh YoloToken deployed by FACTORY. Call, from any address A with no allowance and no balance: token.transferFrom(address(0), B, 0). Expected (OpenZeppelin ERC-6093 semantics the contract mirrors): revert ERC20InvalidSender(0x0). Actual: returns true and emits Transfer(from=0x0, to=B, value=0); balanceOf(B) stays 0 and totalSupply stays 1e27. Verified in test/scratch/MathBoundary.t.sol::test_transferFromZeroAddressZeroValueEmitsMintShapedEvent (passes on current code, i.e. the event is emitted). Minimal fix: add `error ERC20InvalidSender(address sender);` and `if (from == address(0)) revert ERC20InvalidSender(address(0));` at the top of _transfer.","severity":"info","snippet":"        if (to == address(0)) revert ERC20InvalidReceiver(address(0));","title":"transferFrom accepts from == address(0) and emits a mint-shaped zero-value Transfer event"}],"hash":"7299a137b151dd352a84a54f7493adfe90bd5146d10aa900b9527e0462144863","nodeId":"55213e5d-dbb2-4f02-b412-079aabbda3d4","outcome":"completed","summary":"The review is complete and the findings file is written and validated.\n\n**Outcome:** the Yolo token holds up under the Math Precision, Boundary and Numerical Gap guides. I found no defect that moves value or breaks the supply. One informational deviation is recorded.\n\n**What I checked**\n- **Math Precision:** the contract has no division, no runtime multiplication, no scaling and no downcasts. The only arithmetic is the two `unchecked` blocks in `_transfer` and `_spendAllowance`. Both subtractions sit behind an explicit less-than revert, and the unchecked add cannot overflow because the sum of balances is fixed at 1e27 by construction. The aderyn \"large numeric literal\" lead resolves to exactly 1e27 at compile time and is style only.\n- **Boundary:** no external calls, no payable function, no receive or fallback, no bytes decoding, so most of the guide has no entries here. I walked the zero and max edges directly: zero receiver and zero spender revert, zero amounts succeed with an event, max amount reverts in the guard, max allowance is the unlimited sentinel and max minus one decrements normally, self-transfer of the whole supply is a no-op, and a recipient can reach exactly the full supply.\n- **Numerical Gap:** with no rounding anywhere, the conservation invariant cannot drift. A fuzzed test of random eight-step transfer sequences among four accounts kept the sum at exactly 1e27 across 256 runs.\n\n**Finding (info):** `transferFrom(address(0), to, 0)` succeeds for any caller and emits a Transfer event from the zero address, which is the shape ERC-20 reserves for mints. No balance or supply changes, and a non-zero amount from the zero address reverts. The fix is a one-line `ERC20InvalidSender` check in `_transfer`, matching the OpenZeppelin semantics the error names are borrowed from.\n\n**Coverage:** all three listed entry points have rows, plus rows for the supply invariant, the constant, the constructor and the absent external-call surface. Nothing was left unreached. The scratch tests live in `test/scratch/MathBoundary.t.sol` and used the project's own TestBase because forge-std is not vendored in this tree. No tracked file was changed.","treeHash":null,"usage":{"cachedInputTokens":653022,"inputTokens":290,"model":"claude-fable-5-1","outputTokens":11336,"runtime":"claude","turns":17,"wallClockMs":160026}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"bc1e515ca5c78ac4","findings":[{"citation":"resolved","description":"Merged from all five specialist reports (audit_flow, write_foundry_tests, audit_math, audit_economics, audit_permissions): same root cause. _transfer checks only the receiver, never the sender, and the contract omits ERC-6093's ERC20InvalidSender although it otherwise adopts those names. In transferFrom, _spendAllowance(address(0), caller, 0) passes (allowance 0, not max, and `0 < 0` is false) and _transfer passes (balanceOf[address(0)] == 0 >= 0), so any caller can emit Transfer(address(0), anyRecipient, 0) at will. By ERC-20 convention that event shape is a mint, contradicting the stated guarantee that the only mint is the constructor's; log-based indexers/explorers/launch monitors can record spurious post-launch mints. No balance, allowance or totalSupply changes (any value >= 1 reverts with ERC20InsufficientAllowance, since allowance[address(0)][x] can never be set), and launch flows (factory, PoolManager, distributor) always transfer from their own addresses, so it does not block deployment or move funds. Fix preserving behaviour: declare `error ERC20InvalidSender(address sender);` and add `if (from == address(0)) revert ERC20InvalidSender(address(0));` at the top of _transfer.","line":96,"path":"src/YoloToken.sol","reproduction":"Deploy YoloToken (no constructor args). From any contract/EOA with no balance or allowance call transferFrom(address(0), 0x0000000000000000000000000000000000000B0b, 0). Expected: revert ERC20InvalidSender(address(0)). Actual (reproduced with a scratch forge test, -vvvv trace): returns true and emits Transfer(from: 0x0000000000000000000000000000000000000000, to: 0x...0B0b, amount: 0); totalSupply() stays 1e27 and balances are unchanged. The same call with value 1 reverts (ERC20InsufficientAllowance), so only the zero-value event is reachable.","severity":"low","snippet":"        if (to == address(0)) revert ERC20InvalidReceiver(address(0));","title":"transferFrom accepts from == address(0) with value 0 and emits a mint-shaped Transfer(address(0), to, 0) after deployment"}],"hash":"79c7d002930381232094d266027bec60a4ae038f010cdf98ddf76bcf0e068e30","nodeId":"a3412aa7-5cc8-4214-8739-8fa2cae45d17","outcome":"completed","summary":"The review found one low-severity defect, and nothing that blocks the launch. All five specialists reported the same root cause, so I merged their reports into one finding and reproduced it myself.\n\n**Finding 1 (low), `src/YoloToken.sol:96`:** `_transfer` checks that the receiver isn't the zero address but never checks the sender. So anyone can call `transferFrom(address(0), to, 0)` and it succeeds:\n- The allowance check passes, because the allowance is 0 and the amount is 0.\n- The balance check passes, because the zero address holds 0.\n- The token then emits `Transfer(address(0), to, 0)`, which explorers and indexers treat as a mint.\n\nI confirmed this with a temporary Foundry test and a `-vvvv` trace. Balances, allowances and `totalSupply` don't change. Any amount of 1 or more reverts on the allowance check, and the launch's own transfers never come from the zero address. The impact is limited to fake \"mint\" events that log-reading tools may record after launch.\n\nThe fix is to declare `ERC20InvalidSender(address)` and add `if (from == address(0)) revert ERC20InvalidSender(address(0));` at the top of `_transfer`. This is the OpenZeppelin behaviour whose error names the contract already uses. I attached no proof file, since the task only asks for one on critical and high findings.\n\n**Coverage:**\n- **`approve`:** holds.\n- **`transfer`:** holds, including transferring to yourself, which I tested.\n- **`transferFrom`:** has finding 1.\n\nI also checked two invariants:\n- **Fixed supply:** 1e27 is minted once to the deployer and nothing can mint or burn afterwards. This matches `launch.json`, which has the right supply, 18 decimals and empty constructor arguments for the no-argument constructor.\n- **Launch transfers arrive whole:** there's no fee, owner, pause, blocklist, delegatecall or selfdestruct.\n\nThe aderyn \"large numeric literal\" warning on line 27 is just a style note about `1_000_000_000 * 10 ** 18`, so I didn't report it.\n\n**What I couldn't run:**\n- The project's existing 58 tests pass.\n- I couldn't run the protected launch tests: they need libraries that aren't installed here (`v4-core`, and `forge-std`, which the task's proof format expects). I wrote my reproduction test without `forge-std` for that reason.\n- I deleted the scratch test afterwards, and no tracked files changed.\n\nThe findings and coverage are in `.imd-findings.json`, which is valid JSON.","treeHash":null,"usage":{"cachedInputTokens":271356,"inputTokens":14,"model":"claude-opus-5-5","outputTokens":4805,"runtime":"claude","turns":7,"wallClockMs":59811}},{"artifacts":[],"attempt":1,"bundleHash":"f0e64246a4394953c7eeb03bc0589fe3ed0de6744f5a9e38f16d88b482553014","device":"8c9c4986ca881107","findings":[{"description":"_transfer does not reject from == address(0) (OpenZeppelin reverts with ERC20InvalidSender). Because balanceOf[address(0)] and allowance[address(0)][caller] are both 0, transferFrom(address(0), to, 0) passes the allowance check (0 < 0 is false) and the balance check, and emits Transfer(address(0), to, 0). Indexers and explorers that treat Transfer from the zero address as a mint may show spurious zero-value mints after launch. No balance or supply changes, so the fixed-supply guarantee holds; this is cosmetic. The ERC20InvalidSender error is also missing from the ERC-6093 set the contract claims to follow.","line":96,"path":"src/YoloToken.sol","reproduction":"Deploy YoloToken; from any address (e.g. 0xBEEF) call transferFrom(address(0), 0xB0B, 0). Expected: revert ERC20InvalidSender(address(0)). Actual: succeeds and emits Transfer(from: 0x0, to: 0xB0B, amount: 0). Balances and totalSupply are unchanged.","severity":"info","title":"Anyone can emit a mint-shaped Transfer(address(0), to, 0) via zero-value transferFrom from the zero address"}],"hash":"b5d91ddb33c5578f1763cd70a5199b83167d1b870ec57ca70e013c21dc488a5e","nodeId":"c2e6448f-abb2-450c-a4c6-ba6594532151","outcome":"completed","summary":"I added two test files on top of the existing suite. `forge build` succeeds, and `forge test` with the verifier's fuzz seed passes all 58 tests (33 existing, 25 new). The token is plain and I found no real defect, only one cosmetic issue, which I reported instead of writing a test that treats it as correct.\n\n**`test/YoloTokenInvariant.t.sol`: invariant tests over random call sequences**\n- A handler moves tokens between five holders (the factory plus four others). It keeps its own record of what every balance and allowance should be, worked out from the arguments of each call rather than read back from the token.\n- It also drives the calls that should fail: sending more than the balance, sending to the zero address, spending more than the allowance or the owner's balance, and approving the zero address. Each must revert and leave everything unchanged.\n- The invariants checked after every call:\n  - total supply stays at 1,000,000,000 × 10¹⁸;\n  - the five holders' balances add up to the supply, and nothing ends up at the zero address, the token contract or the handler;\n  - every balance and allowance matches the handler's record;\n  - no call that should fail succeeds, no failed call changes state, and an unlimited (`type(uint256).max`) allowance is never reduced.\n- Settings are 256 runs at depth 64, about 16,000 calls, with zero reverts.\n- To check that these tests can actually fail, I broke the source two ways: once so unlimited allowances get reduced, once so transfers deliver 1 wei short. Each break was caught; I then restored the source, and git shows it unchanged.\n\n**`test/YoloTokenEdges.t.sol`: 24 edge-case and fuzz tests**\n- **Maximum values:** transferring `type(uint256).max` or the supply plus 1 reverts, and an allowance of max − 1 counts down like a normal one.\n- **Repeated calls:** a second spend of a used-up allowance reverts, re-approving the same amount replaces it rather than adding, and approving 0 revokes.\n- **Unexpected callers:** an owner can't spend their own tokens through `transferFrom` without approving themselves, and allowances apply only to the one owner and spender they were set for.\n- **Clean failures:** a failed `transferFrom` leaves the allowance intact, and sending zero to the zero address still reverts.\n- **Fuzz tests (1,000 runs):** a transfer between any two holders conserves their combined balance, two partial spends of an allowance end the same as one full spend, and an unlimited allowance is never reduced.\n\n**Reported in `.imd-findings.json` (info severity):** anyone can call `transferFrom(address(0), to, 0)`. It succeeds and emits `Transfer(address(0), to, 0)`, which block explorers and indexers can show as a zero-value mint. No balance or supply changes. OpenZeppelin's ERC-20 rejects this with `ERC20InvalidSender`, which this contract leaves out (`src/YoloToken.sol:96`). I confirmed it with a test in `test/scratch/` before writing it up. That file isn't submitted, and because the finding is info-level it carries no proof.\n\n`.imd-findings.json` is listed in `.git/info/exclude`, so `git status` doesn't show it, but the file is in the repository root.\n\nI didn't change any existing file, source or configuration.","treeHash":"f716a1baf66b2573e53af445cdc7f34a25a9dbd1","usage":{"cachedInputTokens":656218,"inputTokens":28,"model":"claude-opus-5-5","outputTokens":17644,"runtime":"claude","turns":14,"wallClockMs":188845}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"5c1e4764d4e20ef5","findings":[{"citation":"resolved","description":"Asymmetry guide, branch/pair diff (approve <-> transferFrom, receiver check <-> sender check). _transfer rejects to == address(0) with ERC20InvalidReceiver but never rejects from == address(0). The contract adopts the ERC-6093 error names (header comment, lines 10-11, 46-49) yet omits ERC20InvalidSender, which the reference implementation (OpenZeppelin v5 _transfer) raises for a zero sender. Because balanceOf[address(0)] is permanently 0 and allowance[address(0)][x] can never be set (approve keys on msg.sender, which is never the zero address), the only value that passes both the allowance check (`0 < 0` is false) and the balance check (`0 < 0` is false) is 0. The call therefore succeeds and emits Transfer(0x0, to, 0), the exact shape of a mint event. No balance or allowance changes and totalSupply is a constant, so there is no loss of funds and no effect on the launch flows, the swarm share, the seed or swaps; the impact is limited to off-chain indexers and explorers that treat Transfer-from-zero as a mint (they record a zero-value mint attributed to an arbitrary `to`) and to spec drift from the ERC-6093 names the contract advertises. Minimal fix that preserves intended behaviour: in _transfer add `if (from == address(0)) revert ERC20InvalidSender(address(0));` with the matching `error ERC20InvalidSender(address sender);` declaration. This changes nothing for any real holder since no real caller ever transfers from address(0).","line":96,"path":"src/YoloToken.sol","reproduction":"State: fresh YoloToken deployed by FACTORY (0xFAC7), no approvals. Call: vm.prank(0xA11CE); token.transferFrom(address(0), 0xB0B, 0). Actual: returns true and emits Transfer(from=0x0000000000000000000000000000000000000000, to=0xB0B, value=0); balanceOf(0xB0B) stays 0, totalSupply stays 1000000000000000000000000000. Expected (ERC-6093 / OZ v5 semantics the contract claims to mirror): revert ERC20InvalidSender(address(0)). Confirmed with test/scratch/ZeroSender.t.sol::test_transferFromZeroSenderZeroValueSucceedsAndEmitsMintShapedEvent (passes on current code, documenting the behaviour). Any value >= 1 from the zero sender reverts with ERC20InsufficientAllowance(spender, 0, value), so no balance can ever be moved through this path.","severity":"info","snippet":"        if (to == address(0)) revert ERC20InvalidReceiver(address(0));","title":"transferFrom validates the receiver but not the sender: anyone can emit a mint-shaped Transfer(address(0), to, 0) event"}],"hash":"f829ebb952c03554085fbcff7b80f9b30d2a7a42a5a5263edadafcbc50c6b68e","nodeId":"5f89e0b6-0ff5-4123-b5c7-e70b7a9dc6e2","outcome":"completed","summary":"The review is complete and `.imd-findings.json` is written and valid. The working tree is otherwise untouched: only the findings file and my scratch test under `test/scratch/` exist, both gitignored.\n\n**Outcome:** the Yolo token is clean in the assigned area. One informational finding, no medium or higher.\n\n**What I checked** against the Access Control, Asymmetry and Trust Gap guides, plus the Senior Auditor's Mindset:\n\n- **Permission model.** There are no roles, modifiers, owner slots, setters, initializers, `receive`, `fallback`, proxies or `delegatecall`. The ABI's only state-changing entry points are `approve`, `transfer` and `transferFrom`, each acting on the caller's own balance or allowance. The factory receives the supply in the constructor and afterwards is an ordinary holder with no pull power.\n- **Paired-surface diff.** `transfer` and `transferFrom` share `_transfer`, so receiver validation, balance check and event emission are identical. The allowance writer pair (`approve` sets, `_spendAllowance` only decrements) cannot raise an allowance. The unlimited sentinel is handled as OpenZeppelin does. Self-transfer and whole-balance transfers conserve supply, and the unchecked add cannot wrap because the sum of balances is the constant 1e27.\n- **Trust gap.** No fee, tax or exemption list exists, so the swarm share, the seed, claims and swaps move exactly what they state. There is no admin variant of any user function and no in-flight value an actor could redirect.\n- **Static analysis lead.** Aderyn's large-literal note on line 27 is correct arithmetic (1e9 times 1e18 equals the manifest supply) and is not a defect.\n\n**The one finding (info):** `_transfer` rejects a zero receiver but never rejects a zero sender, although the contract advertises ERC-6093 error names. Since the zero address can hold no balance and no allowance, the only passing value is zero, so anyone can call `transferFrom(address(0), to, 0)` and emit a mint-shaped `Transfer(0x0, to, 0)` event. No balance, allowance or supply changes. I confirmed it with a scratch test and gave the one-line fix that preserves behaviour.\n\n**Coverage record:** all three listed entry points are answered (two hold, `transferFrom` carries the info finding), plus rows for the constructor and four invariants. Nothing in my area was left unreached. The project's existing 33 tests pass under solc 0.8.26.","treeHash":null,"usage":{"cachedInputTokens":570962,"inputTokens":226,"model":"claude-fable-5-1","outputTokens":11301,"runtime":"claude","turns":19,"wallClockMs":190435}}],"verification":[{"checks":[{"durationMs":363,"exitCode":0,"name":"build","output":"Compiling 3 files with Solc 0.8.26\nSolc 0.8.26 finished in 311.56ms\nCompiler run successful!\n","passed":true},{"durationMs":72,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 33 tests for test/YoloToken.t.sol:YoloTokenTest\n[PASS] testFuzz_approveAnyValue(address,uint256) (runs: 256, μ: 65933, ~: 66189)\n[PASS] testFuzz_chainedTransfersConserveSupply(uint256,uint256) (runs: 256, μ: 143722, ~: 145355)\n[PASS] testFuzz_transferAboveBalanceReverts(uint256,uint256) (runs: 256, μ: 89250, ~: 89904)\n[PASS] testFuzz_transferConservesSupply(address,uint256) (runs: 256, μ: 91391, ~: 91729)\n[PASS] testFuzz_transferFromAboveAllowanceReverts(uint256,uint256) (runs: 256, μ: 139749, ~: 140343)\n[PASS] testFuzz_transferFromAccountsAllowance(address,uint256,uint256) (runs: 256, μ: 181045, ~: 184206)\n[PASS] test_approveOverwritesAllowance() (gas: 87353)\n[PASS] test_approveSetsAllowanceAndEmits() (gas: 67814)\n[PASS] test_approveZeroSpenderReverts() (gas: 30675)\n[PASS] test_constructorMintsToAContractDeployerAndEmits() (gas: 192985)\n[PASS] test_constructorMintsWholeSupplyToDeployer() (gas: 23057)\n[PASS] test_deployerCannotPullFromHolderWithoutAllowance() (gas: 89669)\n[PASS] test_launchFlowsArriveWhole() (gas: 190817)\n[PASS] test_metadata() (gas: 17584)\n[PASS] test_noMintOrAdminFunctionExists() (gas: 475006)\n[PASS] test_noPrivilegedCallMovesOrFreezesAHolder() (gas: 411570)\n[PASS] test_plainEtherAndUnknownCalldataAreRejected() (gas: 47982)\n[PASS] test_runtimeHasNoDelegatecallOrSelfdestruct() (gas: 717179)\n[PASS] test_supplyIsOneBillionWithEighteenDecimals() (gas: 16167)\n[PASS] test_transferFromAboveAllowanceReverts() (gas: 136835)\n[PASS] test_transferFromAboveBalanceRevertsEvenWithAllowance() (gas: 135216)\n[PASS] test_transferFromExactAllowanceLeavesZero() (gas: 165531)\n[PASS] test_transferFromSpendsAllowance() (gas: 192641)\n[PASS] test_transferFromToZeroAddressReverts() (gas: 83381)\n[PASS] test_transferFromWithUnlimitedAllowanceDoesNotDecrement() (gas: 167563)\n[PASS] test_transferFromWithoutAllowanceReverts() (gas: 89676)\n[PASS] test_transferMovesBalanceAndEmits() (gas: 77891)\n[PASS] test_transferRevertsFromEmptyAccount() (gas: 33217)\n[PASS] test_transferRevertsOnInsufficientBalance() (gas: 96861)\n[PASS] test_transferToSelfKeepsBalance() (gas: 89865)\n[PASS] test_transferToZeroAddressReverts() (gas: 34706)\n[PASS] test_transferWholeBalance() (gas: 65399)\n[PASS] test_transferZeroAmountSucceeds() (gas: 39745)\nSuite result: ok. 33 passed; 0 failed; 0 skipped; finished in 13.43ms (66.02ms CPU time)\n\nRan 1 test suite in 14.10ms (13.43ms CPU time): 33 tests passed, 0 failed, 0 skipped (33 total tests)\n","passed":true},{"durationMs":37,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"YoloToken.approve(address,uint256)\",\"YoloToken.transfer(address,uint256)\",\"YoloToken.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":4,\"README.md\":117,\"foundry.toml\":19,\"src/YoloToken.sol\":123,\"test/YoloToken.t.sol\":443,\"test/utils/TestBase.sol\":44},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true},{"durationMs":468,"exitCode":0,"name":"slither","output":"slither: no results at low impact or above","passed":true},{"durationMs":255,"exitCode":0,"name":"aderyn","output":"[low] large-numeric-literal at src/YoloToken.sol:27: Large Numeric Literal","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"6099e3af7d44436b38467a224c34c1239c2fbcff2baa86da16ac0feb20549799","verifiedTreeHash":"d46777f02feda2148a2f4ba0b7277cddaa8e156a","verifierVersion":"0.1.0+a26ee00d"},{"checks":[{"durationMs":319,"exitCode":0,"name":"build","output":"Compiling 3 files with Solc 0.8.26\nSolc 0.8.26 finished in 266.38ms\nCompiler run successful!\n","passed":true},{"durationMs":62,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 33 tests for test/YoloToken.t.sol:YoloTokenTest\n[PASS] testFuzz_approveAnyValue(address,uint256) (runs: 256, μ: 65933, ~: 66189)\n[PASS] testFuzz_chainedTransfersConserveSupply(uint256,uint256) (runs: 256, μ: 143722, ~: 145355)\n[PASS] testFuzz_transferAboveBalanceReverts(uint256,uint256) (runs: 256, μ: 89250, ~: 89904)\n[PASS] testFuzz_transferConservesSupply(address,uint256) (runs: 256, μ: 91391, ~: 91729)\n[PASS] testFuzz_transferFromAboveAllowanceReverts(uint256,uint256) (runs: 256, μ: 139749, ~: 140343)\n[PASS] testFuzz_transferFromAccountsAllowance(address,uint256,uint256) (runs: 256, μ: 181045, ~: 184206)\n[PASS] test_approveOverwritesAllowance() (gas: 87353)\n[PASS] test_approveSetsAllowanceAndEmits() (gas: 67814)\n[PASS] test_approveZeroSpenderReverts() (gas: 30675)\n[PASS] test_constructorMintsToAContractDeployerAndEmits() (gas: 192985)\n[PASS] test_constructorMintsWholeSupplyToDeployer() (gas: 23057)\n[PASS] test_deployerCannotPullFromHolderWithoutAllowance() (gas: 89669)\n[PASS] test_launchFlowsArriveWhole() (gas: 190817)\n[PASS] test_metadata() (gas: 17584)\n[PASS] test_noMintOrAdminFunctionExists() (gas: 475006)\n[PASS] test_noPrivilegedCallMovesOrFreezesAHolder() (gas: 411570)\n[PASS] test_plainEtherAndUnknownCalldataAreRejected() (gas: 47982)\n[PASS] test_runtimeHasNoDelegatecallOrSelfdestruct() (gas: 717179)\n[PASS] test_supplyIsOneBillionWithEighteenDecimals() (gas: 16167)\n[PASS] test_transferFromAboveAllowanceReverts() (gas: 136835)\n[PASS] test_transferFromAboveBalanceRevertsEvenWithAllowance() (gas: 135216)\n[PASS] test_transferFromExactAllowanceLeavesZero() (gas: 165531)\n[PASS] test_transferFromSpendsAllowance() (gas: 192641)\n[PASS] test_transferFromToZeroAddressReverts() (gas: 83381)\n[PASS] test_transferFromWithUnlimitedAllowanceDoesNotDecrement() (gas: 167563)\n[PASS] test_transferFromWithoutAllowanceReverts() (gas: 89676)\n[PASS] test_transferMovesBalanceAndEmits() (gas: 77891)\n[PASS] test_transferRevertsFromEmptyAccount() (gas: 33217)\n[PASS] test_transferRevertsOnInsufficientBalance() (gas: 96861)\n[PASS] test_transferToSelfKeepsBalance() (gas: 89865)\n[PASS] test_transferToZeroAddressReverts() (gas: 34706)\n[PASS] test_transferWholeBalance() (gas: 65399)\n[PASS] test_transferZeroAmountSucceeds() (gas: 39745)\nSuite result: ok. 33 passed; 0 failed; 0 skipped; finished in 11.58ms (67.08ms CPU time)\n\nRan 1 test suite in 12.58ms (11.58ms CPU time): 33 tests passed, 0 failed, 0 skipped (33 total tests)\n","passed":true},{"durationMs":23,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"YoloToken.approve(address,uint256)\",\"YoloToken.transfer(address,uint256)\",\"YoloToken.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":4,\"README.md\":117,\"foundry.toml\":19,\"launch.json\":24,\"src/YoloToken.sol\":123,\"test/YoloToken.t.sol\":443,\"test/utils/TestBase.sol\":44},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"6cf4de53c5be7f0afd4a835f6b53be1e5c91d16f1923248a6bbd3cd96df0974d","verifiedTreeHash":"bb7d1dea5161f4fb23563db2cbf0c37764c52ca5","verifierVersion":"0.1.0+a26ee00d"},{"checks":[{"durationMs":667,"exitCode":0,"name":"build","output":"Compiling 5 files with Solc 0.8.26\nSolc 0.8.26 finished in 603.81ms\nCompiler run successful!\n","passed":true},{"durationMs":6883,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 33 tests for test/YoloToken.t.sol:YoloTokenTest\n[PASS] testFuzz_approveAnyValue(address,uint256) (runs: 256, μ: 65934, ~: 66189)\n[PASS] testFuzz_chainedTransfersConserveSupply(uint256,uint256) (runs: 256, μ: 144346, ~: 145355)\n[PASS] testFuzz_transferAboveBalanceReverts(uint256,uint256) (runs: 256, μ: 89424, ~: 89904)\n[PASS] testFuzz_transferConservesSupply(address,uint256) (runs: 256, μ: 91410, ~: 91729)\n[PASS] testFuzz_transferFromAboveAllowanceReverts(uint256,uint256) (runs: 256, μ: 139902, ~: 140343)\n[PASS] testFuzz_transferFromAccountsAllowance(address,uint256,uint256) (runs: 256, μ: 181347, ~: 184212)\n[PASS] test_approveOverwritesAllowance() (gas: 87353)\n[PASS] test_approveSetsAllowanceAndEmits() (gas: 67814)\n[PASS] test_approveZeroSpenderReverts() (gas: 30675)\n[PASS] test_constructorMintsToAContractDeployerAndEmits() (gas: 192985)\n[PASS] test_constructorMintsWholeSupplyToDeployer() (gas: 23057)\n[PASS] test_deployerCannotPullFromHolderWithoutAllowance() (gas: 89669)\n[PASS] test_launchFlowsArriveWhole() (gas: 190817)\n[PASS] test_metadata() (gas: 17584)\n[PASS] test_noMintOrAdminFunctionExists() (gas: 475006)\n[PASS] test_noPrivilegedCallMovesOrFreezesAHolder() (gas: 411570)\n[PASS] test_plainEtherAndUnknownCalldataAreRejected() (gas: 47982)\n[PASS] test_runtimeHasNoDelegatecallOrSelfdestruct() (gas: 717179)\n[PASS] test_supplyIsOneBillionWithEighteenDecimals() (gas: 16167)\n[PASS] test_transferFromAboveAllowanceReverts() (gas: 136835)\n[PASS] test_transferFromAboveBalanceRevertsEvenWithAllowance() (gas: 135216)\n[PASS] test_transferFromExactAllowanceLeavesZero() (gas: 165531)\n[PASS] test_transferFromSpendsAllowance() (gas: 192641)\n[PASS] test_transferFromToZeroAddressReverts() (gas: 83381)\n[PASS] test_transferFromWithUnlimitedAllowanceDoesNotDecrement() (gas: 167563)\n[PASS] test_transferFromWithoutAllowanceReverts() (gas: 89676)\n[PASS] test_transferMovesBalanceAndEmits() (gas: 77891)\n[PASS] test_transferRevertsFromEmptyAccount() (gas: 33217)\n[PASS] test_transferRevertsOnInsufficientBalance() (gas: 96861)\n[PASS] test_transferToSelfKeepsBalance() (gas: 89865)\n[PASS] test_transferToZeroAddressReverts() (gas: 34706)\n[PASS] test_transferWholeBalance() (gas: 65399)\n[PASS] test_transferZeroAmountSucceeds() (gas: 39745)\nSuite result: ok. 33 passed; 0 failed; 0 skipped; finished in 42.31ms (207.83ms CPU time)\n\nRan 24 tests for test/YoloTokenEdges.t.sol:YoloTokenEdgesTest\n[PASS] testFuzz_splitPullsEqualOnePull(uint256,uint256) (runs: 1000, μ: 214442, ~: 216215)\n[PASS] testFuzz_transferAnyAmountAboveBalanceReverts(uint256,uint256) (runs: 1000, μ: 85361, ~: 85830)\n[PASS] testFuzz_transferBetweenAnyTwoHoldersConserves(address,address,uint256,uint256) (runs: 1000, μ: 158137, ~: 161592)\n[PASS] testFuzz_unlimitedAllowanceNeverDecrements(uint256,uint256) (runs: 1000, μ: 213560, ~: 213761)\n[PASS] test_allowanceIsPerOwner() (gas: 184705)\n[PASS] test_allowanceIsPerSpender() (gas: 136874)\n[PASS] test_allowanceOneBelowMaxIsDecremented() (gas: 115851)\n[PASS] test_approveSameValueTwiceDoesNotAccumulate() (gas: 84607)\n[PASS] test_approveZeroRevokes() (gas: 160139)\n[PASS] test_approveZeroSpenderZeroValueReverts() (gas: 30661)\n[PASS] test_balanceFailureDoesNotSpendAllowance() (gas: 157453)\n[PASS] test_ownerHasNoImplicitAllowanceOverOwnTokens() (gas: 85661)\n[PASS] test_secondTransferFromAfterAllowanceSpentReverts() (gas: 197166)\n[PASS] test_secondTransferOfWholeBalanceReverts() (gas: 132579)\n[PASS] test_selfApprovalLetsOwnerPullOwnTokens() (gas: 170355)\n[PASS] test_spenderDoesNotReceiveUnlessRecipient() (gas: 165107)\n[PASS] test_tokenContractCanHoldButNotMoveTokens() (gas: 68098)\n[PASS] test_transferFromMaxUintWithUnlimitedAllowanceReverts() (gas: 87815)\n[PASS] test_transferFromToOwnerKeepsBalanceButSpendsAllowance() (gas: 146214)\n[PASS] test_transferMaxUintReverts() (gas: 37543)\n[PASS] test_transferOneWeiOverSupplyReverts() (gas: 33408)\n[PASS] test_wholeSupplyThroughTransferFrom() (gas: 121167)\n[PASS] test_zeroAmountToZeroAddressStillReverts() (gas: 30738)\n[PASS] test_zeroReceiverFailureDoesNotSpendAllowance() (gas: 147364)\nSuite result: ok. 24 passed; 0 failed; 0 skipped; finished in 42.20ms (160.34ms CPU time)\n\nRan 1 test for test/YoloTokenInvariant.t.sol:YoloTokenInvariantTest\n[PASS]\nYoloTokenInvariantTest invariants:\n[PASS] invariant_allowancesMatchLedger\n[PASS] invariant_balancesMatchLedger\n[PASS] invariant_balancesSumToSupply\n[PASS] invariant_failurePathsRevertCleanly\n[PASS] invariant_totalSupplyIsFixed\n YoloTokenInvariantTest invariants (runs: 256, calls: 16384, reverts: 0)\n\n╭-------------+---------------------------+-------+---------+----------╮\n| Contract    | Selector                  | Calls | Reverts | Discards |\n+======================================================================+\n| YoloHandler | approve                   | 1974  | 0       | 0        |\n|-------------+---------------------------+-------+---------+----------|\n| YoloHandler | approveZero               | 1974  | 0       | 0        |\n|-------------+---------------------------+-------+---------+----------|\n| YoloHandler | transfer                  | 2082  | 0       | 0        |\n|-------------+---------------------------+-------+---------+----------|\n| YoloHandler | transferFrom              | 2015  | 0       | 0        |\n|-------------+---------------------------+-------+---------+----------|\n| YoloHandler | transferFromOverAllowance | 2128  | 0       | 0        |\n|-------------+---------------------------+-------+---------+----------|\n| YoloHandler | transferFromOverBalance   | 2060  | 0       | 0        |\n|-------------+---------------------------+-------+---------+----------|\n| YoloHandler | transferToZero            | 2024  | 0       | 0        |\n|-------------+---------------------------+-------+---------+----------|\n| YoloHandler | transferTooMuch           | 2127  | 0       | 0        |\n╰-------------+---------------------------+-------+---------+----------╯\n\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 6.82s (6.82s CPU time)\n\nRan 3 test suites in 6.82s (6.90s CPU time): 58 tests passed, 0 failed, 0 skipped (58 total tests)\n","passed":true},{"durationMs":29,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"YoloToken.approve(address,uint256)\",\"YoloToken.transfer(address,uint256)\",\"YoloToken.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":4,\"README.md\":117,\"foundry.toml\":19,\"src/YoloToken.sol\":123,\"test/YoloToken.t.sol\":443,\"test/YoloTokenEdges.t.sol\":309,\"test/YoloTokenInvariant.t.sol\":269,\"test/utils/TestBase.sol\":44},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"b5d91ddb33c5578f1763cd70a5199b83167d1b870ec57ca70e013c21dc488a5e","verifiedTreeHash":"f716a1baf66b2573e53af445cdc7f34a25a9dbd1","verifierVersion":"0.1.0+a26ee00d"}]}