{"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":"8f6122c6-6ea8-423e-96bb-0d1f7a631611","kind":"shape:chain","nodes":[{"acceptedSubmissionHash":"997ddf8dd27e046ecabe3204f93ee39874f19118cc98ec00068933de044e661e","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":"2973e188cdeb45467646fc69d8b3702e9df67607a84560a0384a85e7783cb991","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":"38af2a43426cb4204e08b880b4509abfdd655d93338e23d6037e7989936d8599","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":"57bc6f95eff488175b6bc55e7c8ca581293f60e9c290425308e1c0d3267dd7cd","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":"b11a5798d64b0b63078e56f7a8283d0acbe9d12d410d193959b03e5f5acd7acd","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":"c55a570afc0cd9180f419c75939508f1c40e2007d6203d0e2e366db27d2a37d2","dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"816fe39c7efd64504a19175b0f4dd9186d61069f37a22684c90358a18c60bddc","skillId":"build-contract-project","tools":[]},"key":"build_contract_project","kind":"code","role":"implement","skillHash":"816fe39c7efd64504a19175b0f4dd9186d61069f37a22684c90358a18c60bddc","skillId":"build-contract-project","state":"accepted"},{"acceptedSubmissionHash":"76b9db909fe45c3c1fbe50ecc8bba5b6ee1ad5f665d3c1cc4295d8148d831390","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"tools":[]},"key":"manifest","kind":"code","role":"integrate","skillHash":null,"skillId":null,"state":"accepted"},{"acceptedSubmissionHash":"5ff58c5194882c79a933225f4207e717c58aec051cf969d0d06761fc54222126","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"ab3f8f2aa4e7f3b3ada558c0dcf522ba733ca3df3b1da92c707a0fe305816d5f","skillId":"write-foundry-tests","tools":[]},"key":"write_foundry_tests","kind":"code","role":"tests","skillHash":"ab3f8f2aa4e7f3b3ada558c0dcf522ba733ca3df3b1da92c707a0fe305816d5f","skillId":"write-foundry-tests","state":"accepted"}],"objective":"A custom token: IMDwindowshopper (WWW).\nToken name: IMDwindowshopper\nToken symbol: WWW\nToken supply: 1,000,000,000 with 18 decimals, all minted once to the deployer in the constructor.","parentJobId":null,"planHash":"f3a54a9ca85bc168a1c7202d60fd1233381e6f6c91873bc782d5eb35d57e4fea","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"8f6122c6-6ea8-423e-96bb-0d1f7a631611","publication":{"commit":null,"deliveredAt":null,"repoUrl":"https://github.com/identity-md-launches/launch-2543-imdwindowshopper"},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[],"schema":"identitymd-work-v1","signals":[{"agentId":"50985","feedbackHash":"153051f89e2392d231a4caa928bd4bf1981187b1418e7761389e13d5f8401018","nodeKey":"audit_economics","submissionHash":"997ddf8dd27e046ecabe3204f93ee39874f19118cc98ec00068933de044e661e","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51435","feedbackHash":"7be5f016f35a57d8c5ac617aa000138ac0a849e522abc41e0957e50e07b6e987","nodeKey":"audit_flow","submissionHash":"2973e188cdeb45467646fc69d8b3702e9df67607a84560a0384a85e7783cb991","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52609","feedbackHash":"a46507dd6f80d70b9f2c0f22d534b1d306f25094cacbcbb9236059eb319cdf32","nodeKey":"audit_judge","submissionHash":"38af2a43426cb4204e08b880b4509abfdd655d93338e23d6037e7989936d8599","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51189","feedbackHash":"bf90b8c7847c1859dca334068121afb56a6b64752e51f5dd57c849a2b5e3dfec","nodeKey":"audit_math","submissionHash":"57bc6f95eff488175b6bc55e7c8ca581293f60e9c290425308e1c0d3267dd7cd","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"50959","feedbackHash":"afb388ba2354fa5fdeeb533e328d717a7f9291273af232766a549bd5aed7754c","nodeKey":"audit_permissions","submissionHash":"b11a5798d64b0b63078e56f7a8283d0acbe9d12d410d193959b03e5f5acd7acd","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51226","feedbackHash":"b5476dc0afec1750d10bb3d98482b6c823d581a1b74a682947809e3123c93a9e","nodeKey":"build_contract_project","submissionHash":"c55a570afc0cd9180f419c75939508f1c40e2007d6203d0e2e366db27d2a37d2","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"52073","feedbackHash":"04fe807d1585f7fc79aae1f90af18f808ef69eb56e79089858d1b52c8eda6879","nodeKey":"manifest","submissionHash":"76b9db909fe45c3c1fbe50ecc8bba5b6ee1ad5f665d3c1cc4295d8148d831390","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"51274","feedbackHash":"86daa732d557f4c7f43214d9caf2c32691d609226e439841c64308dcc1ac0bbd","nodeKey":"write_foundry_tests","submissionHash":"5ff58c5194882c79a933225f4207e717c58aec051cf969d0d06761fc54222126","tag1":"verification:checks","tag2":"acceptance-v2","value":1}],"site":null,"snapshotHash":"1ca819f70639acae8885b918ea6fccdb150ddeb890c785e61af8a1b8b3fb1c8e","state":"completed","submissions":[{"artifacts":[],"attempt":1,"bundleHash":null,"device":"5fdca4f96f37a80d","findings":[{"citation":"resolved","description":"Periphery guide: the token inherits all of its behaviour from the vendored base contract, so the base contract's provenance is the only guarantee a reviewer has that transfer/approve/transferFrom are the audited OpenZeppelin 5.0.2 code. The vendored README (line 8) says 'The Solidity files are unmodified upstream copies' and lists upstream SHA-256 checksums (lines 15 and 19). Two of the five shipped files do not hash to the stated values: contracts/token/ERC20/ERC20.sol hashes to 4a1db79b7b76a41b1d228242ad369c24fb293be6a62cd00b7e286333e965df59 (README says 2d874da1...) and contracts/interfaces/draft-IERC6093.sol hashes to 94e5638bf0e43993e72ed07612547554e9265b335ab69ad8e74b8d41d90368bd (README says 4aea8724...). I downloaded the v5.0.2 tag files and diffed: the only differences are whitespace re-wraps of one long line in each file (the `_approve(address,address,uint256,bool)` signature in ERC20.sol and the `ERC1155InsufficientBalance` error in draft-IERC6093.sol), evidently from running `forge fmt` on lib/ before `[fmt] ignore = [\"lib/**\"]` was added to foundry.toml. Behaviour is unchanged, so this is not a token defect; it is a false provenance statement. Anyone verifying the vendored base by the documented hashes gets a mismatch and cannot tell a benign reformat from a tampered base without repeating the upstream diff. Fix: either restore the byte-exact upstream files (so the listed hashes hold) or replace the listed hashes with the shipped files' hashes and drop the word 'unmodified'. IERC20.sol, IERC20Metadata.sol, Context.sol and LICENSE match the stated checksums.","line":15,"path":"lib/openzeppelin-contracts/README.md","reproduction":"At the repository root run: sha256sum lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol lib/openzeppelin-contracts/contracts/interfaces/draft-IERC6093.sol. Expected (per lib/openzeppelin-contracts/README.md lines 15 and 19): 2d874da1c1478ed22a2d30dcf1a6ec0d09a13f897ca680d55fb49fbcc0e0c5b1 and 4aea87243e6de38804bf8737bf86f750443d3b5e63dd0fd0b7ad92f77cdbd3e3. Actual: 4a1db79b7b76a41b1d228242ad369c24fb293be6a62cd00b7e286333e965df59 and 94e5638bf0e43993e72ed07612547554e9265b335ab69ad8e74b8d41d90368bd. Then: curl -sSL https://raw.githubusercontent.com/OpenZeppelin/openzeppelin-contracts/v5.0.2/contracts/token/ERC20/ERC20.sol | diff - lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol shows a 4-line whitespace-only difference at upstream line 284; the same for draft-IERC6093.sol at upstream line 121. The upstream download does hash to the README's values, so the README quotes upstream and the shipped files were reformatted after.","severity":"low","snippet":"2d874da1c1478ed22a2d30dcf1a6ec0d09a13f897ca680d55fb49fbcc0e0c5b1  contracts/token/ERC20/ERC20.sol","title":"Vendored OpenZeppelin README states upstream checksums that do not match the shipped ERC20.sol and draft-IERC6093.sol"}],"hash":"2973e188cdeb45467646fc69d8b3702e9df67607a84560a0384a85e7783cb991","nodeId":"f8f3d071-1599-45fc-b811-cba0fb89c3f7","outcome":"completed","summary":"The review is complete. The findings file is written and the scratch test directory is removed, leaving the tree unchanged apart from the ignored `.imd-findings.json`.\n\n**Outcome.** The token is a plain OpenZeppelin 5.0.2 ERC-20 that mints exactly 1e27 units to the deployer once, with no other entry points. Tracing all three state-changing functions through the Execution Trace, Periphery and First Principles guides found no defect in the token's control flow. One low-severity provenance defect was found in the vendored library's documentation.\n\n**What I verified**\n- `approve`, `transfer` and `transferFrom` inherit the standard OZ paths. Zero-address sender, recipient and spender revert, insufficient balance or allowance reverts, the unlimited allowance is never decremented, and a failed step rolls back the whole call. Each is marked `holds` in the coverage record.\n- The compiled ABI exposes only the ERC-20 methods plus the supply constant. There is no receive or fallback, so ETH and unknown selectors revert. The runtime has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, checked with a scratch replica of the protected opcode scan.\n- The project's 33 tests pass with the README's fuzz seed, and `forge fmt --check` is clean.\n- The aderyn large-numeric-literal lead is not a defect. The constant evaluates to exactly 1e27 at compile time and the tests assert it independently.\n\n**The one finding (low).** The vendored OpenZeppelin README claims the Solidity files are unmodified upstream copies and lists upstream SHA-256 checksums. Two shipped files, `ERC20.sol` and `draft-IERC6093.sol`, do not match those hashes. I downloaded the v5.0.2 tag files and diffed them. The only differences are whitespace re-wraps of one long line in each file, so behaviour is identical, but anyone checking provenance by the documented hashes gets a mismatch. The fix is to restore the byte-exact upstream files or correct the listed hashes.\n\n**Not reached.** The protected launch-flow harness needs v4-core and the floor's `LaunchLiquidity` contract, which are not in this tree, so I could not execute it. By inspection a fee-free, hook-free ERC-20 satisfies every assertion in it. This is recorded as `unreached` in the coverage.","treeHash":null,"usage":{"cachedInputTokens":567743,"inputTokens":258,"model":"claude-fable-5-1","outputTokens":11993,"runtime":"claude","turns":24,"wallClockMs":218606}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"8e25456c4ae69acf","findings":[{"citation":"resolved","description":"Merged from audit_economics, audit_math, audit_permissions and audit_flow, which all report the same root cause. The vendored-library README says the Solidity files are unmodified upstream OpenZeppelin v5.0.2 copies and lists their upstream SHA-256 checksums (lines 15 and 19). Two committed files were reformatted to the project's 100-column fmt width after they were vendored: lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol line 284 (`function _approve(address owner, address spender, uint256 value, bool emitEvent)`, one line upstream, now split over lines 284-287) and lib/openzeppelin-contracts/contracts/interfaces/draft-IERC6093.sol line 121 (`error ERC1155InsufficientBalance(`, one line upstream, now split over lines 121-123). So the checksums the README publishes do not hold for the tree. I removed all whitespace from both files and compared them with upstream: they are identical, so the compiled token's behaviour is unchanged. There is no on-chain impact. The defect is a false provenance statement: anyone who checks the vendored base, which supplies all of the token's transfer, approve and transferFrom logic, against the published hashes gets a mismatch and cannot tell a harmless reformat from a tampered base without redoing the upstream diff. Fix: restore the two files byte-for-byte from upstream v5.0.2 (foundry.toml's `[fmt] ignore = [\"lib/**\"]` already keeps them that way), or list the actual checksums and drop the word 'unmodified'.","line":8,"path":"lib/openzeppelin-contracts/README.md","reproduction":"At the repository root run: sha256sum lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol lib/openzeppelin-contracts/contracts/interfaces/draft-IERC6093.sol. Expected per README lines 15 and 19: 2d874da1c1478ed22a2d30dcf1a6ec0d09a13f897ca680d55fb49fbcc0e0c5b1 and 4aea87243e6de38804bf8737bf86f750443d3b5e63dd0fd0b7ad92f77cdbd3e3. Actual: 4a1db79b7b76a41b1d228242ad369c24fb293be6a62cd00b7e286333e965df59 and 94e5638bf0e43993e72ed07612547554e9265b335ab69ad8e74b8d41d90368bd. The files at https://raw.githubusercontent.com/OpenZeppelin/openzeppelin-contracts/v5.0.2/ (contracts/token/ERC20/ERC20.sol and contracts/interfaces/draft-IERC6093.sol) hash to exactly the README's values. A plain `diff` against them shows only `284c284,287` (the _approve signature re-wrap) and `121c121,123` (the ERC1155InsufficientBalance re-wrap). With all whitespace removed (tr -d ' \\n\\t'), both files are identical to upstream. LICENSE, IERC20.sol, IERC20Metadata.sol and Context.sol match the listed checksums.","severity":"low","snippet":"the upstream `LICENSE`. The Solidity files are unmodified upstream copies. They are","title":"Vendored OpenZeppelin README says the files are unmodified upstream copies, but ERC20.sol and draft-IERC6093.sol do not match its listed checksums (whitespace re-wrap)"}],"hash":"38af2a43426cb4204e08b880b4509abfdd655d93338e23d6037e7989936d8599","nodeId":"911c6a99-72bc-4600-aaca-5d212e910b10","outcome":"completed","summary":"I kept one low-severity finding and the token itself checks out clean. The findings and coverage record are in `.imd-findings.json`, and no tracked file in the repo was changed.\n\n**Kept, low: the vendored library's provenance note is wrong** (`lib/openzeppelin-contracts/README.md:8`)\n- **Merged:** four specialists (economics, math, permissions, flow) reported this same issue, so it is one finding.\n- **The claim:** the README says the OpenZeppelin files are \"unmodified upstream copies\" and lists their checksums.\n- **The mismatch:** two files have different checksums from the listed ones: `ERC20.sol` (4a1db79b…, README says 2d874da1…) and `draft-IERC6093.sol` (94e5638b…, README says 4aea8724…).\n- **Cause:** I downloaded the v5.0.2 files from GitHub; they hash to exactly the README's values. A diff shows the only change is one long line re-wrapped in each file: `ERC20.sol` line 284 and `draft-IERC6093.sol` line 121. With whitespace removed, both files are identical to upstream.\n- **Impact:** the token behaves exactly as upstream, so there is no on-chain effect. But anyone checking the library against the published checksums gets a mismatch and can't tell a harmless reformat from a tampered base without redoing the diff.\n- **Fix:** restore the two files byte-for-byte from upstream, or list the actual checksums and drop the word \"unmodified\".\n\n**Dropped, the allowance race (economics, info):** I dropped this one. It reproduces, but it is standard ERC-20 `approve` behaviour inherited unchanged from OpenZeppelin, and the brief asks for a standard token, so it isn't a defect in this code.\n\n**My own pass found nothing new:**\n- **The token:** `src/IMDwindowshopper.sol` is a plain OpenZeppelin ERC-20. It mints the full supply once, in the constructor, to the deployer. It has no owner, no mint after launch, and no fee, burn or hook on transfer, so the launch's transfers move exact amounts.\n- **The manifest:** `launch.json` matches the code: no constructor arguments, 18 decimals, total supply `1000000000000000000000000000`, and the right name and symbol.\n- **Deployability:** the contract is 1,752 bytes deployed and 2,644 bytes of creation code, far under the 24,576 and 49,152 limits.\n- **Static analysis:** slither reported nothing. The aderyn note about a large number literal is only `1_000_000_000 * 10 ** 18`, which is correct.\n- **Tests:** all 50 of the project's Foundry tests pass.\n\n**Coverage:** `approve`, `transfer` and `transferFrom` are all marked `holds`, and I added two invariant rows: the fixed supply, and the match between the manifest, the constructor and deployability.\n\nNo finding is critical or high, so none needed a test proof.","treeHash":null,"usage":{"cachedInputTokens":224988,"inputTokens":12,"model":"claude-opus-5-5","outputTokens":4981,"runtime":"claude","turns":6,"wallClockMs":79322}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"ee8bab8367ea6e91","findings":[{"citation":"resolved","description":"The vendored library README (line 8) states 'The Solidity files are unmodified upstream copies' and publishes upstream SHA-256 checksums (lines 13-20) for a verifier to check. Two of the five Solidity files in the tree were reformatted (line wrapping at 100 columns, consistent with `forge fmt`): contracts/token/ERC20/ERC20.sol (the `_approve(owner, spender, value, bool emitEvent)` signature at line 284 is split across four lines) and contracts/interfaces/draft-IERC6093.sol (the `ERC1155InsufficientBalance` error at line 121 is split across three lines). Their SHA-256 sums therefore differ from the README's values, so anyone following the README's provenance procedure gets a mismatch. I confirmed the differences are whitespace-only: after stripping all whitespace, every vendored file hashes identically to the file fetched from github.com/OpenZeppelin/openzeppelin-contracts at tag v5.0.2, and the compiled behavior is unchanged (all 33 project tests and 11 scratch boundary tests pass). This is outside the assigned math area and has no on-chain impact; it is a provenance-documentation defect only. Fix: either restore the byte-exact upstream files (and exclude lib/ from `forge fmt`, which foundry.toml's `[fmt] ignore = [\"lib/**\"]` already intends) or recompute the checksums and drop the word 'unmodified'.","line":15,"path":"lib/openzeppelin-contracts/README.md","reproduction":"Run at the repository root: `sha256sum lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol lib/openzeppelin-contracts/contracts/interfaces/draft-IERC6093.sol`. Expected (per README lines 15 and 19): 2d874da1c1478ed22a2d30dcf1a6ec0d09a13f897ca680d55fb49fbcc0e0c5b1 and 4aea87243e6de38804bf8737bf86f750443d3b5e63dd0fd0b7ad92f77cdbd3e3. Actual: 4a1db79b7b76a41b1d228242ad369c24fb293be6a62cd00b7e286333e965df59 and 94e5638bf0e43993e72ed07612547554e9265b335ab69ad8e74b8d41d90368bd. The other three Solidity files (IERC20.sol, IERC20Metadata.sol, Context.sol) and LICENSE match the README. `diff <(curl -sL https://raw.githubusercontent.com/OpenZeppelin/openzeppelin-contracts/v5.0.2/contracts/token/ERC20/ERC20.sol) lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol` shows only the line-wrapping change at line 284.","severity":"info","snippet":"2d874da1c1478ed22a2d30dcf1a6ec0d09a13f897ca680d55fb49fbcc0e0c5b1  contracts/token/ERC20/ERC20.sol","title":"Vendored OpenZeppelin README claims unmodified files and lists checksums that two reformatted files do not match"}],"hash":"57bc6f95eff488175b6bc55e7c8ca581293f60e9c290425308e1c0d3267dd7cd","nodeId":"782052d5-7335-4fc8-968a-a5177bb3be50","outcome":"completed","summary":"The review is complete and the findings file is written. No math defects were found in the token.\n\n**Scope covered:** the Math Precision, Boundary and Numerical Gap guides applied to `src/IMDwindowshopper.sol` and the inherited OpenZeppelin 5.0.2 ERC20 paths it executes, plus a check that the vendored library is really upstream.\n\n**What holds**\n- The supply constant is compile-time exact at 10^27 and is minted once with a checked add. The aderyn large-literal lead is benign.\n- Every unchecked block in `_update` and `_spendAllowance` is guarded by a strict less-than check on the same values first. Max-uint, exact-balance, balance plus one, allowance of max and max minus one, self-transfers and delegated self-transfers all behave correctly. A 2000-run fuzz over balance, amount and allowance triples found no wrap and exact pass/fail boundaries.\n- Sum of balances equals total supply on every path, and the launch splits of 10, 70 and 20 percent divide 10^27 with no remainder.\n- The token has no external calls, no payable or fallback entry, no bytes decoding, and the only sentinel branch is the zero address, which reverts everywhere. The compiled runtime passes the protected floor's forbidden-opcode scan.\n- All 33 project tests pass with the pinned fuzz seed.\n\n**One info finding, outside the math area**\nThe vendored library README says its Solidity files are unmodified upstream copies and lists SHA-256 checksums, but `ERC20.sol` and `draft-IERC6093.sol` were reformatted with line wrapping, so their hashes no longer match. I confirmed against the upstream v5.0.2 files that the difference is whitespace only, with no behavioral effect. The fix is to restore the byte-exact files or update the README.\n\n**Output:** `.imd-findings.json` holds 1 finding and 9 coverage rows, one per listed entry point plus the constructor, invariants, boundary surface, library integrity and opcode floor. Scratch tests were removed, so the working tree is otherwise unchanged.","treeHash":null,"usage":{"cachedInputTokens":681677,"inputTokens":258,"model":"claude-fable-5-1","outputTokens":15852,"runtime":"claude","turns":24,"wallClockMs":224935}},{"artifacts":[],"attempt":1,"bundleHash":"72393a79b08c0cc7911908b2b7c8a6fd9b62409de9f0d144e3af645a5d76fff2","device":"34d50a3af6e87087","findings":[],"hash":"5ff58c5194882c79a933225f4207e717c58aec051cf969d0d06761fc54222126","nodeId":"10bc41a9-6dbd-46da-bc3e-4f7258ec196f","outcome":"completed","summary":"Added failure-path and edge-case tests, six fuzz properties, and four-actor stateful invariants under `test/`.\n\nOffline `forge build` and `forge test` pass with the required seed: 50 tests passed, including 32,768 invariant calls.\n\nNo implementation defects found. Existing files remain unchanged.","treeHash":"3c0b26a83ea4dc48d6c6cc2412943bf7f66d6f41","usage":{"cachedInputTokens":745088,"inputTokens":54425,"model":"gpt-6-astra","outputTokens":13477,"runtime":"codex","turns":5,"wallClockMs":460898}},{"artifacts":[],"attempt":1,"bundleHash":"08b6ebb7b95d29e53da1c21170be3e8dafcb7f6d23b90054e689c301401f7dd3","device":"381cad4126e6ec64","findings":[],"hash":"76b9db909fe45c3c1fbe50ecc8bba5b6ee1ad5f665d3c1cc4295d8148d831390","nodeId":"a8b36ab7-13c4-45cf-a5a7-433993304808","outcome":"completed","summary":"Created `launch.json` matching the accepted token, constructor, exact supply, pool settings, and economics.\n\n`forge build` succeeded. All 33 tests passed with the supplied fuzz seed. Only `launch.json` is changed for submission.","treeHash":"85a46850c3843992b087a2d43273cca85a21ca4f","usage":{"cachedInputTokens":192896,"inputTokens":24677,"model":"gpt-6-astra","outputTokens":2490,"runtime":"codex","turns":3,"wallClockMs":68953}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"410247426ec5a6df","findings":[{"citation":"resolved","description":"lib/openzeppelin-contracts/README.md states 'The Solidity files are unmodified upstream copies' and lists upstream SHA-256 checksums. Two of the five vendored files were reformatted after vendoring (line-wrapped to the project's 100-column fmt width): ERC20.sol at line 284 (the `_approve(owner, spender, value, emitEvent)` signature, one line upstream, four lines here) and draft-IERC6093.sol at line 121 (`ERC1155InsufficientBalance`, one line upstream, three lines here). I fetched the v5.0.2 files from github.com/OpenZeppelin/openzeppelin-contracts and confirmed the README's hashes are the genuine upstream hashes (ERC20.sol 2d874da1…, draft-IERC6093.sol 4aea8724…), while the files in the tree hash to 4a1db79b… and 94e5638b…. Stripping all whitespace, the files are identical to upstream, so the compiled runtime and the token's behaviour are unaffected. The defect is in provenance: anyone following the README's instruction to verify the vendored library against those checksums gets a mismatch, and a reviewer or verifier diffing the published sources against upstream v5.0.2 sees a modified library with a document asserting it is unmodified. Fix: either restore the two files to their byte-exact upstream content (forge fmt already ignores lib/** so they will stay that way), or correct the README to say the files were reformatted and list the checksums of the files actually in the tree.","line":284,"path":"lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol","reproduction":"In the repository root run:\n\n    sha256sum lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol lib/openzeppelin-contracts/contracts/interfaces/draft-IERC6093.sol\n\nActual: 4a1db79b7b76a41b1d228242ad369c24fb293be6a62cd00b7e286333e965df59 and 94e5638bf0e43993e72ed07612547554e9265b335ab69ad8e74b8d41d90368bd.\nExpected per lib/openzeppelin-contracts/README.md lines 15 and 19: 2d874da1c1478ed22a2d30dcf1a6ec0d09a13f897ca680d55fb49fbcc0e0c5b1 and 4aea87243e6de38804bf8737bf86f750443d3b5e63dd0fd0b7ad92f77cdbd3e3. The other three vendored files (IERC20.sol, IERC20Metadata.sol, Context.sol) and LICENSE match. `diff` against the upstream v5.0.2 file shows only the line-wrapping at ERC20.sol:284-287 and draft-IERC6093.sol:121-123.","severity":"low","snippet":"    function _approve(address owner, address spender, uint256 value, bool emitEvent)\n        internal\n        virtual\n    {","title":"Vendored OpenZeppelin files are not the byte-identical upstream copies the provenance README claims; its own checksums do not match the tree"},{"citation":"resolved","description":"This is the standard ERC-20 approve semantics inherited unchanged from OpenZeppelin 5.0.2 ERC20.approve, which overwrites the allowance. It is recorded here because it is the one economic path in this token where an unprivileged actor (an approved spender) can take more than the holder intended, and the Economic Security guide asks for every such path to be stated with numbers. OpenZeppelin 5 deliberately ships no increaseAllowance/decreaseAllowance, and the project README already advises holders to revoke to zero before granting a replacement. No code change is required for the brief's 'standard token'; the author may optionally expose ERC-2612 permit or document the mitigation more prominently. Not a blocking defect.","line":9,"path":"src/IMDwindowshopper.sol","reproduction":"Holder H holds 1000e18 WWW. 1) H calls approve(S, 100e18). 2) H later submits approve(S, 50e18) intending to reduce it. 3) S, seeing the pending transaction, front-runs with transferFrom(H, S, 100e18): succeeds, allowance becomes 0. 4) H's approve(S, 50e18) lands: allowance becomes 50e18. 5) S calls transferFrom(H, S, 50e18): succeeds. Actual: S holds 150e18 of H's tokens. Expected by H: at most 100e18 (and after step 2, at most 50e18). Verified in a scratch Foundry test: after the five calls balanceOf(S) == 150e18 and both transferFrom calls returned true.","severity":"info","snippet":"contract IMDwindowshopper is ERC20 {","title":"Inherent ERC-20 allowance race: a spender can consume both the old and the replacement allowance when approve is used to change a non-zero allowance"}],"hash":"997ddf8dd27e046ecabe3204f93ee39874f19118cc98ec00068933de044e661e","nodeId":"24d07c2e-d7cb-431f-9b7f-0a67fbadaea2","outcome":"completed","summary":"The review is complete. The findings file is written at the repository root, the scratch tests are removed, and no project file was changed.\n\n**Outcome:** the token's economics hold. IMDwindowshopper is an unmodified OpenZeppelin 5.0.2 ERC-20 with a single constructor mint of exactly 10^27 base units to msg.sender, no fee, burn, hook, owner, pause, mint or upgrade path. I found no defect in the assigned area and one low-severity provenance defect outside it.\n\n**What I checked, with tests run locally**\n\n- Launch flows move exactly what they say. A factory stand-in deployed the token, sent 10% to a distributor and on to a claimant, seeded 70% both by push transfer and by allowance pull, and sent the 20% remainder. Every balance was exact and the factory ended at zero.\n- Conservation held. A fuzz test ran 256 random 64-step sequences mixing transfer, approve and transferFrom among four accounts. The sum of balances stayed at 10^27 on every step.\n- The supply cannot change after construction. No public mint or burn exists, and the protected floor's admin-call probes have nothing to hit.\n- The aderyn large-literal lead is benign. The constant equals 10^27 under three independent spellings.\n- The existing suite of 33 tests passes with the README's fuzz seed, and the committed files pass the formatter check.\n\n**Findings written**\n\n1. **Low, provenance.** The vendored ERC20.sol and draft-IERC6093.sol were reformatted after vendoring, so they are not byte-identical to upstream v5.0.2 even though the library README says they are unmodified and lists the genuine upstream checksums. I fetched upstream and confirmed the content is identical once whitespace is stripped, so behaviour and bytecode are unaffected. The README's hashes simply do not match the tree.\n2. **Info.** The inherent ERC-20 allowance race, where a spender front-runs an allowance change and spends both the old and the new amount. This is standard behaviour the README already documents, and I recorded it with concrete numbers only because it is the one path where an unprivileged actor can take more than a holder intended.\n\n**Coverage record:** all three entry points are marked holds, plus nine invariant and flow rows. Nothing was left unreached.","treeHash":null,"usage":{"cachedInputTokens":996063,"inputTokens":482,"model":"claude-fable-5-1","outputTokens":18447,"runtime":"claude","turns":29,"wallClockMs":277375}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"468e82a89b9bfe18","findings":[{"citation":"resolved","description":"Trust-gap area (what a reviewer or the deployer is asked to trust about the dependency the whole token inherits its behaviour from). The vendored README claims every Solidity file is an unmodified upstream OpenZeppelin v5.0.2 copy and lists SHA-256 checksums for them. Two of the vendored files do not hash to the listed values: contracts/token/ERC20/ERC20.sol (listed 2d874da1..., actual 4a1db79b...) and contracts/interfaces/draft-IERC6093.sol (listed 4aea8724..., actual 94e5638b...). I fetched both files from github.com/OpenZeppelin/openzeppelin-contracts at tag v5.0.2 and diffed them: the only differences are line wrapping of the `_approve(address,address,uint256,bool)` signature (ERC20.sol line 284) and of the `ERC1155InsufficientBalance` error declaration (draft-IERC6093.sol line 121); the diff is whitespace-only and the compiled semantics are identical. So there is no code defect and no change in permission, transfer or allowance behaviour; the defect is that the provenance statement a reviewer would rely on to skip re-auditing the library is false as written, and anyone checking the checksums mechanically will conclude the library was modified. The other four files (IERC20.sol, IERC20Metadata.sol, Context.sol, LICENSE) match upstream byte for byte.","line":8,"path":"lib/openzeppelin-contracts/README.md","reproduction":"From the repository root run `sha256sum lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol lib/openzeppelin-contracts/contracts/interfaces/draft-IERC6093.sol`. Expected (per README lines 15 and 19): 2d874da1c1478ed22a2d30dcf1a6ec0d09a13f897ca680d55fb49fbcc0e0c5b1 and 4aea87243e6de38804bf8737bf86f750443d3b5e63dd0fd0b7ad92f77cdbd3e3. Actual: 4a1db79b7b76a41b1d228242ad369c24fb293be6a62cd00b7e286333e965df59 and 94e5638bf0e43993e72ed07612547554e9265b335ab69ad8e74b8d41d90368bd. `diff -w` against the upstream v5.0.2 files shows only the two re-wrapped declarations. Fix: either restore the byte-exact upstream files (which also makes `forge fmt --check` with `ignore = [\"lib/**\"]` irrelevant to them) or state in the README that the two files were re-wrapped and list the checksums of the files actually committed.","severity":"info","snippet":"the upstream `LICENSE`. The Solidity files are unmodified upstream copies. They are","title":"Vendored-library provenance note is inaccurate: two files do not match the 'unmodified upstream' checksums the README states"}],"hash":"b11a5798d64b0b63078e56f7a8283d0acbe9d12d410d193959b03e5f5acd7acd","nodeId":"184402bf-4fdc-4bdf-83f7-8c5f6881ad17","outcome":"completed","summary":"The review is complete and `.imd-findings.json` is written with one informational finding and six coverage rows. No source or test file was changed.\n\n**What the token is.** `src/IMDwindowshopper.sol` is a 16-line contract over OpenZeppelin 5.0.2 ERC20. The constructor takes no arguments and mints 10^27 units to the caller, which is the factory on launch. The compiled ABI exposes only `approve`, `transfer` and `transferFrom` as state changers plus the standard views. There is no owner, role, initializer, receive or fallback, and no payable function.\n\n**Access Control.** There is no permission model to break. The caller identity comes from msg.sender through an unmodified Context, with no tx.origin or meta-transaction path. The deployer holds no right over other holders, and the inherited mint and burn helpers are internal and reachable only from the constructor. A reachable-opcode scan of the runtime found no DELEGATECALL, CALLCODE or SELFDESTRUCT.\n\n**Trust Gap.** With no privileged actor and no economics beyond plain transfers, the only trusted component is the vendored library. I fetched the upstream v5.0.2 files and diffed them. Four files match byte for byte. The ERC20 implementation and the ERC-6093 error interface differ only by two re-wrapped declarations, so behaviour is identical. However the vendored README claims the files are unmodified and lists checksums that two files do not match. That is the one finding, filed as info with the exact hashes as reproduction.\n\n**Asymmetry.** The approve and transferFrom pair is symmetric: set versus decrement unless unlimited, with revert paths rolling back both allowance and balances. The transfer and transferFrom pair share one `_transfer` path. In `_update`, the burn branch is unreachable because `_transfer` rejects a zero recipient.\n\n**Checks run.** The suite's 33 tests pass under the default seed and under a second seed with 2000 fuzz runs. The build and format check pass. The aderyn large-literal lead resolves to exactly the brief's supply. Slither reported nothing and I found nothing it missed.\n\n**Coverage.** All three listed entry points hold, plus rows for the constructor, the hidden-entry-point invariant and the custom-token floor. Nothing was left unreached.","treeHash":null,"usage":{"cachedInputTokens":1084086,"inputTokens":354,"model":"claude-fable-5-1","outputTokens":12811,"runtime":"claude","turns":29,"wallClockMs":251290}},{"artifacts":[],"attempt":1,"bundleHash":"6c1066b3017cc6fc6f39be268b21780e9baaf9115711d913d5f844fc6d19132b","device":"720122d0ca9f60ca","findings":[],"hash":"c55a570afc0cd9180f419c75939508f1c40e2007d6203d0e2e366db27d2a37d2","nodeId":"45d08cc3-0ec1-47ad-8967-654f1ad204b4","outcome":"completed","summary":"Implemented IMDwindowshopper (WWW) with 18 decimals and 1,000,000,000 tokens minted once to the deployer.\n\nVendored dependencies and documented deployment assumptions and operational responsibilities.\n\nValidation passed with Solidity 0.8.26: `forge build`, all 33 tests using the supplied fuzz seed, and `forge fmt --check`.","treeHash":"ba8058331464504ca0a8f7ca758b71f0e1a935ee","usage":{"cachedInputTokens":1228672,"inputTokens":100044,"model":"gpt-6.1-sol","outputTokens":23603,"runtime":"codex","turns":7,"wallClockMs":581919}}],"verification":[{"checks":[{"durationMs":717,"exitCode":0,"name":"build","output":"Compiling 12 files with Solc 0.8.26\nSolc 0.8.26 finished in 666.16ms\nCompiler run successful!\n","passed":true},{"durationMs":9605,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 15 tests for test/IMDwindowshopper.properties.t.sol:IMDwindowshopperPropertiesTest\n[PASS] testFuzz_ApprovalReplacementIsIdempotentAndIsolated(uint256,uint256) (runs: 1000, μ: 261912, ~: 262591)\n[PASS] testFuzz_DelegatedSelfTransferSpendsOnlyAllowance(uint256,bool) (runs: 1000, μ: 110990, ~: 111638)\n[PASS] testFuzz_FailedBalanceCheckPreservesApprovalForLaterFunding(uint256,uint256) (runs: 1000, μ: 283584, ~: 283854)\n[PASS] testFuzz_FiniteAllowanceAboveSupplyIsConsumedExactly(uint256,uint256) (runs: 1000, μ: 139855, ~: 139794)\n[PASS] testFuzz_InvalidRecipientPreservesFiniteOrUnlimitedApproval(uint256,bool) (runs: 1000, μ: 189520, ~: 189822)\n[PASS] testFuzz_TransferRoundTripRestoresEveryBalance(uint256,uint256) (runs: 1000, μ: 185363, ~: 186775)\n[PASS] test_DelegatedSelfTransferCannotBypassBalanceCheck() (gas: 98783)\n[PASS] test_MaximumDelegatedAmountCannotSpendBeyondBalance() (gas: 110683)\n[PASS] test_MaximumMinusOneAllowanceRemainsFinite() (gas: 157103)\n[PASS] test_MaximumTransferAmountRevertsWithoutWrappingBalances() (gas: 52472)\n[PASS] test_OneBaseUnitCanMoveAndReturnThroughDelegatedTransfer() (gas: 196409)\n[PASS] test_SelfApprovalAllowsOwnerToUseTransferFrom() (gas: 157938)\n[PASS] test_TokenContractCanReceiveTransfersWithoutChangingSupply() (gas: 166302)\n[PASS] test_UnlimitedApprovalCanBeRevokedAfterUse() (gas: 180530)\n[PASS] test_ZeroApprovalToZeroSpenderStillReverts() (gas: 42419)\nSuite result: ok. 15 passed; 0 failed; 0 skipped; finished in 71.97ms (428.69ms CPU time)\n\nRan 33 tests for test/IMDwindowshopper.t.sol:IMDwindowshopperTest\n[PASS] testFuzz_SelfTransferCannotInflateBalance(uint256) (runs: 256, μ: 43097, ~: 43099)\n[PASS] testFuzz_TransferAboveBalanceReverts(uint256,uint256) (runs: 256, μ: 104800, ~: 105016)\n[PASS] testFuzz_TransferConservesSupply(address,uint256) (runs: 256, μ: 75471, ~: 75717)\n[PASS] testFuzz_TransferFromAboveAllowanceReverts(uint256,uint256) (runs: 256, μ: 107886, ~: 108095)\n[PASS] testFuzz_TransferFromConsumesFiniteAllowance(uint256,uint256) (runs: 256, μ: 137658, ~: 139241)\n[PASS] testFuzz_TransferSequenceConservesAllBalances(bytes32) (runs: 256, μ: 2672730, ~: 2676386)\n[PASS] test_ApprovalForAnotherSpenderDoesNotAuthorizeCaller() (gas: 92543)\n[PASS] test_ApproveEmitsEventWithoutMovingTokens() (gas: 82681)\n[PASS] test_ApproveOverwritesAndCanBeRevoked() (gas: 154866)\n[PASS] test_ApproveZeroSpenderReverts() (gas: 34745)\n[PASS] test_ConstructorEmitsOneMintTransfer() (gas: 7490)\n[PASS] test_DelegatedSelfTransferConsumesAllowanceWithoutChangingBalance() (gas: 106551)\n[PASS] test_DeployerCannotFreezeSeizeOrAdministerHolders() (gas: 280023)\n[PASS] test_DeployerCannotSpendHolderTokensWithoutApproval() (gas: 144120)\n[PASS] test_EntireSupplyBelongsToDeployer() (gas: 38824)\n[PASS] test_FactoryReceivesSupplyAndCanDistributeItExactly() (gas: 384687)\n[PASS] test_FailedTransferFromRollsBackAllowanceOnInsufficientBalance() (gas: 105701)\n[PASS] test_FailedTransferFromRollsBackAllowanceOnZeroRecipient() (gas: 95713)\n[PASS] test_MaximumAllowanceIsNotDecremented() (gas: 128134)\n[PASS] test_MetadataAndSupplyMatchRequest() (gas: 35852)\n[PASS] test_MintBurnInitializationAndUpgradeEntrypointsAreUnavailable() (gas: 383177)\n[PASS] test_SelfTransferAboveBalanceReverts() (gas: 37434)\n[PASS] test_TransferEntireBalance() (gas: 70267)\n[PASS] test_TransferFromCanSpendEntireAllowanceAndBalance() (gas: 155285)\n[PASS] test_TransferFromEmptyAccountReverts() (gas: 44797)\n[PASS] test_TransferFromRequiresAllowanceEvenWhenCallerIsHolder() (gas: 33374)\n[PASS] test_TransferFromSpendsAllowanceAndEmitsTransfer() (gas: 201052)\n[PASS] test_TransferFromZeroSenderRevertsEvenForZeroAmount() (gas: 33010)\n[PASS] test_TransferMovesExactAmountAndEmitsEvent() (gas: 80157)\n[PASS] test_TransferToZeroAddressReverts() (gas: 41854)\n[PASS] test_ZeroTransferFromEmptyAccountEmitsEvent() (gas: 57573)\n[PASS] test_ZeroTransferFromWithoutAllowanceIsAllowed() (gas: 68683)\n[PASS] test_ZeroTransferToZeroAddressAlsoReverts() (gas: 30404)\nSuite result: ok. 33 passed; 0 failed; 0 skipped; finished in 105.23ms (316.35ms CPU time)\n\nRan 2 tests for test/IMDwindowshopper.invariant.t.sol:IMDwindowshopperInvariantTest\n[PASS]\nIMDwindowshopperInvariantTest invariants:\n[PASS] invariant_AllowancesMatchApprovalsAndSuccessfulSpends\n[PASS] invariant_BalancesMatchAuthorizedMovements\n[PASS] invariant_FixedSupplyAndConservation\n[PASS] invariant_MetadataIsStable\n IMDwindowshopperInvariantTest invariants (runs: 256, calls: 32768, reverts: 0)\n\n╭-----------------------+---------------------+-------+---------+----------╮\n| Contract              | Selector            | Calls | Reverts | Discards |\n+==========================================================================+\n| TokenInvariantHandler | approve             | 4671  | 0       | 0        |\n|-----------------------+---------------------+-------+---------+----------|\n| TokenInvariantHandler | rejectOverBalance   | 4665  | 0       | 0        |\n|-----------------------+---------------------+-------+---------+----------|\n| TokenInvariantHandler | rejectZeroRecipient | 4697  | 0       | 0        |\n|-----------------------+---------------------+-------+---------+----------|\n| TokenInvariantHandler | rejectZeroSpender   | 4642  | 0       | 0        |\n|-----------------------+---------------------+-------+---------+----------|\n| TokenInvariantHandler | transfer            | 4609  | 0       | 0        |\n|-----------------------+---------------------+-------+---------+----------|\n| TokenInvariantHandler | transferFrom        | 4685  | 0       | 0        |\n|-----------------------+---------------------+-------+---------+----------|\n| TokenInvariantHandler | transferFromRaw     | 4799  | 0       | 0        |\n╰-----------------------+---------------------+-------+---------+----------╯\n\n[PASS] test_HandlerExercisesTransfersRevocationsAndFailures() (gas: 1705731)\nSuite result: ok. 2 passed; 0 failed; 0 skipped; finished in 9.54s (9.54s CPU time)\n\nRan 3 test suites in 9.54s (9.71s CPU time): 50 tests passed, 0 failed, 0 skipped (50 total tests)\n","passed":true},{"durationMs":29,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"IMDwindowshopper.approve(address,uint256)\",\"IMDwindowshopper.transfer(address,uint256)\",\"IMDwindowshopper.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":3,\"README.md\":94,\"foundry.toml\":18,\"src/IMDwindowshopper.sol\":16,\"test/IMDwindowshopper.invariant.t.sol\":126,\"test/IMDwindowshopper.properties.t.sol\":330,\"test/IMDwindowshopper.t.sol\":445,\"test/helpers/TokenInvariantHandler.sol\":184,\"test/helpers/TokenPropertyBase.sol\":20,\"test/helpers/TokenTestBase.sol\":44},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"5ff58c5194882c79a933225f4207e717c58aec051cf969d0d06761fc54222126","verifiedTreeHash":"3c0b26a83ea4dc48d6c6cc2412943bf7f66d6f41","verifierVersion":"0.1.0+ad64f8c4"},{"checks":[{"durationMs":425,"exitCode":0,"name":"build","output":"Compiling 8 files with Solc 0.8.26\nSolc 0.8.26 finished in 371.65ms\nCompiler run successful!\n","passed":true},{"durationMs":169,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 33 tests for test/IMDwindowshopper.t.sol:IMDwindowshopperTest\n[PASS] testFuzz_SelfTransferCannotInflateBalance(uint256) (runs: 256, μ: 43099, ~: 43099)\n[PASS] testFuzz_TransferAboveBalanceReverts(uint256,uint256) (runs: 256, μ: 104628, ~: 105016)\n[PASS] testFuzz_TransferConservesSupply(address,uint256) (runs: 256, μ: 75473, ~: 75717)\n[PASS] testFuzz_TransferFromAboveAllowanceReverts(uint256,uint256) (runs: 256, μ: 107734, ~: 108083)\n[PASS] testFuzz_TransferFromConsumesFiniteAllowance(uint256,uint256) (runs: 256, μ: 137542, ~: 139253)\n[PASS] testFuzz_TransferSequenceConservesAllBalances(bytes32) (runs: 256, μ: 2671374, ~: 2675896)\n[PASS] test_ApprovalForAnotherSpenderDoesNotAuthorizeCaller() (gas: 92543)\n[PASS] test_ApproveEmitsEventWithoutMovingTokens() (gas: 82681)\n[PASS] test_ApproveOverwritesAndCanBeRevoked() (gas: 154866)\n[PASS] test_ApproveZeroSpenderReverts() (gas: 34745)\n[PASS] test_ConstructorEmitsOneMintTransfer() (gas: 7490)\n[PASS] test_DelegatedSelfTransferConsumesAllowanceWithoutChangingBalance() (gas: 106551)\n[PASS] test_DeployerCannotFreezeSeizeOrAdministerHolders() (gas: 280023)\n[PASS] test_DeployerCannotSpendHolderTokensWithoutApproval() (gas: 144120)\n[PASS] test_EntireSupplyBelongsToDeployer() (gas: 38824)\n[PASS] test_FactoryReceivesSupplyAndCanDistributeItExactly() (gas: 384687)\n[PASS] test_FailedTransferFromRollsBackAllowanceOnInsufficientBalance() (gas: 105701)\n[PASS] test_FailedTransferFromRollsBackAllowanceOnZeroRecipient() (gas: 95713)\n[PASS] test_MaximumAllowanceIsNotDecremented() (gas: 128134)\n[PASS] test_MetadataAndSupplyMatchRequest() (gas: 35852)\n[PASS] test_MintBurnInitializationAndUpgradeEntrypointsAreUnavailable() (gas: 383177)\n[PASS] test_SelfTransferAboveBalanceReverts() (gas: 37434)\n[PASS] test_TransferEntireBalance() (gas: 70267)\n[PASS] test_TransferFromCanSpendEntireAllowanceAndBalance() (gas: 155285)\n[PASS] test_TransferFromEmptyAccountReverts() (gas: 44797)\n[PASS] test_TransferFromRequiresAllowanceEvenWhenCallerIsHolder() (gas: 33374)\n[PASS] test_TransferFromSpendsAllowanceAndEmitsTransfer() (gas: 201052)\n[PASS] test_TransferFromZeroSenderRevertsEvenForZeroAmount() (gas: 33010)\n[PASS] test_TransferMovesExactAmountAndEmitsEvent() (gas: 80157)\n[PASS] test_TransferToZeroAddressReverts() (gas: 41854)\n[PASS] test_ZeroTransferFromEmptyAccountEmitsEvent() (gas: 57573)\n[PASS] test_ZeroTransferFromWithoutAllowanceIsAllowed() (gas: 68683)\n[PASS] test_ZeroTransferToZeroAddressAlsoReverts() (gas: 30404)\nSuite result: ok. 33 passed; 0 failed; 0 skipped; finished in 87.78ms (139.50ms CPU time)\n\nRan 1 test suite in 88.64ms (87.78ms CPU time): 33 tests passed, 0 failed, 0 skipped (33 total tests)\n","passed":true},{"durationMs":24,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"IMDwindowshopper.approve(address,uint256)\",\"IMDwindowshopper.transfer(address,uint256)\",\"IMDwindowshopper.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":3,\"README.md\":94,\"foundry.toml\":18,\"launch.json\":24,\"src/IMDwindowshopper.sol\":16,\"test/IMDwindowshopper.t.sol\":445,\"test/helpers/TokenTestBase.sol\":44},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"76b9db909fe45c3c1fbe50ecc8bba5b6ee1ad5f665d3c1cc4295d8148d831390","verifiedTreeHash":"85a46850c3843992b087a2d43273cca85a21ca4f","verifierVersion":"0.1.0+ad64f8c4"},{"checks":[{"durationMs":861,"exitCode":0,"name":"build","output":"Compiling 8 files with Solc 0.8.26\nSolc 0.8.26 finished in 774.20ms\nCompiler run successful!\n","passed":true},{"durationMs":254,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 33 tests for test/IMDwindowshopper.t.sol:IMDwindowshopperTest\n[PASS] testFuzz_SelfTransferCannotInflateBalance(uint256) (runs: 256, μ: 43099, ~: 43099)\n[PASS] testFuzz_TransferAboveBalanceReverts(uint256,uint256) (runs: 256, μ: 104628, ~: 105016)\n[PASS] testFuzz_TransferConservesSupply(address,uint256) (runs: 256, μ: 75473, ~: 75717)\n[PASS] testFuzz_TransferFromAboveAllowanceReverts(uint256,uint256) (runs: 256, μ: 107734, ~: 108083)\n[PASS] testFuzz_TransferFromConsumesFiniteAllowance(uint256,uint256) (runs: 256, μ: 137542, ~: 139253)\n[PASS] testFuzz_TransferSequenceConservesAllBalances(bytes32) (runs: 256, μ: 2671374, ~: 2675896)\n[PASS] test_ApprovalForAnotherSpenderDoesNotAuthorizeCaller() (gas: 92543)\n[PASS] test_ApproveEmitsEventWithoutMovingTokens() (gas: 82681)\n[PASS] test_ApproveOverwritesAndCanBeRevoked() (gas: 154866)\n[PASS] test_ApproveZeroSpenderReverts() (gas: 34745)\n[PASS] test_ConstructorEmitsOneMintTransfer() (gas: 7490)\n[PASS] test_DelegatedSelfTransferConsumesAllowanceWithoutChangingBalance() (gas: 106551)\n[PASS] test_DeployerCannotFreezeSeizeOrAdministerHolders() (gas: 280023)\n[PASS] test_DeployerCannotSpendHolderTokensWithoutApproval() (gas: 144120)\n[PASS] test_EntireSupplyBelongsToDeployer() (gas: 38824)\n[PASS] test_FactoryReceivesSupplyAndCanDistributeItExactly() (gas: 384687)\n[PASS] test_FailedTransferFromRollsBackAllowanceOnInsufficientBalance() (gas: 105701)\n[PASS] test_FailedTransferFromRollsBackAllowanceOnZeroRecipient() (gas: 95713)\n[PASS] test_MaximumAllowanceIsNotDecremented() (gas: 128134)\n[PASS] test_MetadataAndSupplyMatchRequest() (gas: 35852)\n[PASS] test_MintBurnInitializationAndUpgradeEntrypointsAreUnavailable() (gas: 383177)\n[PASS] test_SelfTransferAboveBalanceReverts() (gas: 37434)\n[PASS] test_TransferEntireBalance() (gas: 70267)\n[PASS] test_TransferFromCanSpendEntireAllowanceAndBalance() (gas: 155285)\n[PASS] test_TransferFromEmptyAccountReverts() (gas: 44797)\n[PASS] test_TransferFromRequiresAllowanceEvenWhenCallerIsHolder() (gas: 33374)\n[PASS] test_TransferFromSpendsAllowanceAndEmitsTransfer() (gas: 201052)\n[PASS] test_TransferFromZeroSenderRevertsEvenForZeroAmount() (gas: 33010)\n[PASS] test_TransferMovesExactAmountAndEmitsEvent() (gas: 80157)\n[PASS] test_TransferToZeroAddressReverts() (gas: 41854)\n[PASS] test_ZeroTransferFromEmptyAccountEmitsEvent() (gas: 57573)\n[PASS] test_ZeroTransferFromWithoutAllowanceIsAllowed() (gas: 68683)\n[PASS] test_ZeroTransferToZeroAddressAlsoReverts() (gas: 30404)\nSuite result: ok. 33 passed; 0 failed; 0 skipped; finished in 144.57ms (243.19ms CPU time)\n\nRan 1 test suite in 145.40ms (144.57ms CPU time): 33 tests passed, 0 failed, 0 skipped (33 total tests)\n","passed":true},{"durationMs":67,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"IMDwindowshopper.approve(address,uint256)\",\"IMDwindowshopper.transfer(address,uint256)\",\"IMDwindowshopper.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":3,\"README.md\":94,\"foundry.toml\":18,\"src/IMDwindowshopper.sol\":16,\"test/IMDwindowshopper.t.sol\":445,\"test/helpers/TokenTestBase.sol\":44},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true},{"durationMs":777,"exitCode":0,"name":"slither","output":"slither: no results at low impact or above","passed":true},{"durationMs":427,"exitCode":0,"name":"aderyn","output":"[low] large-numeric-literal at src/IMDwindowshopper.sol:11: Large Numeric Literal","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"c55a570afc0cd9180f419c75939508f1c40e2007d6203d0e2e366db27d2a37d2","verifiedTreeHash":"ba8058331464504ca0a8f7ca758b71f0e1a935ee","verifierVersion":"0.1.0+ad64f8c4"}]}