{"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":"ae839ba5-5275-475b-8562-18bbc4868b4b","kind":"shape:chain","nodes":[{"acceptedSubmissionHash":"f2f7a62e03814fd2b5885697c9e091150e1b2a0b8100ab78ca582e6601977f1a","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":"08e6c1b7801c197a7d34ea92ef01d22cb768d8aee5c3b12456f5d52ea6c96871","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":"47f05b1b2cbd7afd4149f948457f926abed461ab1eab7af5e7669f1fef70bd71","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":"ecf035771d1d9ee74e601a2f01f548616db3a70637cd098b72850cf221710ee8","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":"cde3ae541bc59b57328642910936c3708746bc452d2f5fe8e2ae0bca535b8f61","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":"0490114e55ef798ba658b2bbf59494c909868ce1d49c9b73389db9e5d7a2f661","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":"5c6de5dd90391fb22a195db8cce1503255867912be46dc8ddcb5fac13f7b80f9","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"tools":[]},"key":"manifest","kind":"code","role":"integrate","skillHash":null,"skillId":null,"state":"accepted"},{"acceptedSubmissionHash":"eff10aa2f030cb7f6a48f3d1e95b5e1c44d4fa2ca2ab5f9a81da187a5770dabe","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: Mutually Assured Destruction (MAD).\nToken name: Mutually Assured Destruction\nToken symbol: MAD\nToken supply: 1,000,000,000 with 18 decimals, all minted once to the deployer in the constructor.","parentJobId":null,"planHash":"ee107357dbdfbb579adcf201db904bc4325cf016ea22da5121f843c62e920b7f","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"ae839ba5-5275-475b-8562-18bbc4868b4b","publication":{"commit":null,"deliveredAt":null,"repoUrl":"https://github.com/identity-md-launches/launch-2467-mutually-assured-destruction"},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[],"schema":"identitymd-work-v1","signals":[{"agentId":"51878","feedbackHash":"48a00cbca6fdd2c4e5f6b4ee8a659a50c52fa0d1718a4f084c24d64775e3224c","nodeKey":"audit_economics","submissionHash":"f2f7a62e03814fd2b5885697c9e091150e1b2a0b8100ab78ca582e6601977f1a","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51873","feedbackHash":"931c18c249bbf772a4fd3c68bbbcc8feed5c975e47c4f796db010d02a9636ec6","nodeKey":"audit_flow","submissionHash":"08e6c1b7801c197a7d34ea92ef01d22cb768d8aee5c3b12456f5d52ea6c96871","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52164","feedbackHash":"bf8efd024a485484bac1bb14fb80e054c48b7280fc10dab6649d3b66ef7c8d04","nodeKey":"audit_judge","submissionHash":"47f05b1b2cbd7afd4149f948457f926abed461ab1eab7af5e7669f1fef70bd71","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51018","feedbackHash":"d867bc5d6aea6f8376638cba99d55c7a5dadfceb38c7dcee1722250732c372ba","nodeKey":"audit_math","submissionHash":"ecf035771d1d9ee74e601a2f01f548616db3a70637cd098b72850cf221710ee8","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51879","feedbackHash":"252b994755c8d62e93bc70911cff1986de816b75e7a62a4da6ada1b7d9168229","nodeKey":"audit_permissions","submissionHash":"cde3ae541bc59b57328642910936c3708746bc452d2f5fe8e2ae0bca535b8f61","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"50965","feedbackHash":"14ec4e4fce8062ae8b9b0220f4bf91d07e6a5dc136aecbfa4de40ce54b08d58f","nodeKey":"build_contract_project","submissionHash":"0490114e55ef798ba658b2bbf59494c909868ce1d49c9b73389db9e5d7a2f661","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"54155","feedbackHash":"924582342ec23803eb426e862540a5a1124f570027eac17e46fbd22c525a56c7","nodeKey":"manifest","submissionHash":"5c6de5dd90391fb22a195db8cce1503255867912be46dc8ddcb5fac13f7b80f9","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"51316","feedbackHash":"7e78a195b0e6b360894de22f0625e6c65d076f872c8c4d28230496ac65d63461","nodeKey":"write_foundry_tests","submissionHash":"eff10aa2f030cb7f6a48f3d1e95b5e1c44d4fa2ca2ab5f9a81da187a5770dabe","tag1":"verification:checks","tag2":"acceptance-v2","value":1}],"site":null,"snapshotHash":"24720b7da6d8efbdbf34ca964862feda46091749030b30b706ae5a9b4ed7b153","state":"completed","submissions":[{"artifacts":[],"attempt":1,"bundleHash":"0deb913e9bcb8529bc93ca85ec9d8cb5360c177d7019a3730a4853e710bdf0ca","device":"1272a65455eb54ca","findings":[],"hash":"0490114e55ef798ba658b2bbf59494c909868ce1d49c9b73389db9e5d7a2f661","nodeId":"20e8d500-8f14-40b2-b16d-e5769729d175","outcome":"completed","summary":"Implemented MAD: 1 billion tokens, 18 decimals, minted once to the deployer. Includes vendored dependencies, success/failure tests, fuzz tests, invariants, and deployment documentation.\n\nVerified with Solidity 0.8.26:\n\n- `forge build` passed.\n- `forge test` passed: 34 tests using the supplied seed.\n- `forge fmt --check` passed.\n\nFull launch integration remains with the independent verifier.","treeHash":"2b9523b8537586deb2b7ebcb6e2cd7e1ebac6879","usage":{"cachedInputTokens":360704,"inputTokens":48035,"model":"gpt-6-astra","outputTokens":13666,"runtime":"codex","turns":5,"wallClockMs":457331}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"42a6bb6aa496cd6b","findings":[{"citation":"resolved","description":"Periphery guide: base contracts. MADToken has no logic of its own; everything approve/transfer/transferFrom do is the vendored lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol. VENDORED.md (line 9) states 'Solidity sources are unmodified upstream files. SHA256SUMS records their upstream bytes' and tells the operator to verify with `sha256sum --check SHA256SUMS`; README.md line 56 repeats that the checksums are included for verification. The recorded hashes are the true upstream v5.0.2 (commit dbb6104c) hashes (I fetched the upstream files and they match SHA256SUMS exactly), but the vendored ERC20.sol and interfaces/draft-IERC6093.sol in the tree have different bytes (ERC20.sol sha256 4a1db79b7b76a41b1d228242ad369c24fb293be6a62cd00b7e286333e965df59 instead of 2d874da1...; draft-IERC6093.sol 94e5638b... instead of 4aea8724...). The byte diff is whitespace-only: `forge fmt` re-wrapped the `_approve(address,address,uint256,bool)` signature at ERC20.sol:284 and the `ERC1155InsufficientBalance` error at draft-IERC6093.sol:121. I confirmed with a whitespace-insensitive diff that no token or statement changed, so there is no behavioural impact and the compiled runtime is the genuine OZ ERC-20. The defect is that the project's dependency-integrity claim is false and the verification step it instructs the launch operator and reviewers to run fails, which is exactly the signal that a tampered base contract would produce. Any reviewer or the verifier following the README cannot distinguish this from a real modification without doing the upstream comparison by hand. Minimal fix: restore the two files to the upstream bytes (I verified in a scratch copy that after restoring them `sha256sum --check` passes, `forge fmt --check` still exits 0 because fmt does not cover lib/, `forge build` succeeds and all tests pass). Alternatively, if the formatted copies are to be kept, regenerate SHA256SUMS and reword VENDORED.md, but then the 'unmodified upstream' claim must be dropped.","line":1,"path":"lib/openzeppelin-contracts/SHA256SUMS","reproduction":"State: the repository as checked in. Input: `cd lib/openzeppelin-contracts && sha256sum --check SHA256SUMS`. Expected (per VENDORED.md line 11 and README.md line 56): every line OK. Actual: `contracts/token/ERC20/ERC20.sol: FAILED`, `contracts/interfaces/draft-IERC6093.sol: FAILED`, `sha256sum: WARNING: 2 computed checksums did NOT match`, exit code 1. Confirming the recorded hashes are upstream's: `curl https://raw.githubusercontent.com/OpenZeppelin/openzeppelin-contracts/dbb6104ce834628e473d2173bbc9d47f81a9eec3/contracts/token/ERC20/ERC20.sol | sha256sum` prints 2d874da1..., which is SHA256SUMS line 1. `diff -w` of the vendored file against that download is empty apart from the re-wrapped signature at line 284-287, so the token's behaviour is unaffected.","severity":"low","snippet":"2d874da1c1478ed22a2d30dcf1a6ec0d09a13f897ca680d55fb49fbcc0e0c5b1  contracts/token/ERC20/ERC20.sol","title":"Vendored OpenZeppelin ERC20 base does not match its recorded upstream checksums; the documented integrity check fails"}],"hash":"08e6c1b7801c197a7d34ea92ef01d22cb768d8aee5c3b12456f5d52ea6c96871","nodeId":"7ecc5261-0db3-4fef-b037-96f21017f253","outcome":"completed","summary":"Review complete. The findings file is written and the working tree is otherwise unchanged.\n\n**Outcome.** MADToken is a plain OpenZeppelin v5.0.2 ERC-20 with one constructor mint of exactly 10^27 units to msg.sender. I traced all three entry points plus the constructor against the Execution Trace, Periphery and First Principles guides and found no defect in token behaviour. All 34 project tests pass, including the 256-run stateful invariant suite, and the compiled runtime has no reachable DELEGATECALL, CALLCODE, SELFDESTRUCT or external CALL.\n\n**One low finding, in the Periphery area.** The vendored OpenZeppelin base contracts fail the integrity check the project itself documents.\n\n- VENDORED.md states the Solidity sources are unmodified upstream bytes and tells the operator to run the checksum file. Running it reports two failures, on ERC20.sol and draft-IERC6093.sol.\n- I fetched the real upstream files at the pinned commit. Their hashes match the checksum file, so the vendored copies are what drifted. The only difference is formatter whitespace, so there is no behavioural impact.\n- The defect is a false integrity claim that produces the same signal a tampered base contract would. Fix: restore the two files to upstream bytes. I confirmed in a scratch copy that this keeps the formatter check, build and tests green.\n\n**Coverage record.** Eight rows: the three listed entry points and the constructor hold, three invariants hold (fixed supply, exact launch flows, forbidden-opcode scan), and the vendored base contracts row points to finding 1. Nothing was left unreached. The static-analysis lead about the large numeric literal is a compile-time constant with the correct value and was not promoted.\n\n**Not in scope and not checked.** The protected launch test needs the verifier's v4-core and factory harness, which are not in this tree, so the real pool seed and swap were not executed here. Chain and pair-token addresses in the README were not verified against a network file, since none was supplied.","treeHash":null,"usage":{"cachedInputTokens":516086,"inputTokens":258,"model":"claude-fable-5-1","outputTokens":13007,"runtime":"claude","turns":25,"wallClockMs":196986}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"63458a1bd2b2d376","findings":[{"citation":"resolved","description":"Merged from the four specialist reports (audit_flow, audit_math, audit_permissions, audit_economics), which all describe the same root cause. MADToken has no logic of its own: approve, transfer and transferFrom are entirely the vendored lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol. VENDORED.md line 9 states the vendored Solidity sources are unmodified upstream v5.0.2 files and that SHA256SUMS records their bytes; line 11 tells the reader to verify with `sha256sum --check SHA256SUMS`, and README.md line 56 points at those checksums as the dependency's provenance. I reproduced the failure: the check reports FAILED for contracts/token/ERC20/ERC20.sol and contracts/interfaces/draft-IERC6093.sol and exits 1. I fetched both files from the pinned upstream commit dbb6104ce834628e473d2173bbc9d47f81a9eec3 and confirmed the recorded sums are the genuine upstream hashes (2d874da1... and 4aea8724...). A plain diff of the tree copies against upstream shows exactly two hunks, both pure line re-wrapping at line_length 100 (the `_approve(address,address,uint256,bool) internal virtual` header at ERC20.sol:284-287 and the `ERC1155InsufficientBalance` error at draft-IERC6093.sol:121-123); `diff -w` apart from those wraps is empty, so no token or statement changed and the compiled ERC-20 is semantically upstream v5.0.2. The defect is therefore in the evidence chain, not in token behaviour: the repository's own integrity claim is false as shipped, and anyone who follows the documented verification step gets a FAILED on the core ERC-20 file, which is the same signal a tampered base contract would give, and must redo the upstream comparison by hand to rule tampering out. Severity low: no funds, supply, launch flow or permission is affected. Fix, to be made by whoever owns lib/ (reviewers may not touch it): either restore the two files to their exact upstream bytes (compiled output is unchanged; forge fmt --check still passes since fmt does not cover lib/), or regenerate SHA256SUMS from the files as shipped and reword VENDORED.md to say the sources were reformatted with forge fmt and are semantically identical to upstream. The 'unmodified upstream files' claim cannot be kept as written.","line":9,"path":"lib/openzeppelin-contracts/VENDORED.md","reproduction":"State: the working tree at commit 23145ef (same lib/ bytes as bfba40f). Input: `cd lib/openzeppelin-contracts && sha256sum --check SHA256SUMS` (the command VENDORED.md line 11 gives). Expected, per VENDORED.md line 9: six `OK` lines, exit 0. Actual: `contracts/token/ERC20/ERC20.sol: FAILED`, `contracts/interfaces/draft-IERC6093.sol: FAILED`, the other four lines OK, `sha256sum: WARNING: 2 computed checksums did NOT match`, exit 1. Cause: `curl https://raw.githubusercontent.com/OpenZeppelin/openzeppelin-contracts/dbb6104ce834628e473d2173bbc9d47f81a9eec3/contracts/token/ERC20/ERC20.sol | sha256sum` prints 2d874da1c1478ed22a2d30dcf1a6ec0d09a13f897ca680d55fb49fbcc0e0c5b1 (SHA256SUMS line 1) while the vendored file hashes to 4a1db79b7b76a41b1d228242ad369c24fb293be6a62cd00b7e286333e965df59; `diff upstream_ERC20.sol lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol` shows only `284c284,287` (the `_approve(..., bool emitEvent) internal virtual {` header split over four lines), and the same for draft-IERC6093.sol at `121c121,123`. Semantic equivalence confirmed: `forge build` succeeds and all 58 project tests pass with the seed in README.md.","severity":"low","snippet":"Only the ERC-20 implementation, its transitive Solidity imports, and the MIT license are vendored. Solidity sources are unmodified upstream files. `SHA256SUMS` records their upstream bytes. All dependencies needed to build MADToken are ordinary repository files; no package installation, submodule, or network access is needed.","title":"Vendored OpenZeppelin provenance check fails: ERC20.sol and draft-IERC6093.sol were reformatted after SHA256SUMS was recorded, so the documented `sha256sum --check` step reports FAILED"}],"hash":"47f05b1b2cbd7afd4149f948457f926abed461ab1eab7af5e7669f1fef70bd71","nodeId":"4c29a0ff-d390-44d8-a4dd-505a450827c5","outcome":"completed","summary":"The review is complete and written to `.imd-findings.json`. No tracked file was changed. The build output directory and the findings file are untracked and ignored by git.\n\n**Outcome:** one low finding, merged from the four identical specialist reports, and all three entry points hold.\n\n**The kept finding.** The vendoring note in VENDORED.md claims the OpenZeppelin sources are unmodified upstream bytes and tells readers to verify with the checksum file. That check fails for ERC20.sol and draft-IERC6093.sol. I reproduced it: the recorded sums are the real upstream hashes at the pinned commit, and the tree copies differ only by two formatter line-wraps, so the compiled token is semantically genuine v5.0.2. The defect is a false integrity claim, not token behaviour, so it stays at low. The fix belongs to whoever owns lib/, either restoring the upstream bytes or regenerating the sums and dropping the \"unmodified\" wording.\n\n**Dropped leads.** The aderyn large-numeric-literal line points at a readable, correct constant equal to the manifest supply. The standard ERC-20 approve race is documented in the README and is not a defect.\n\n**Independent checks I ran:**\n- Traced approve, transfer and transferFrom through the vendored ERC20: zero-address reverts, exact balance and allowance accounting, no fee, burn, owner or hook path.\n- Built the project and ran the full suite with the README's fuzz seed. All 58 tests passed, including the stateful and hostile invariants.\n- Scanned the compiled runtime and creation code: no DELEGATECALL, CALLCODE or SELFDESTRUCT, no immutables or unlinked libraries, and both sizes are far below the protocol limits.\n- Confirmed the parameterless constructor matches the manifest's empty constructorArgs and that the launch.json keys, types, address casing and supply string are consistent with the tree and the protected launch tests.\n\nThe coverage record answers the three listed entry points as holds, plus three invariant rows for supply, CREATE2 deployability and the manifest.","treeHash":null,"usage":{"cachedInputTokens":610138,"inputTokens":354,"model":"claude-fable-5-1","outputTokens":8255,"runtime":"claude","turns":13,"wallClockMs":168629}},{"artifacts":[],"attempt":1,"bundleHash":"9d1e3cff4b35d7cfc0c284fc89187f1bf97a3f12768dda87f8c2eb23c577a663","device":"989e104186cad5ec","findings":[],"hash":"5c6de5dd90391fb22a195db8cce1503255867912be46dc8ddcb5fac13f7b80f9","nodeId":"f1a9b9ac-7804-4d73-9715-e5959619ea7a","outcome":"completed","summary":"Created [launch.json](/home/imd1550/.identitymd/work/ae839ba5-5275-475b-8562-18bbc4868b4b/f1a9b9ac-7804-4d73-9715-e5959619ea7a/launch.json) matching `MADToken`’s constructor, supply, and the exact required pool and economics values.\n\nVerified manifest fields and constructor ABI. `forge build` succeeded; `forge test` passed all 34 tests with the supplied fuzz seed.\n\nOnly `launch.json` changed outside the permitted scratch directory.","treeHash":"17e18a32d9507ec7a5c6e7ae6772b87b050e4b6e","usage":{"cachedInputTokens":197120,"inputTokens":25646,"model":"gpt-6-astra","outputTokens":2783,"runtime":"codex","turns":3,"wallClockMs":104542}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"4faf975f1178e1f8","findings":[{"citation":"resolved","description":"lib/openzeppelin-contracts/VENDORED.md:9 states that the vendored Solidity sources are unmodified upstream files and that SHA256SUMS records their upstream bytes, and README.md:53-56 relies on that record as the dependency's provenance. The recorded hashes are indeed the upstream v5.0.2 bytes (I fetched commit dbb6104ce834628e473d2173bbc9d47f81a9eec3 and the upstream files hash to exactly the recorded values), but two files in the tree were reformatted after the record was written: contracts/token/ERC20/ERC20.sol (the `_approve(address,address,uint256,bool)` header at lines 284-287 is wrapped onto four lines; upstream has it on one line) and contracts/interfaces/draft-IERC6093.sol (the `ERC1155InsufficientBalance` error at lines 121-123 is wrapped). The change is whitespace only: `diff -w` against upstream shows no token-level difference beyond the line wrap, the ERC-20 logic (transfer, approve, transferFrom, _update, _spendAllowance) is byte-for-byte the upstream code, and with bytecode_hash = \"none\" the compiled runtime is unaffected. The defect is in the trust story, not the token: a reviewer or the release/attestation step who follows the project's own instruction to run `sha256sum --check SHA256SUMS` gets two FAILED lines and must either assume tampering or redo the upstream comparison that the checksum file was supposed to make unnecessary. Minimal fix (either one, chosen by whoever owns lib/): restore the two files to their exact upstream bytes (compiled output does not change), or regenerate SHA256SUMS from the files as formatted and drop the claim that the sources are byte-identical to upstream.","line":1,"path":"lib/openzeppelin-contracts/SHA256SUMS","reproduction":"State: the working tree at commit bfba40f. Input: `cd lib/openzeppelin-contracts && sha256sum --check SHA256SUMS` (the exact command VENDORED.md:11 gives). Expected: six `OK` lines. Actual: `contracts/token/ERC20/ERC20.sol: FAILED`, `contracts/interfaces/draft-IERC6093.sol: FAILED`, `sha256sum: WARNING: 2 computed checksums did NOT match`; the other four files pass. Cross-check: `curl` of the two files at upstream commit dbb6104c hashes to the recorded 2d874da1... and 4aea8724..., and `diff` of the tree copies against them shows only lines 284-287 of ERC20.sol and lines 121-123 of draft-IERC6093.sol differing, by line wrapping alone.","severity":"low","snippet":"2d874da1c1478ed22a2d30dcf1a6ec0d09a13f897ca680d55fb49fbcc0e0c5b1  contracts/token/ERC20/ERC20.sol","title":"Vendored OpenZeppelin files no longer match their recorded SHA256SUMS; the documented integrity check fails"}],"hash":"cde3ae541bc59b57328642910936c3708746bc452d2f5fe8e2ae0bca535b8f61","nodeId":"44c79090-5475-4b8c-9824-bc81b3ebacad","outcome":"completed","summary":"The review is complete and `.imd-findings.json` holds one low finding and eight coverage rows.\n\n**Outcome.** The MAD token's permission model is clean. The contract is a 17-line wrapper over OpenZeppelin v5.0.2 ERC20 with a no-argument constructor that mints the whole supply to the deployer. There is no owner, role, modifier, initializer, proxy, fee path, exemption list or external call, and the compiled ABI exposes only approve, transfer and transferFrom as state-changing entry points. I traced all three through the inherited code, checked the approve/transferFrom and transfer/transferFrom pairs for asymmetric writes, confirmed the mint and burn branches of the internal update function are unreachable after construction, scanned the runtime bytecode for reachable DELEGATECALL, CALLCODE and SELFDESTRUCT, and ran the project's full suite with the README's fuzz seed. All 34 tests pass, including the stateful invariants. The protected launch floor's requirements on supply, decimals, privileged selectors and whole-amount flows are met.\n\n**The one finding (low).** The vendored OpenZeppelin directory ships a SHA256SUMS file and instructs readers to verify with it, and the README leans on that record as the dependency's provenance. Running that check fails for two files. I fetched the pinned upstream commit and confirmed the recorded hashes are the genuine upstream bytes, but the tree copies of ERC20.sol and draft-IERC6093.sol were line-wrapped by the formatter after the record was written. The logic is unchanged and the compiled bytecode is unaffected, so this is an integrity-claim defect rather than a token defect. The fix is either to restore the two files to upstream bytes or to regenerate the checksums and soften the \"unmodified\" claim.\n\n**Not reported.** The standard ERC-20 approve race is documented in the README and is design, not a defect. The README's claim that the launch targets Ethereum mainnet is consistent with the FWA pair token, which I confirmed has code and the symbol FWA at the documented address on mainnet. No launch.json exists yet, which is expected at this stage.\n\n**Trust assumption to carry forward.** The immediate deployer receives every token and has only ordinary holder rights afterwards. Deploying through anything other than the intended factory sends the supply to that contract.\n\nNo files other than `.imd-findings.json` were created, and no proof tests were needed since nothing rose above low severity.","treeHash":null,"usage":{"cachedInputTokens":689355,"inputTokens":290,"model":"claude-fable-5-1","outputTokens":14234,"runtime":"claude","turns":28,"wallClockMs":228663}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"30a6c1a419ef4f9c","findings":[{"citation":"resolved","description":"The token's entire arithmetic (balance subtraction, unchecked additions, allowance spending, supply accounting) lives in the vendored OpenZeppelin ERC20.sol, and the project's stated way for a reviewer or verifier to confirm that this copy is the audited upstream code is `sha256sum --check SHA256SUMS` (VENDORED.md line 11; README.md line 56 also points to these checksums). That check fails for two of the five Solidity files: contracts/token/ERC20/ERC20.sol and contracts/interfaces/draft-IERC6093.sol. I fetched both files from the pinned upstream commit dbb6104ce834628e473d2173bbc9d47f81a9eec3 and diffed them: the only differences are formatter line-wrapping (the `_approve(..., bool emitEvent) internal virtual {` signature at ERC20.sol:284-287 and the `ERC1155InsufficientBalance` error declaration at draft-IERC6093.sol:121-123 were split across lines, consistent with `forge fmt` at line_length 100). Compiled behaviour is unchanged, and I verified that every arithmetic path in ERC20._update/_spendAllowance is the upstream v5.0.2 logic. The defect is that the delivered integrity evidence is false: VENDORED.md asserts the sources are byte-for-byte upstream and that SHA256SUMS records their bytes, but a verifier running the documented command gets `WARNING: 2 computed checksums did NOT match`, and cannot distinguish a harmless reformat from a semantic edit without doing the upstream diff themselves. Because the math audit of this token reduces almost entirely to 'is this really OZ v5.0.2 ERC20', a failing provenance check is the one place the math guarantee can be silently undermined. Fix (one of): restore the two files to their exact upstream bytes (so the recorded sums pass and the 'unmodified' statement is true), or regenerate SHA256SUMS from the files as shipped and reword VENDORED.md to say the sources were reformatted with forge fmt and are semantically identical to upstream. Note the submission rules forbid a reviewer from touching lib/, so this must be done by the author.","line":9,"path":"lib/openzeppelin-contracts/VENDORED.md","reproduction":"State: the repository as checked out (commit bfba40f). Input: run `cd lib/openzeppelin-contracts && sha256sum --check SHA256SUMS`. Expected (per VENDORED.md lines 9 and 11): every line reports OK. Actual: `contracts/token/ERC20/ERC20.sol: FAILED`, `contracts/interfaces/draft-IERC6093.sol: FAILED`, `sha256sum: WARNING: 2 computed checksums did NOT match`, exit status 1. The recorded hash 2d874da1...c5b1 is the hash of upstream ERC20.sol at commit dbb6104c (fetched from raw.githubusercontent.com and hashed: matches the recorded value), while the vendored file hashes differently. `diff -w` of vendored vs upstream is empty apart from the two rewrapped declarations listed above, so the mismatch is formatting-only, but the documented integrity check still fails.","severity":"low","snippet":"Only the ERC-20 implementation, its transitive Solidity imports, and the MIT license are vendored. Solidity sources are unmodified upstream files. `SHA256SUMS` records their upstream bytes. All dependencies needed to build MADToken are ordinary repository files; no package installation, submodule, or network access is needed.","title":"Vendored OpenZeppelin provenance check fails: SHA256SUMS does not match the ERC20.sol and draft-IERC6093.sol bytes actually in the tree"}],"hash":"ecf035771d1d9ee74e601a2f01f548616db3a70637cd098b72850cf221710ee8","nodeId":"e8309d98-b1ad-4b67-9043-6e0ab0ab2ff0","outcome":"completed","summary":"The review is complete and written to `.imd-findings.json`.\n\n**Outcome.** The MAD token's math holds. The contract is a two-line wrapper around OpenZeppelin ERC20 v5.0.2 with one constructor mint, and every arithmetic path in my area (Math Precision, Boundary, Numerical Gap) traced correctly. I found one low-severity provenance defect and no defects in the token's arithmetic.\n\n**What I checked and confirmed:**\n- **Supply constant.** The literal is constant-folded to exactly 10^27 and that value appears in the creation bytecode. The aderyn \"large numeric literal\" lead is style only. Decimals return 18, matching the brief.\n- **transfer and transferFrom.** The balance check reverts before the unchecked subtraction, the unchecked addition cannot overflow because the balance sum equals the fixed supply, and full-supply self-transfers stay exact. Allowance of max is infinite but still bounded by balance. Allowance of max minus one is finite and decrements. All of this was exercised by the existing 34 tests plus 7 scratch edge tests I ran, all passing.\n- **Boundary surface.** The token makes no external calls, has no payable function, no receive or fallback, decodes no bytes, and its only sentinel branches are the zero-address guards. There is nothing for a boundary corner case to hit.\n- **Launch splits.** The 10/85/5 percent flows and the 2+8 percent swarm share are exact integers of 10^27 with no truncation, and the token takes no fee, so the protected launch flows arrive whole.\n\n**The one finding (low).** The vendoring note in lib/openzeppelin-contracts/VENDORED.md states the Solidity sources are unmodified upstream bytes and tells reviewers to run the checksum command. That command fails for two of the five files. I fetched both from the pinned upstream commit and diffed them. The differences are only two declarations rewrapped by a formatter, so compiled behaviour is unchanged. The defect is that the documented integrity evidence is false, which matters because the token's entire math guarantee rests on this copy being real OZ. The fix is either restoring the exact upstream bytes or regenerating the checksum file and rewording the note. The author must do it, since lib/ is off limits to reviewers.\n\n**Not reached.** The deployer-side pool price and liquidity math lives outside this tree. I sanity-checked that the opening sqrtPriceX96 and single-sided liquidity for the 85 percent seed fit v4's integer bounds, but could not verify the deployer's tick choice.\n\nThe coverage record answers all three listed entry points as holds, plus rows for the constructor, two invariants, the boundary surface, the vendored-library finding, and the unreached pool math. The scratch test under test/scratch/ is mine and is not part of the submission.","treeHash":null,"usage":{"cachedInputTokens":844483,"inputTokens":322,"model":"claude-fable-5-1","outputTokens":15961,"runtime":"claude","turns":26,"wallClockMs":235283}},{"artifacts":[],"attempt":1,"bundleHash":"3aa5e27172ce7bc0b5655d5b83d3bda21bdd89d733f64e5ba73a04551e03b5f2","device":"6b0a28df3d585600","findings":[],"hash":"eff10aa2f030cb7f6a48f3d1e95b5e1c44d4fa2ca2ab5f9a81da187a5770dabe","nodeId":"f7513f20-ac63-4bb1-bfe1-3e649d00dc93","outcome":"completed","summary":"I added 24 tests in two new files and found no defects in the token, so I didn't write `.imd-findings.json`. The full suite passes with the verifier's fuzz seed: 58 tests in 5 suites, 0 failures, and `forge build` is clean. I changed only files under `test/`; the earlier contributor's tests and helper are untouched. Nothing is committed.\n\nThe token is plain OpenZeppelin ERC-20. Its constructor mints 10^27 units (1,000,000,000 with 18 decimals) once to the deployer, and nothing overrides the transfer or approval logic. The existing suite already covered the basics well, so the new tests go after what it left out.\n\n**`test/MADToken.adversarial.t.sol`** (22 tests):\n- **Edge cases:** one wei over the balance, a one-wei transfer and back, repeating the same transfer or `transferFrom` (neither can overdraw), and an allowance of max−1 behaving as a normal finite allowance.\n- **Callers the code might not expect:**\n  - The owner needs an allowance even to move their own tokens with `transferFrom`.\n  - Allowances only work in the direction they were given.\n  - An unlimited allowance still can't move more than the holder's balance.\n  - After giving away its supply, the deployer has no special rights.\n  - Contracts can hold and spend tokens exactly like ordinary wallets.\n  - A call claiming to come from the zero address is refused.\n- **Tokens sent to the token's own address** stay stuck there but still count toward the supply. This is standard behaviour the README already documents, not a defect.\n- **Missing functions:** there is no fallback, no `permit`, no `nonces` and no rescue function.\n- **Bytecode scans:** the deployed code contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, and makes no external calls or contract creations.\n- **Fuzz tests (1,000 runs each):**\n  - Random calldata from a stranger changes no balance, allowance or supply.\n  - Whether a `transferFrom` succeeds, and what it moves, matches a model over random owner, spender, recipient, balance, allowance and amount, including the zero address.\n  - Two transfers add up to the same as one.\n  - Sending tokens there and back restores both balances.\n  - Approving twice changes nothing, and the latest approval wins.\n\n**`test/MADToken.hostile.invariant.t.sol`**: a second random-sequence test (256 runs of 100 calls). It uses six actors, one of them the token's own address. It mixes valid calls with hostile ones: the zero address as receiver, spender or owner, amounts one wei over the balance or allowance, and arbitrary function calls. Every call's success or failure must match the model. The checks after each sequence:\n- the supply never changes and is fully held by the actors;\n- each actor's balance equals what they started with, plus what they received, minus what they sent;\n- allowances match the model, and those involving the zero address stay zero;\n- name, symbol and decimals never change.\n\nA separate fixed test confirms the random-sequence tester really does produce both successful moves and refused calls. I added it because a per-run version of that check could fail by chance: some runs contain only one call.","treeHash":"9f0a558c758e4fc3e77246e48efb3ad2df43dac8","usage":{"cachedInputTokens":775691,"inputTokens":30,"model":"claude-opus-5-5","outputTokens":18033,"runtime":"claude","turns":16,"wallClockMs":288352}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"2a6239e0c1b8c774","findings":[{"citation":"resolved","description":"VENDORED.md states the vendored Solidity sources are unmodified upstream v5.0.2 files and instructs reviewers to verify them with `sha256sum --check SHA256SUMS`. That check fails for contracts/token/ERC20/ERC20.sol and contracts/interfaces/draft-IERC6093.sol. The recorded sums do match upstream v5.0.2 (fetched from the OpenZeppelin tag and re-hashed: 2d874da1... and 4aea8724...), but the files in the tree were re-wrapped by a formatter after vendoring: ERC20.sol line 284 splits the `_approve(..., bool emitEvent) internal virtual {` signature across four lines and draft-IERC6093.sol line 121 splits `error ERC1155InsufficientBalance(...)` across three. A whitespace-insensitive diff against upstream is empty, so the compiled ERC-20 is semantically the genuine v5.0.2 implementation and no transfer, approval, supply or launch-flow behaviour is affected. The defect is that the repository's own provenance guarantee is false as shipped: anyone who follows the documented verification step gets FAILED on the core ERC-20 file and cannot distinguish this benign reflow from a malicious edit without doing the upstream diff themselves. Not an economic defect; reported because it sits on the audit's evidence chain for the token's only dependency. Fix: either restore the two upstream byte-exact files (and exclude lib/ from forge fmt via `[fmt] ignore`), or regenerate SHA256SUMS from the files actually in the tree and drop the 'unmodified upstream bytes' claim.","line":9,"path":"lib/openzeppelin-contracts/VENDORED.md","reproduction":"State: the tree as committed (bfba40f). Steps: `cd lib/openzeppelin-contracts && sha256sum --check SHA256SUMS`. Expected (per VENDORED.md line 9-11): all six lines OK. Actual: `contracts/token/ERC20/ERC20.sol: FAILED`, `contracts/interfaces/draft-IERC6093.sol: FAILED`, `WARNING: 2 computed checksums did NOT match`. Confirming cause: `curl https://raw.githubusercontent.com/OpenZeppelin/openzeppelin-contracts/v5.0.2/contracts/token/ERC20/ERC20.sol | sha256sum` gives 2d874da1c1478ed22a2d30dcf1a6ec0d09a13f897ca680d55fb49fbcc0e0c5b1 (the recorded sum); `diff -w upstream_ERC20.sol lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol` shows only the line-wrap of the `_approve` signature at line 284 and no other change.","severity":"low","snippet":"Only the ERC-20 implementation, its transitive Solidity imports, and the MIT license are vendored. Solidity sources are unmodified upstream files. `SHA256SUMS` records their upstream bytes. All dependencies needed to build MADToken are ordinary repository files; no package installation, submodule, or network access is needed.","title":"Vendored OpenZeppelin provenance check fails: two files were reformatted after their SHA256SUMS were recorded"}],"hash":"f2f7a62e03814fd2b5885697c9e091150e1b2a0b8100ab78ca582e6601977f1a","nodeId":"3d721c5b-eb79-4a3c-b84f-a4a80be632d3","outcome":"completed","summary":"The review is complete and written to `.imd-findings.json`. No tracked file was changed.\n\n**Result: the assigned area is clean.** MADToken is an unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint of 10^27 units to `msg.sender`, no constructor arguments, and no owner, fee, burn, pause, hook or external call. Every item in the Economic Security, Invariant and Flow Gap guides either does not apply or holds when traced through the actual `_update`, `_approve` and `_spendAllowance` code.\n\nWhat I verified:\n- **Supply conservation.** The only mint path runs once in the constructor, `_burn` has no caller, and the runtime bytecode contains no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT. The invariant suite passes under the pinned seed and three extra seeds.\n- **Launch flows arrive whole.** Factory to distributor, distributor to claimant, and both PoolManager legs move exactly the requested amount, so the 10/85/5 split and the seed cannot arrive short.\n- **Entry points.** All three state-changing functions trace to standard OZ behaviour, including the zero-address sentinels and the from-equals-zero `transferFrom` path, which reverts rather than minting.\n- **Leads.** The aderyn large-literal line evaluates to exactly 10^27. Slither reported nothing.\n\nOne low finding, outside the economic area but on the audit's evidence chain: the vendored library's own `sha256sum --check SHA256SUMS` step fails for `ERC20.sol` and `draft-IERC6093.sol`. I fetched upstream v5.0.2 and confirmed the recorded sums are upstream's and the only differences are formatter line wraps, so the compiled token is semantically genuine. The provenance claim in VENDORED.md is nonetheless false as shipped.\n\nNot run: the protected `CustomTokenProtectedTest`, which needs the network's v4-core and launch harness that are absent from this tree. The coverage record has eight rows covering all three listed entry points plus the invariants checked.","treeHash":null,"usage":{"cachedInputTokens":881134,"inputTokens":322,"model":"claude-fable-5-1","outputTokens":13206,"runtime":"claude","turns":28,"wallClockMs":248902}}],"verification":[{"checks":[{"durationMs":488,"exitCode":0,"name":"build","output":"Compiling 10 files with Solc 0.8.26\nSolc 0.8.26 finished in 425.52ms\nCompiler run successful!\n","passed":true},{"durationMs":4132,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 2 tests for test/LaunchFlow.t.sol:LaunchFlowTest\n[PASS] testFuzz_constructorMintsToImmediateDeployer(address) (runs: 512, μ: 11408, ~: 11905)\n[PASS] test_factoryGetsEntireSupplyAndLaunchTransfersArriveWhole() (gas: 678620)\nSuite result: ok. 2 passed; 0 failed; 0 skipped; finished in 15.03ms (14.88ms CPU time)\n\nRan 31 tests for test/MADToken.t.sol:MADTokenTest\n[PASS] testFuzz_arbitraryRecipient(address,uint256) (runs: 512, μ: 74379, ~: 75515)\n[PASS] testFuzz_transferAboveAllowanceAlwaysReverts(uint256) (runs: 512, μ: 99925, ~: 100329)\n[PASS] testFuzz_transferAboveBalanceAlwaysReverts(uint256,uint256) (runs: 512, μ: 104556, ~: 104901)\n[PASS] testFuzz_transferConservesSupply(uint256) (runs: 512, μ: 74806, ~: 75146)\n[PASS] testFuzz_transferFromConservesSupplyAndAllowance(uint256,uint256) (runs: 512, μ: 137267, ~: 138873)\n[PASS] test_approvalDoesNotRequireBalance() (gas: 65700)\n[PASS] test_approveEmitsEventWithoutMovingBalance() (gas: 75094)\n[PASS] test_approveReplacesAndRevokesAllowance() (gas: 155721)\n[PASS] test_approveZeroSpenderReverts() (gas: 34685)\n[PASS] test_constructorEmitsExactlyOneMint() (gas: 6951)\n[PASS] test_deployerCannotSpendHolderTokensWithoutApproval() (gas: 146881)\n[PASS] test_directEtherPaymentIsRejected() (gas: 38924)\n[PASS] test_entireSupplyCanMoveAndMoveBack() (gas: 120606)\n[PASS] test_exactAllowanceCanBeExhausted() (gas: 148400)\n[PASS] test_infiniteAllowanceIsNotReduced() (gas: 183389)\n[PASS] test_insufficientBalanceRevertsWithoutMovingTokens() (gas: 44819)\n[PASS] test_maximumUintTransferReverts() (gas: 37157)\n[PASS] test_metadataAndInitialSupply() (gas: 73811)\n[PASS] test_noMintBurnOrAdministrativeEntrypoints() (gas: 666923)\n[PASS] test_selfTransferPreservesBalance() (gas: 42707)\n[PASS] test_transferEmitsEventAndMovesExactAmount() (gas: 79862)\n[PASS] test_transferFromExceedingAllowanceRevertsAtomically() (gas: 99904)\n[PASS] test_transferFromInsufficientBalanceRestoresAllowance() (gas: 105651)\n[PASS] test_transferFromSpendsOnlyItsAllowanceAndEmitsTransfer() (gas: 195891)\n[PASS] test_transferFromToSelfSpendsAllowanceWithoutChangingBalance() (gas: 94682)\n[PASS] test_transferFromZeroOwnerCannotMint() (gas: 43332)\n[PASS] test_transferFromZeroReceiverRestoresAllowance() (gas: 95404)\n[PASS] test_transferToContractDoesNotCallRecipient() (gas: 166003)\n[PASS] test_transferToZeroRevertsIncludingZeroAmount() (gas: 65990)\n[PASS] test_zeroTransferFromEmptyAccountEmitsEvent() (gas: 50058)\n[PASS] test_zeroTransferFromWithoutAllowanceSucceeds() (gas: 50899)\nSuite result: ok. 31 passed; 0 failed; 0 skipped; finished in 17.30ms (88.14ms CPU time)\n\nRan 1 test for test/MADToken.invariant.t.sol:MADTokenInvariantTest\n[PASS]\nMADTokenInvariantTest invariants:\n[PASS] invariant_allowancesMatchModel\n[PASS] invariant_supplyAndBalancesMatchModel\n MADTokenInvariantTest invariants (runs: 256, calls: 16384, reverts: 0)\n\n╭------------+-----------------+-------+---------+----------╮\n| Contract   | Selector        | Calls | Reverts | Discards |\n+===========================================================+\n| MADHandler | approve         | 4140  | 0       | 0        |\n|------------+-----------------+-------+---------+----------|\n| MADHandler | transfer        | 4040  | 0       | 0        |\n|------------+-----------------+-------+---------+----------|\n| MADHandler | transferFrom    | 4074  | 0       | 0        |\n|------------+-----------------+-------+---------+----------|\n| MADHandler | transferTooMuch | 4130  | 0       | 0        |\n╰------------+-----------------+-------+---------+----------╯\n\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 4.08s (4.08s CPU time)\n\nRan 3 test suites in 4.08s (4.11s CPU time): 34 tests passed, 0 failed, 0 skipped (34 total tests)\n","passed":true},{"durationMs":30,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"MADToken.approve(address,uint256)\",\"MADToken.transfer(address,uint256)\",\"MADToken.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":3,\"README.md\":109,\"foundry.toml\":22,\"src/MADToken.sol\":17,\"test/LaunchFlow.t.sol\":84,\"test/MADToken.invariant.t.sol\":123,\"test/MADToken.t.sol\":391,\"test/helpers/TestBase.sol\":49},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true},{"durationMs":690,"exitCode":0,"name":"slither","output":"slither: no results at low impact or above","passed":true},{"durationMs":318,"exitCode":0,"name":"aderyn","output":"[low] large-numeric-literal at src/MADToken.sol:10: Large Numeric Literal","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"0490114e55ef798ba658b2bbf59494c909868ce1d49c9b73389db9e5d7a2f661","verifiedTreeHash":"2b9523b8537586deb2b7ebcb6e2cd7e1ebac6879","verifierVersion":"0.1.0+ead9012e"},{"checks":[{"durationMs":557,"exitCode":0,"name":"build","output":"Compiling 10 files with Solc 0.8.26\nSolc 0.8.26 finished in 492.14ms\nCompiler run successful!\n","passed":true},{"durationMs":4264,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 2 tests for test/LaunchFlow.t.sol:LaunchFlowTest\n[PASS] testFuzz_constructorMintsToImmediateDeployer(address) (runs: 512, μ: 11408, ~: 11905)\n[PASS] test_factoryGetsEntireSupplyAndLaunchTransfersArriveWhole() (gas: 678620)\nSuite result: ok. 2 passed; 0 failed; 0 skipped; finished in 18.78ms (19.04ms CPU time)\n\nRan 31 tests for test/MADToken.t.sol:MADTokenTest\n[PASS] testFuzz_arbitraryRecipient(address,uint256) (runs: 512, μ: 74379, ~: 75515)\n[PASS] testFuzz_transferAboveAllowanceAlwaysReverts(uint256) (runs: 512, μ: 99925, ~: 100329)\n[PASS] testFuzz_transferAboveBalanceAlwaysReverts(uint256,uint256) (runs: 512, μ: 104556, ~: 104901)\n[PASS] testFuzz_transferConservesSupply(uint256) (runs: 512, μ: 74806, ~: 75146)\n[PASS] testFuzz_transferFromConservesSupplyAndAllowance(uint256,uint256) (runs: 512, μ: 137267, ~: 138873)\n[PASS] test_approvalDoesNotRequireBalance() (gas: 65700)\n[PASS] test_approveEmitsEventWithoutMovingBalance() (gas: 75094)\n[PASS] test_approveReplacesAndRevokesAllowance() (gas: 155721)\n[PASS] test_approveZeroSpenderReverts() (gas: 34685)\n[PASS] test_constructorEmitsExactlyOneMint() (gas: 6951)\n[PASS] test_deployerCannotSpendHolderTokensWithoutApproval() (gas: 146881)\n[PASS] test_directEtherPaymentIsRejected() (gas: 38924)\n[PASS] test_entireSupplyCanMoveAndMoveBack() (gas: 120606)\n[PASS] test_exactAllowanceCanBeExhausted() (gas: 148400)\n[PASS] test_infiniteAllowanceIsNotReduced() (gas: 183389)\n[PASS] test_insufficientBalanceRevertsWithoutMovingTokens() (gas: 44819)\n[PASS] test_maximumUintTransferReverts() (gas: 37157)\n[PASS] test_metadataAndInitialSupply() (gas: 73811)\n[PASS] test_noMintBurnOrAdministrativeEntrypoints() (gas: 666923)\n[PASS] test_selfTransferPreservesBalance() (gas: 42707)\n[PASS] test_transferEmitsEventAndMovesExactAmount() (gas: 79862)\n[PASS] test_transferFromExceedingAllowanceRevertsAtomically() (gas: 99904)\n[PASS] test_transferFromInsufficientBalanceRestoresAllowance() (gas: 105651)\n[PASS] test_transferFromSpendsOnlyItsAllowanceAndEmitsTransfer() (gas: 195891)\n[PASS] test_transferFromToSelfSpendsAllowanceWithoutChangingBalance() (gas: 94682)\n[PASS] test_transferFromZeroOwnerCannotMint() (gas: 43332)\n[PASS] test_transferFromZeroReceiverRestoresAllowance() (gas: 95404)\n[PASS] test_transferToContractDoesNotCallRecipient() (gas: 166003)\n[PASS] test_transferToZeroRevertsIncludingZeroAmount() (gas: 65990)\n[PASS] test_zeroTransferFromEmptyAccountEmitsEvent() (gas: 50058)\n[PASS] test_zeroTransferFromWithoutAllowanceSucceeds() (gas: 50899)\nSuite result: ok. 31 passed; 0 failed; 0 skipped; finished in 19.12ms (94.52ms CPU time)\n\nRan 1 test for test/MADToken.invariant.t.sol:MADTokenInvariantTest\n[PASS]\nMADTokenInvariantTest invariants:\n[PASS] invariant_allowancesMatchModel\n[PASS] invariant_supplyAndBalancesMatchModel\n MADTokenInvariantTest invariants (runs: 256, calls: 16384, reverts: 0)\n\n╭------------+-----------------+-------+---------+----------╮\n| Contract   | Selector        | Calls | Reverts | Discards |\n+===========================================================+\n| MADHandler | approve         | 4140  | 0       | 0        |\n|------------+-----------------+-------+---------+----------|\n| MADHandler | transfer        | 4040  | 0       | 0        |\n|------------+-----------------+-------+---------+----------|\n| MADHandler | transferFrom    | 4074  | 0       | 0        |\n|------------+-----------------+-------+---------+----------|\n| MADHandler | transferTooMuch | 4130  | 0       | 0        |\n╰------------+-----------------+-------+---------+----------╯\n\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 4.21s (4.21s CPU time)\n\nRan 3 test suites in 4.21s (4.24s CPU time): 34 tests passed, 0 failed, 0 skipped (34 total tests)\n","passed":true},{"durationMs":40,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"MADToken.approve(address,uint256)\",\"MADToken.transfer(address,uint256)\",\"MADToken.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":3,\"README.md\":109,\"foundry.toml\":22,\"launch.json\":24,\"src/MADToken.sol\":17,\"test/LaunchFlow.t.sol\":84,\"test/MADToken.invariant.t.sol\":123,\"test/MADToken.t.sol\":391,\"test/helpers/TestBase.sol\":49},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"5c6de5dd90391fb22a195db8cce1503255867912be46dc8ddcb5fac13f7b80f9","verifiedTreeHash":"17e18a32d9507ec7a5c6e7ae6772b87b050e4b6e","verifierVersion":"0.1.0+ead9012e"},{"checks":[{"durationMs":919,"exitCode":0,"name":"build","output":"Compiling 12 files with Solc 0.8.26\nSolc 0.8.26 finished in 841.89ms\nCompiler run successful!\n","passed":true},{"durationMs":15193,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 31 tests for test/MADToken.t.sol:MADTokenTest\n[PASS] testFuzz_arbitraryRecipient(address,uint256) (runs: 512, μ: 74578, ~: 75509)\n[PASS] testFuzz_transferAboveAllowanceAlwaysReverts(uint256) (runs: 512, μ: 99963, ~: 100329)\n[PASS] testFuzz_transferAboveBalanceAlwaysReverts(uint256,uint256) (runs: 512, μ: 104512, ~: 104901)\n[PASS] testFuzz_transferConservesSupply(uint256) (runs: 512, μ: 74851, ~: 75146)\n[PASS] testFuzz_transferFromConservesSupplyAndAllowance(uint256,uint256) (runs: 512, μ: 137420, ~: 138873)\n[PASS] test_approvalDoesNotRequireBalance() (gas: 65700)\n[PASS] test_approveEmitsEventWithoutMovingBalance() (gas: 75094)\n[PASS] test_approveReplacesAndRevokesAllowance() (gas: 155721)\n[PASS] test_approveZeroSpenderReverts() (gas: 34685)\n[PASS] test_constructorEmitsExactlyOneMint() (gas: 6951)\n[PASS] test_deployerCannotSpendHolderTokensWithoutApproval() (gas: 146881)\n[PASS] test_directEtherPaymentIsRejected() (gas: 38924)\n[PASS] test_entireSupplyCanMoveAndMoveBack() (gas: 120606)\n[PASS] test_exactAllowanceCanBeExhausted() (gas: 148400)\n[PASS] test_infiniteAllowanceIsNotReduced() (gas: 183389)\n[PASS] test_insufficientBalanceRevertsWithoutMovingTokens() (gas: 44819)\n[PASS] test_maximumUintTransferReverts() (gas: 37157)\n[PASS] test_metadataAndInitialSupply() (gas: 73811)\n[PASS] test_noMintBurnOrAdministrativeEntrypoints() (gas: 666923)\n[PASS] test_selfTransferPreservesBalance() (gas: 42707)\n[PASS] test_transferEmitsEventAndMovesExactAmount() (gas: 79862)\n[PASS] test_transferFromExceedingAllowanceRevertsAtomically() (gas: 99904)\n[PASS] test_transferFromInsufficientBalanceRestoresAllowance() (gas: 105651)\n[PASS] test_transferFromSpendsOnlyItsAllowanceAndEmitsTransfer() (gas: 195891)\n[PASS] test_transferFromToSelfSpendsAllowanceWithoutChangingBalance() (gas: 94682)\n[PASS] test_transferFromZeroOwnerCannotMint() (gas: 43332)\n[PASS] test_transferFromZeroReceiverRestoresAllowance() (gas: 95404)\n[PASS] test_transferToContractDoesNotCallRecipient() (gas: 166003)\n[PASS] test_transferToZeroRevertsIncludingZeroAmount() (gas: 65990)\n[PASS] test_zeroTransferFromEmptyAccountEmitsEvent() (gas: 50058)\n[PASS] test_zeroTransferFromWithoutAllowanceSucceeds() (gas: 50899)\nSuite result: ok. 31 passed; 0 failed; 0 skipped; finished in 42.07ms (186.51ms CPU time)\n\nRan 22 tests for test/MADToken.adversarial.t.sol:MADTokenAdversarialTest\n[PASS] testFuzz_approveIsIdempotentAndLastWriteWins(uint256,uint256) (runs: 1000, μ: 133217, ~: 133278)\n[PASS] testFuzz_arbitraryCalldataFromStrangerMovesNothing(bytes,address) (runs: 1000, μ: 162999, ~: 162787)\n[PASS] testFuzz_roundTripRestoresBalances(uint256,address) (runs: 1000, μ: 101190, ~: 101495)\n[PASS] testFuzz_splitTransfersEqualOneTransfer(uint256,uint256) (runs: 1000, μ: 103276, ~: 103448)\n[PASS] testFuzz_transferFromOutcomeMatchesModel(address,address,address,uint256,uint256,uint256) (runs: 1000, μ: 177287, ~: 168997)\n[PASS] test_allowanceIsDirectional() (gas: 171782)\n[PASS] test_approveZeroOwnerIsImpossibleFromZeroAddressCaller() (gas: 33618)\n[PASS] test_contractHoldersBehaveAsEoas() (gas: 732978)\n[PASS] test_deployerHasNoRightsAfterDistributing() (gas: 111415)\n[PASS] test_maxAllowanceStillLimitedByBalance() (gas: 147188)\n[PASS] test_maxMinusOneAllowanceIsFiniteAndDecreases() (gas: 116292)\n[PASS] test_noFallbackAndNoNoncesOrPermit() (gas: 207543)\n[PASS] test_oneWeiOverBalanceReverts() (gas: 37107)\n[PASS] test_oneWeiTransferAndBack() (gas: 108083)\n[PASS] test_ownerNeedsAllowanceForOwnTransferFrom() (gas: 145414)\n[PASS] test_runtimeHasNoDelegatecallCallcodeOrSelfdestruct() (gas: 461741)\n[PASS] test_runtimeMakesNoExternalCalls() (gas: 497430)\n[PASS] test_sameTransferFromTwiceCannotReuseAllowance() (gas: 138068)\n[PASS] test_sameTransferTwiceCannotOverdraw() (gas: 136696)\n[PASS] test_supplyIsExactlyTenToTheTwentySeven() (gas: 25807)\n[PASS] test_tokensSentToTheTokenItselfAreStuckButCounted() (gas: 104599)\n[PASS] test_transferFromEmitsTransferButNoApproval() (gas: 118441)\nSuite result: ok. 22 passed; 0 failed; 0 skipped; finished in 42.33ms (215.30ms CPU time)\n\nRan 2 tests for test/LaunchFlow.t.sol:LaunchFlowTest\n[PASS] testFuzz_constructorMintsToImmediateDeployer(address) (runs: 512, μ: 11453, ~: 11905)\n[PASS] test_factoryGetsEntireSupplyAndLaunchTransfersArriveWhole() (gas: 678620)\nSuite result: ok. 2 passed; 0 failed; 0 skipped; finished in 42.35ms (42.72ms CPU time)\n\nRan 1 test for test/MADToken.invariant.t.sol:MADTokenInvariantTest\n[PASS]\nMADTokenInvariantTest invariants:\n[PASS] invariant_allowancesMatchModel\n[PASS] invariant_supplyAndBalancesMatchModel\n MADTokenInvariantTest invariants (runs: 256, calls: 16384, reverts: 0)\n\n╭------------+-----------------+-------+---------+----------╮\n| Contract   | Selector        | Calls | Reverts | Discards |\n+===========================================================+\n| MADHandler | approve         | 4140  | 0       | 0        |\n|------------+-----------------+-------+---------+----------|\n| MADHandler | transfer        | 4040  | 0       | 0        |\n|------------+-----------------+-------+---------+----------|\n| MADHandler | transferFrom    | 4074  | 0       | 0        |\n|------------+-----------------+-------+---------+----------|\n| MADHandler | transferTooMuch | 4130  | 0       | 0        |\n╰------------+-----------------+-------+---------+----------╯\n\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 4.64s (4.64s CPU time)\n\nRan 2 tests for test/MADToken.hostile.invariant.t.sol:MADTokenHostileInvariantTest\n[PASS]\nMADTokenHostileInvariantTest invariants:\n[PASS] invariant_allowancesMatchModelIncludingZeroSpender\n[PASS] invariant_everyCallOutcomeMatchesTheModel\n[PASS] invariant_fixedSupplyFullyHeldByActors\n[PASS] invariant_metadataNeverChanges\n[PASS] invariant_nobodyLeavesWithMoreThanTheyReceived\n MADTokenHostileInvariantTest invariants (runs: 256, calls: 25600, reverts: 0)\n\n╭-------------------+---------------+-------+---------+----------╮\n| Contract          | Selector      | Calls | Reverts | Discards |\n+================================================================+\n| HostileMADHandler | approve       | 6431  | 0       | 0        |\n|-------------------+---------------+-------+---------+----------|\n| HostileMADHandler | arbitraryCall | 6346  | 0       | 0        |\n|-------------------+---------------+-------+---------+----------|\n| HostileMADHandler | transfer      | 6431  | 0       | 0        |\n|-------------------+---------------+-------+---------+----------|\n| HostileMADHandler | transferFrom  | 6392  | 0       | 0        |\n╰-------------------+---------------+-------+---------+----------╯\n\n[PASS] test_handlerExercisesBothSuccessAndRefusal() (gas: 9640781)\nSuite result: ok. 2 passed; 0 failed; 0 skipped; finished in 15.13s (15.13s CPU time)\n\nRan 5 test suites in 15.13s (19.89s CPU time): 58 tests passed, 0 failed, 0 skipped (58 total tests)\n","passed":true},{"durationMs":42,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"MADToken.approve(address,uint256)\",\"MADToken.transfer(address,uint256)\",\"MADToken.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":3,\"README.md\":109,\"foundry.toml\":22,\"src/MADToken.sol\":17,\"test/LaunchFlow.t.sol\":84,\"test/MADToken.adversarial.t.sol\":377,\"test/MADToken.hostile.invariant.t.sol\":223,\"test/MADToken.invariant.t.sol\":123,\"test/MADToken.t.sol\":391,\"test/helpers/TestBase.sol\":49},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"eff10aa2f030cb7f6a48f3d1e95b5e1c44d4fa2ca2ab5f9a81da187a5770dabe","verifiedTreeHash":"9f0a558c758e4fc3e77246e48efb3ad2df43dac8","verifierVersion":"0.1.0+ead9012e"}]}