{"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":"5953f214-c3ce-4373-810a-83d35a173336","kind":"shape:chain","nodes":[{"acceptedSubmissionHash":"f9d2c2b717c401c874d92697b56fcefd1654f53e1e4b62eb6cd956fb50a45c01","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":"63bf1a23c82e87b91d80e4a7b9520394bbcbf929477760a90af7573c7585d6e0","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":"8f4101aa92287b3b44908068b4d666accf78448ca5891cfeaacbb076bd62eb17","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":"3c6caa4a5e846e7ee686b3a12619c541c943ac0e58c0ce4cf6e324d3fdc3b670","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":"e29a0c41b1b47c5c91b288ce25c1ada8a315d560d2bc838131d9e7540119c0c8","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":"ef88ec103f1d2635b5250c7a316b71f6dee43a576ca6a21a90f85f08c72bbf59","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":"7816410587bc61afd59430a2376ebe78a7b74e4b01e43d106c524cb31117b456","dependsOn":["build_contract_project"],"execution":{"network":false,"profile":"foundry","requires":[],"tools":[]},"key":"manifest","kind":"code","role":"integrate","skillHash":null,"skillId":null,"state":"accepted"},{"acceptedSubmissionHash":"e1a55349cf7e39a6802b7413bc67bd8d0d7521e0651f4bf011800f9989a15dbc","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: Keel (KEEL).\nToken name: Keel\nToken symbol: KEEL\nToken supply: 1,000,000,000 with 18 decimals, all minted once to the deployer in the constructor.","parentJobId":null,"planHash":"4d9df05e38a08c9d6d7c373b2126916f18f4850446c3198c786e9db3282d33bb","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"5953f214-c3ce-4373-810a-83d35a173336","publication":{"commit":null,"deliveredAt":null,"repoUrl":"https://github.com/identity-md-launches/launch-1972-keel"},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[],"schema":"identitymd-work-v1","signals":[{"agentId":"51082","feedbackHash":"619855daa6ef434efe6434c641a1ff2367a1ab19074f9ed3d539c916486c2a8d","nodeKey":"audit_economics","submissionHash":"f9d2c2b717c401c874d92697b56fcefd1654f53e1e4b62eb6cd956fb50a45c01","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52167","feedbackHash":"d46c3797629a3cfe47b4588d71a0096aadee6a3fd20efefe13cf672f421678be","nodeKey":"audit_flow","submissionHash":"63bf1a23c82e87b91d80e4a7b9520394bbcbf929477760a90af7573c7585d6e0","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52152","feedbackHash":"2eb2153b8ef2cbd743c5efcea182beffa7101da469b4cd41a9c514e40bbe49b0","nodeKey":"audit_judge","submissionHash":"8f4101aa92287b3b44908068b4d666accf78448ca5891cfeaacbb076bd62eb17","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51512","feedbackHash":"085bab180ad7a00e23fe20f5514e996a8dac5cf186bfd83293372a3b26d85bb6","nodeKey":"audit_math","submissionHash":"3c6caa4a5e846e7ee686b3a12619c541c943ac0e58c0ce4cf6e324d3fdc3b670","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51509","feedbackHash":"b5e138217dcb0bf626e47c7722d09ca658d1c86a9cf42488aa42237c931e98c1","nodeKey":"audit_permissions","submissionHash":"e29a0c41b1b47c5c91b288ce25c1ada8a315d560d2bc838131d9e7540119c0c8","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51479","feedbackHash":"81f187b7907e2bdd77f88c47cd1dbce98b8830699e466ef8ffc7082d1d618a90","nodeKey":"build_contract_project","submissionHash":"ef88ec103f1d2635b5250c7a316b71f6dee43a576ca6a21a90f85f08c72bbf59","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"51508","feedbackHash":"521c97e673d5fb57f9583ce1281b7ea498d1a975586ac7fd37af41cc1b03f2b1","nodeKey":"manifest","submissionHash":"7816410587bc61afd59430a2376ebe78a7b74e4b01e43d106c524cb31117b456","tag1":"verification:checks","tag2":"acceptance-v2","value":1},{"agentId":"51507","feedbackHash":"f27fa9dae7a82056fba6f623a97a642a3e94781246ebed6068a4c3d5512ce7d2","nodeKey":"write_foundry_tests","submissionHash":"e1a55349cf7e39a6802b7413bc67bd8d0d7521e0651f4bf011800f9989a15dbc","tag1":"verification:checks","tag2":"acceptance-v2","value":1}],"site":null,"snapshotHash":"587f6fc4b4aef14733b7b5b4ca0532c1cb1c6cd8474bb3f2acbf59464fb743b8","state":"completed","submissions":[{"artifacts":[],"attempt":1,"bundleHash":null,"device":"8c9c4986ca881107","findings":[{"citation":"resolved","description":"README.md lists `sha256sum --check lib/SHA256SUMS` as one of the project's build-and-check commands, THIRD_PARTY.md states that lib/SHA256SUMS records the SHA-256 of every vendored file and that upstream files are unmodified, and SECURITY.md says vendored dependencies are pinned and recorded there. On the committed tree (HEAD 595e063) the check fails for seven forge-std files: lib/forge-std/src/StdJson.sol, lib/forge-std/src/interfaces/IMulticall3.sol, lib/forge-std/src/console.sol, lib/forge-std/src/Vm.sol, lib/forge-std/src/interfaces/IERC7540.sol, lib/forge-std/src/StdAssertions.sol and lib/forge-std/src/StdToml.sol. For example the committed blob of lib/forge-std/src/Vm.sol hashes to a1b1c829...02a15 while lib/SHA256SUMS records 9068805b...1c2b1 for it. All OpenZeppelin files (the only vendored code that reaches the deployed bytecode) match their recorded sums, so the token's runtime is unaffected; forge-std is test-only. The defect is in provenance: the tree's own integrity record does not describe the tree, so a reviewer cannot use it to confirm that the test harness is the unmodified forge-std v1.9.7 the documentation claims. Fix: regenerate lib/SHA256SUMS from the files actually committed (or restore the seven files to the version the sums were taken from) so the documented check passes.","line":57,"path":"README.md","reproduction":"State: a clean checkout of HEAD 595e063 (git status is clean). Run `sha256sum --check lib/SHA256SUMS` from the repository root. Expected (per README.md line 57 and THIRD_PARTY.md line 5): every line reports OK and the command exits 0. Actual: 29 OK, 7 FAILED (StdJson.sol, interfaces/IMulticall3.sol, console.sol, Vm.sol, interfaces/IERC7540.sol, StdAssertions.sol, StdToml.sol), 'WARNING: 7 computed checksums did NOT match', exit status 1. Confirm it is the committed content and not a working-tree edit with `git cat-file -p HEAD:lib/forge-std/src/Vm.sol | sha256sum` (a1b1c82924aecf0f38b53192fd1e801cccc1e1fd2ecd6b2301e4f4c4ab102a15) against the recorded 9068805b59ac1d0ea03a8fa1f15ae49c094e0c6c852a2500e0dd112f264b2cb1.","severity":"low","snippet":"sha256sum --check lib/SHA256SUMS","title":"Documented vendored-dependency integrity check fails: 7 committed forge-std files do not match lib/SHA256SUMS"}],"hash":"3c6caa4a5e846e7ee686b3a12619c541c943ac0e58c0ce4cf6e324d3fdc3b670","nodeId":"d374168f-c2a7-4e36-9806-1dc8409a1c2b","outcome":"completed","summary":"The review is complete and `.imd-findings.json` is written. The working tree is clean apart from the gitignored scratch test and the findings file.\n\n**Outcome.** The Keel token's math holds across all three assigned guides. The contract is 17 lines on top of an unmodified OpenZeppelin v5 ERC20, with one compile-time constant and no division, fee, scale conversion, external call, payable path or bytes decoding. I found no defect in the assigned area. One low finding outside the area is recorded.\n\n**What I checked in my area**\n\n- **Math Precision.** The only arithmetic is the supply constant. It evaluates to exactly 1e27, fits below 2^96, and the 10% and 88% launch shares divide with zero remainder. Balance updates in the vendored ERC20 are guarded before their unchecked subtraction, and the recipient add cannot wrap because balances always sum to the supply.\n- **Boundary.** Probed transfer values of 0, 1, supply, supply+1 and max uint, self-transfers, allowance at max, max minus one, exactly equal and above balance, zero owner and spender, and ETH sent to the contract. Every case reverts or succeeds as the ERC-20 contract and README describe, with state unchanged on revert.\n- **Numerical Gap.** There is no seam to exploit: no formula pair, no accumulator, no truncated quantity, no edge fast path that skips an invariant. A seeded fuzz over three-holder splits confirmed conservation.\n\n**The one finding (low).** The README documents `sha256sum --check lib/SHA256SUMS` as a project check, and THIRD_PARTY.md says the file records every vendored file unmodified. On the committed tree that command fails for seven forge-std files, including Vm.sol and StdAssertions.sol. All OpenZeppelin files match, so the deployed bytecode is unaffected. This is a provenance gap in the test harness only, with the exact command and hashes in the reproduction.\n\n**Coverage.** All three ABI entry points are marked `holds`, plus rows for the supply, decimals, narrow-width, boundary-surface, vendored-library and aderyn-lead invariants. The aderyn large-literal lead is a readability note, not a defect. Nothing was left unreached.","treeHash":null,"usage":{"cachedInputTokens":721877,"inputTokens":322,"model":"claude-fable-5-1","outputTokens":11684,"runtime":"claude","turns":16,"wallClockMs":178877}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"1ca477e8d9b58040","findings":[{"citation":"resolved","description":"README.md lists `sha256sum --check lib/SHA256SUMS` as one of the four build-and-check commands, and the README's 'Build and check' text says the vendored dependencies are attested by that manifest. On the committed tree (git status clean, all 37 lib files tracked) the command reports 7 mismatches, all in lib/forge-std/src: StdJson.sol, interfaces/IMulticall3.sol, console.sol, Vm.sol, interfaces/IERC7540.sol, StdAssertions.sol, StdToml.sol. Root cause (verified): the recorded hashes are those of pristine forge-std v1.9.7 (e.g. lib/SHA256SUMS line 23 records 9068805b... for Vm.sol, which is exactly upstream v1.9.7/src/Vm.sol), but the files in the tree were afterwards re-wrapped by `forge fmt` under this project's `line_length = 120` setting (`forge fmt --check` now passes, so fmt was run over lib/). A whitespace-stripped comparison of each of the 7 files against upstream v1.9.7 is byte-identical, so no semantic change was introduced and the test library (including StdAssertions) is trustworthy. The vendored OpenZeppelin files (ERC20.sol, Context.sol, IERC20.sol, IERC20Metadata.sol, draft-IERC6093.sol) all match upstream v5.0.2 exactly and pass the sums. Impact: the integrity manifest the README tells a reviewer or the deployer to rely on does not attest to the tree as shipped; a reviewer following the README gets a FAILED result and cannot distinguish a formatting drift from a tampered test library without redoing the upstream comparison done here. No effect on src/Keel.sol or its bytecode. Fix: regenerate lib/SHA256SUMS from the tree as committed (`sha256sum $(git ls-files lib | grep -v SHA256SUMS) > lib/SHA256SUMS`), or restore the 7 files to their pristine v1.9.7 bytes and exclude lib/ from fmt; either way the documented command must pass on the committed tree.","line":57,"path":"README.md","reproduction":"State: the committed tree (595e063), clean working copy. Input: run `sha256sum --check lib/SHA256SUMS` from the repository root, as README.md line 57 instructs. Expected (per README): every line ': OK', exit 0. Actual: `lib/forge-std/src/StdJson.sol: FAILED`, `lib/forge-std/src/interfaces/IMulticall3.sol: FAILED`, `lib/forge-std/src/console.sol: FAILED`, `lib/forge-std/src/Vm.sol: FAILED`, `lib/forge-std/src/interfaces/IERC7540.sol: FAILED`, `lib/forge-std/src/StdAssertions.sol: FAILED`, `lib/forge-std/src/StdToml.sol: FAILED`, `sha256sum: WARNING: 7 computed checksums did NOT match`, exit 1. Confirming the cause: `sha256sum lib/forge-std/src/Vm.sol` gives a1b1c829..., while lib/SHA256SUMS line 23 records 9068805b..., which equals sha256 of https://raw.githubusercontent.com/foundry-rs/forge-std/v1.9.7/src/Vm.sol; `diff` of the two shows only multi-line signatures re-joined to single lines (e.g. Vm.sol line 827 `function getDeployment(...)` joined), and `tr -d ' \\n\\t' < file | sha256sum` is identical for upstream and local on all 7 files.","severity":"low","snippet":"sha256sum --check lib/SHA256SUMS","title":"Documented integrity check `sha256sum --check lib/SHA256SUMS` fails on the shipped tree (7 forge-std files reformatted after the sums were recorded)"},{"citation":"resolved","description":"Keel inherits OpenZeppelin v5 ERC20 unchanged, and the brief asks for a plain fixed-supply token, so this is recorded as a behaviour the author and integrators should know about, not a defect requiring a change. approve(spender, value) overwrites the allowance unconditionally. If an owner lowers an existing non-zero allowance, a spender who sees the pending approve can spend the old allowance first and then the new one, so the total spendable is old + new rather than new. OZ v5 deliberately removed increaseAllowance/decreaseAllowance, and Keel adds neither those nor ERC-2612 permit, so the only mitigation available to holders is the approve(0)-then-approve(new) pattern. The README already documents that approve replaces the allowance and that transferFrom consumes finite allowances without emitting Approval (both confirmed by test). Execution-trace check of transferFrom: _spendAllowance reads the allowance and _transfer follows in the same call with no external calls in between, so there is no stale read or reentrancy; the residual-allowance exposure is only the cross-transaction ordering described here. This does not affect the launch flows (factory to distributor, factory to PoolManager seed, trader swaps), which use transfer or exact-amount transferFrom. No change is required under the agreed design; if the author wants to narrow it, adding ERC20Permit or explicit increase/decrease helpers is a scope decision, not a fix.","line":132,"path":"lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol","reproduction":"Verified with test/scratch/KeelReview.t.sol test_allowanceReplaceCanBeFrontRun (passes, i.e. the sequence executes as described). State: owner holds the supply. Sequence: (1) owner calls approve(spender, 100e18); (2) owner submits approve(spender, 50e18) intending to lower it; (3) spender, before (2) is mined, calls transferFrom(owner, sink, 100e18): succeeds, sink balance 100e18, allowance 0; (4) approve(spender, 50e18) is mined: allowance 50e18; (5) spender calls transferFrom(owner, sink, 50e18): succeeds. Result: sink holds 150e18 and allowance is 0, where the owner intended at most 50e18 spendable after step (2). totalSupply unchanged at 1e27.","severity":"info","snippet":"    function approve(address spender, uint256 value) public virtual returns (bool) {","title":"Allowance replacement via approve() is front-runnable (standard ERC-20 behaviour; no increaseAllowance/decreaseAllowance or permit offered)"}],"hash":"63bf1a23c82e87b91d80e4a7b9520394bbcbf929477760a90af7573c7585d6e0","nodeId":"f3492861-1486-441a-9687-4e220c6e1845","outcome":"completed","summary":"The review is complete and the findings file is written and validated. Nothing further is needed from the tree.\n\n**Outcome:** the Keel token holds in my area. Both findings are outside the token's control flow and neither touches `src/Keel.sol`.\n\n**What I covered**\n\n- **Execution Trace:** traced `transfer`, `transferFrom` and `approve` through the OZ `_update`, `_spendAllowance` and `_approve` paths. No external calls, no stale reads, atomic reverts, exact amounts moved. The launch flows the protected test exercises all move exactly what they say.\n- **Periphery:** every vendored OpenZeppelin file is byte-identical to upstream v5.0.2. The seven forge-std files that fail the checksum manifest differ from v1.9.7 by whitespace only, which I confirmed by a whitespace-stripped comparison.\n- **First Principles:** supply is minted once to `msg.sender` and no selector can grow it. No `receive` or `fallback`. Runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. The project's 30 tests pass with the documented seed, and my scratch test confirmed the behaviors I recorded.\n\n**Findings written to `.imd-findings.json`**\n\n1. **Low.** The README's documented check `sha256sum --check lib/SHA256SUMS` fails on the committed tree. Seven forge-std files were reformatted by `forge fmt` after the sums were taken from pristine v1.9.7. Semantics are unchanged, but the integrity manifest does not attest to the tree as shipped. Fix is to regenerate the sums or restore the pristine files.\n2. **Info.** Standard ERC-20 allowance replacement is front-runnable and the token offers no increase/decrease helpers or permit. This is by design for a plain token and is recorded as a trust note for integrators, not a defect.\n\n**Coverage record:** all three listed entry points marked `holds`, plus four invariant rows. One row (vendored forge-std) references finding 1. No proof tests were attached since nothing reached high or critical severity.","treeHash":null,"usage":{"cachedInputTokens":1408656,"inputTokens":674,"model":"claude-fable-5-1","outputTokens":18592,"runtime":"claude","turns":22,"wallClockMs":281567}},{"artifacts":[],"attempt":1,"bundleHash":"def94b5bcbc687e6d141ae59cf482bad67a75ade2b7df21b403a98ee65a746e5","device":"3516474d8a268bd8","findings":[],"hash":"7816410587bc61afd59430a2376ebe78a7b74e4b01e43d106c524cb31117b456","nodeId":"11dfe815-4334-4f1e-801e-9e9e9a9a7cf4","outcome":"completed","summary":"Done. I wrote `launch.json` for the Keel launch and verified the tree builds and tests pass.\n\n**What the manifest says**\n- Token contract `Keel`, name Keel, symbol KEEL, 18 decimals, no constructor arguments. This matches the accepted `src/Keel.sol`, whose constructor takes nothing and mints the whole supply to msg.sender.\n- totalSupply is the constructor's mint, 10^27 minor units, written as a decimal string.\n- No application contracts, since the accepted tree has none.\n- pool and economics are copied exactly as the launch reference gives them: native ETH as the zero address, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's verbatim economics object.\n- notes describe only the Keel contract and its fixed-supply, no-admin behavior, well under the 4000 character limit.\n\n**Checks run**\n- A schema sanity check on the JSON confirmed only the six schema keys are present, economics is byte-identical to the job's, and totalSupply is 10^27.\n- `forge build` compiled cleanly.\n- `forge test` with the verifier's fuzz seed passed all 30 tests across both suites.\n\nGit status shows `launch.json` as the only new file. Nothing else was changed.","treeHash":"add71d0b833cc44fc01a9278f72393e76172283f","usage":{"cachedInputTokens":185918,"inputTokens":130,"model":"claude-fable-5-1","outputTokens":2558,"runtime":"claude","turns":8,"wallClockMs":46031}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"7c748c02cd2ee98f","findings":[{"citation":"resolved","description":"README.md lists `sha256sum --check lib/SHA256SUMS` as one of the four build-and-check commands, and THIRD_PARTY.md states that upstream files are unmodified and that lib/SHA256SUMS records the SHA-256 of every vendored file. On the committed tree the command reports 7 mismatches, all under lib/forge-std/src: StdJson.sol, interfaces/IMulticall3.sol, console.sol, Vm.sol, interfaces/IERC7540.sol, StdAssertions.sol, StdToml.sol. Reproduced and root-caused: I fetched each of the seven files from upstream forge-std v1.9.7 (raw.githubusercontent.com at that tag); each upstream file hashes to exactly the digest lib/SHA256SUMS records (e.g. Vm.sol -> 9068805b59ac1d0e..., SHA256SUMS line 23), while the vendored copies hash differently (Vm.sol -> a1b1c82924aecf0f...). Stripping all whitespace from each pair gives identical digests for all seven, so the only difference is line wrapping, consistent with `forge fmt` (line_length = 120) having been run over lib/ (`forge fmt --check` passes). All five vendored OpenZeppelin v5.0.2 files (ERC20, IERC20, IERC20Metadata, Context, draft-IERC6093) are byte-identical to upstream and pass the manifest, so nothing that reaches Keel's deployed bytecode is affected, and the test library is semantically unmodified. The defect is in provenance: the project's own stated integrity gate fails as shipped, and the THIRD_PARTY.md claim that upstream files are unmodified is not true byte-for-byte. A reviewer following the README cannot distinguish this benign reformat from a tampered StdAssertions.sol/Vm.sol without redoing the upstream comparison. Merged from five identical reports (audit_flow, write_foundry_tests, audit_permissions, audit_math, audit_economics). Fix: regenerate lib/SHA256SUMS from the committed files (`sha256sum $(git ls-files lib | grep -v SHA256SUMS) > lib/SHA256SUMS`) and note in THIRD_PARTY.md that forge-std was reformatted, or restore the seven files to upstream bytes and exclude lib/ from fmt. Either way the documented command must exit 0 on the committed tree.","line":57,"path":"README.md","reproduction":"State: clean checkout of HEAD (git status clean). From the repository root run `sha256sum --check lib/SHA256SUMS` as README.md line 57 instructs. Expected (README.md line 57, THIRD_PARTY.md line 5): every line ': OK', exit 0. Actual: lib/forge-std/src/StdJson.sol: FAILED, lib/forge-std/src/interfaces/IMulticall3.sol: FAILED, lib/forge-std/src/console.sol: FAILED, lib/forge-std/src/Vm.sol: FAILED, lib/forge-std/src/interfaces/IERC7540.sol: FAILED, lib/forge-std/src/StdAssertions.sol: FAILED, lib/forge-std/src/StdToml.sol: FAILED, 'sha256sum: WARNING: 7 computed checksums did NOT match', exit 1. Cause check: `sha256sum lib/forge-std/src/Vm.sol` = a1b1c82924aecf0f38b53192fd1e801cccc1e1fd2ecd6b2301e4f4c4ab102a15; lib/SHA256SUMS line 23 = 9068805b59ac1d0ea03a8fa1f15ae49c094e0c6c852a2500e0dd112f264b2cb1, which is sha256 of https://raw.githubusercontent.com/foundry-rs/forge-std/v1.9.7/src/Vm.sol; `tr -d ' \\t\\n\\r' < file | sha256sum` is equal for the vendored and upstream copy of each of the seven files.","severity":"low","snippet":"sha256sum --check lib/SHA256SUMS","title":"Documented vendored-dependency integrity check fails: 7 forge-std files were reformatted after lib/SHA256SUMS was recorded"},{"citation":"resolved","description":"Keel inherits OpenZeppelin v5 ERC20 unchanged. approve(spender, value) overwrites the stored allowance; OZ v5 removed increaseAllowance/decreaseAllowance and Keel adds neither those nor ERC-2612 permit. A holder who lowers a non-zero allowance can be front-run by the spender, who spends the old allowance first and then the new one. This is the well-known ERC-20 allowance race, not a defect in the requested fixed-supply design, and the README already documents that approve replaces the allowance. It does not touch the launch flows (factory to distributor, pool seed, swaps), which use transfer or exact-amount transferFrom. Recorded as a trust note for integrators; no change is required under the agreed design. If the author wants to narrow it, adding ERC20Permit or explicit increase/decrease helpers is a scope decision. Reported by audit_flow; reproduced with test/scratch/KeelApprove.t.sol (passes, i.e. the sequence executes as described).","line":132,"path":"lib/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol","reproduction":"State: owner holds the supply. (1) owner: approve(spender, 100e18). (2) owner submits approve(spender, 50e18) intending to lower it. (3) before (2) is mined, spender: transferFrom(owner, sink, 100e18) succeeds; allowance 0. (4) approve(spender, 50e18) mined; allowance 50e18. (5) spender: transferFrom(owner, sink, 50e18) succeeds. Expected by the owner: at most 50e18 spendable after step (2). Actual: sink holds 150e18, allowance 0, totalSupply unchanged at 1e27.","severity":"info","snippet":"    function approve(address spender, uint256 value) public virtual returns (bool) {\n        address owner = _msgSender();\n        _approve(owner, spender, value);\n        return true;\n    }","title":"approve() replaces the allowance unconditionally, so lowering a live allowance is front-runnable (standard ERC-20; no increase/decrease helpers or permit)"}],"hash":"8f4101aa92287b3b44908068b4d666accf78448ca5891cfeaacbb076bd62eb17","nodeId":"3298e5f2-7b7f-4768-85b2-2b9aa81cd414","outcome":"completed","summary":"Findings file is written and the scratch tests are removed. Final check of the tree state and the findings file is done.\n\n**Outcome:** the Keel token holds on every floor check. The only substantiated defect is a documentation and provenance drift, kept at low severity. The findings are in `.imd-findings.json`.\n\n**What I reproduced**\n\n- **Checksum gate fails (low, merged from five specialists).** Running the README's `sha256sum --check lib/SHA256SUMS` reports seven forge-std files as FAILED. I fetched the seven files from upstream forge-std v1.9.7 and confirmed each upstream file hashes to exactly the recorded digest, while the vendored copies differ only in whitespace. So the drift is a `forge fmt` pass over lib/, not tampering. The five OpenZeppelin v5.0.2 files are byte-identical to upstream. Nothing that reaches deployed bytecode is affected, but the documented integrity check and the \"unmodified\" claim in THIRD_PARTY.md are false as shipped.\n- **Allowance replacement race (info).** The standard ERC-20 approve race reproduces in a scratch test. It is inherited OpenZeppelin behaviour under the agreed design, so it is recorded as a trust note, not a defect.\n\n**My own review of the token**\n\n- Fixed supply of 1e27 minted once to msg.sender via CREATE2, decimals 18, name and symbol match launch.json.\n- No mint, owner, pause, blacklist, burnFrom or initializer exists. All 22 admin-style selectors revert from a stranger and from the deployer, with supply and holder balances unchanged.\n- Runtime code contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, and both creation and runtime sizes are far under the limits.\n- Transfers move exactly the requested amount, so the distributor share, pool seed and swaps arrive whole.\n- launch.json uses only schema keys, an empty constructorArgs list matching the zero-parameter constructor, the exact minted supply, and lowercase addresses.\n- The project's own 56 tests pass with the README's fuzz seed, and `forge fmt --check` passes.\n\n**Coverage:** all three entry points answered as holds, plus five invariant rows, one of which points at the checksum finding.\n\n**Not verifiable here:** the protected floor tests import v4-core and launch helper sources that are not in this repository, so I could not run them directly. I replicated their supply, decimals, admin-call and opcode checks in a scratch test, which passed.","treeHash":null,"usage":{"cachedInputTokens":476695,"inputTokens":258,"model":"claude-fable-5-1","outputTokens":11375,"runtime":"claude","turns":9,"wallClockMs":179950}},{"artifacts":[],"attempt":1,"bundleHash":"4b94fce9625064d97921a82522b9a3967fc62eca9fb490d4038102a23839aaf0","device":"2dc755dfe7bd177c","findings":[{"description":"README.md tells reviewers to verify the vendored dependencies with `sha256sum --check lib/SHA256SUMS`. Seven forge-std files no longer match the recorded digests: lib/forge-std/src/StdJson.sol, lib/forge-std/src/StdToml.sol, lib/forge-std/src/StdAssertions.sol, lib/forge-std/src/Vm.sol, lib/forge-std/src/console.sol, lib/forge-std/src/interfaces/IMulticall3.sol and lib/forge-std/src/interfaces/IERC7540.sol. All seven are already clean under `forge fmt --check` with the repository's 120-column setting, so the likely cause is that the digests were recorded before the files were reformatted. The OpenZeppelin files, which the token actually compiles against, all match. This does not affect src/Keel.sol or any test, but the documented provenance check cannot pass as shipped and should be regenerated (or the README's instruction dropped). Not testable from test/: lib/ and README.md are outside the paths this task may change, and a test cannot read the file system without the FFI/fs permissions the README promises are unnecessary.","line":1,"path":"lib/SHA256SUMS","reproduction":"In the repository root run `sha256sum --check lib/SHA256SUMS`. Expected: every line reports OK, as README.md states. Actual: the seven files above report FAILED and sha256sum exits with 'WARNING: 7 computed checksums did NOT match'.","severity":"info","title":"README's vendored-library integrity check fails for seven forge-std files"}],"hash":"e1a55349cf7e39a6802b7413bc67bd8d0d7521e0651f4bf011800f9989a15dbc","nodeId":"9dd52460-11a8-4c3e-ae0a-73ba0b50eef5","outcome":"completed","summary":"Done. The suite is complete and verified.\n\n**Outcome.** The full Foundry suite passes with the verifier's fuzz seed, and only files under `test/` were added. No defect was found in the Keel token itself. It is a plain fixed-supply OpenZeppelin ERC-20 with no mint, burn, or admin surface.\n\n| Check | Result |\n| --- | --- |\n| `forge build` | clean |\n| `forge test` with the verifier seed | 56 passed, 0 failed, 0 skipped |\n| `forge fmt --check test/` | clean |\n| Paths changed | `test/KeelProperties.t.sol`, `test/KeelFailurePaths.invariant.t.sol` |\n\n**What I added** on top of the earlier contributor's 30 tests, which I left untouched:\n\n- **`test/KeelProperties.t.sol`** holds 25 property and edge tests. They cover raw creation-code deployment through CREATE2 in one call with address prediction and the initiator receiving nothing, a factory claiming the wrong supply, salt reuse, arbitrary deployers, independent deployments, net-zero round trips, repeated transfers until the balance runs out, up to 48 holders conserving the supply, transfers to inert contracts and to the token itself, exact event counts, approve overwrite and idempotence, allowance exactly consumed, the one-below-max allowance boundary, the re-approval race, allowance checked before balance and before the zero-receiver check, a holder needing its own allowance, transfers from the zero owner, and that no caller can alter another owner's allowance.\n- **`test/KeelFailurePaths.invariant.t.sol`** is a second invariant suite that mixes valid and deliberately invalid calls in random order across six unevenly funded actors. Each invalid call must revert with the exact ERC-6093 error and leave a state fingerprint unchanged. Invariants check the ledger, fixed supply fully held by the actors, immutable metadata and code hash, and a ghost-volume bound. The run table shows all 14 entry points exercised over a thousand times each with zero unexpected reverts.\n\n**One finding reported**, severity info, in `.imd-findings.json`. The README instructs reviewers to run `sha256sum --check lib/SHA256SUMS`, but seven forge-std files no longer match their recorded digests. All seven are already formatter-clean, so the digests were most likely recorded before a reformat. The OpenZeppelin files the token compiles against all match, and nothing in the token or tests is affected. It is outside my allowed paths, so it is reported rather than fixed.","treeHash":"b370131427ca484cd1881130c2b578edc177e6fe","usage":{"cachedInputTokens":837354,"inputTokens":354,"model":"claude-fable-5-1","outputTokens":34178,"runtime":"claude","turns":25,"wallClockMs":462757}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"74a99f640688d37b","findings":[{"citation":"resolved","description":"README.md (Build and check) and THIRD_PARTY.md state that every vendored file is unmodified upstream source and that lib/SHA256SUMS records the SHA-256 of each one, so a reviewer following the handoff is told to run `sha256sum --check lib/SHA256SUMS` as a provenance gate. In the tree as committed (595e063) that gate fails for seven forge-std files: StdJson.sol, interfaces/IMulticall3.sol, console.sol, Vm.sol, interfaces/IERC7540.sol, StdAssertions.sol and StdToml.sol. Every OpenZeppelin file passes the manifest, and I independently confirmed the five OpenZeppelin files are byte-identical to upstream v5.0.2 (fetched from raw.githubusercontent.com at that tag). For forge-std I fetched the v1.9.7 tarball (its SHA-256 matches the one THIRD_PARTY.md quotes, 45157353ab49...) and diffed: the seven mismatching files differ from upstream only in whitespace and line wrapping (a `forge fmt` pass with line_length = 120 was applied to lib/), with identical content once whitespace is stripped. So there is no tampering and nothing in Keel's deployed bytecode is affected (forge-std is test-only), but the deliverable's own stated integrity guarantee is false and anyone running the documented check gets a FAILED result with no explanation. Trust-gap impact: a reviewer who trusts the manifest cannot distinguish this benign reformat from a real modification of Vm.sol/StdAssertions.sol, which are exactly the files that could silently weaken the test suite the SECURITY.md relies on. Fix: either restore the seven files to their upstream bytes (and exclude lib/ from `forge fmt`), or regenerate lib/SHA256SUMS from the reformatted files and state in THIRD_PARTY.md that forge-std was reformatted. Either way, `sha256sum --check lib/SHA256SUMS` must pass as README.md claims.","line":57,"path":"README.md","reproduction":"From the repository root run: `sha256sum --check lib/SHA256SUMS`. Expected (per README.md line 57 and THIRD_PARTY.md 'lib/SHA256SUMS records the SHA-256 of every vendored file ... unmodified'): every line reports OK. Actual: `sha256sum: WARNING: 7 computed checksums did NOT match`, with FAILED for lib/forge-std/src/StdJson.sol, lib/forge-std/src/interfaces/IMulticall3.sol, lib/forge-std/src/console.sol, lib/forge-std/src/Vm.sol, lib/forge-std/src/interfaces/IERC7540.sol, lib/forge-std/src/StdAssertions.sol and lib/forge-std/src/StdToml.sol. Confirming the difference is formatting only: `diff lib/forge-std/src/Vm.sol <upstream v1.9.7 Vm.sol>` shows only re-wrapped signatures; `tr -d ' \\t\\n\\r' < each | sha256sum` is equal for the vendored and upstream copies of all seven files.","severity":"low","snippet":"sha256sum --check lib/SHA256SUMS","title":"Documented vendored-dependency integrity check fails: 7 forge-std files do not match lib/SHA256SUMS"}],"hash":"e29a0c41b1b47c5c91b288ce25c1ada8a315d560d2bc838131d9e7540119c0c8","nodeId":"3f7c5d06-449b-42b1-aa97-46a629ebb56e","outcome":"completed","summary":"The review is complete and written to `.imd-findings.json`. The working tree is otherwise untouched (git reports clean apart from the findings file, which is gitignored by the harness).\n\n**Outcome:** the Keel token's permission model is sound. It is a plain OpenZeppelin v5.0.2 ERC20 with one constructor that mints the full supply to msg.sender. There are no roles, no owner, no initializer, no mint, burn, pause, blacklist or upgrade entry point, and the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT. The deployer becomes an ordinary holder and cannot move anyone else's balance without an allowance.\n\n**What I checked in my area (Access Control, Trust Gap, Asymmetry):**\n- **Entry points.** All three listed entry points (approve, transfer, transferFrom) trace to the unmodified OpenZeppelin implementation. Each writes only the caller's own balance or allowance row, rejects zero addresses, and cannot reach the mint branch.\n- **Library trust gap.** I fetched the five OpenZeppelin files from the v5.0.2 tag and they are byte-identical to the vendored copies. Storage layout is the standard five-slot ERC20 layout and the source has no non-ASCII characters.\n- **Asymmetries.** The approve-replace versus transferFrom-consume race and the infinite-allowance non-decrement are standard ERC20 behaviour of the agreed design and are documented in the README. I recorded them as trust assumptions, not defects.\n- **Launch floor.** No fees, burns, hooks or exemption lists exist, so every launch flow moves exactly what it says. Constructor takes no arguments, matching the README.\n\n**One low finding.** The README tells reviewers to run the vendored-dependency checksum gate, and it fails: seven forge-std files do not match lib/SHA256SUMS. I diffed them against the upstream v1.9.7 tarball (whose hash matches THIRD_PARTY.md) and the differences are whitespace only, so nothing is tampered and no deployed bytecode is affected. The stated integrity guarantee is still false, and a reviewer cannot tell this benign reformat from a real edit to Vm.sol without doing that work. Fix is to restore the upstream bytes or regenerate the manifest.\n\n**Coverage record:** 8 rows, one per entry point plus the invariants above, all `holds` except the checksum row, which points to finding 1. Existing tests (30 unit, fuzz and invariant tests) build and pass under the pinned seed. No proof test was needed since nothing reached high severity.","treeHash":null,"usage":{"cachedInputTokens":736190,"inputTokens":290,"model":"claude-fable-5-1","outputTokens":12408,"runtime":"claude","turns":23,"wallClockMs":195204}},{"artifacts":[],"attempt":1,"bundleHash":"d4c569d805958f538923661062ef9ef7cb8d7eb2ec5dfb2d92d7e2ffc128d1f7","device":"49abac41ee211059","findings":[],"hash":"ef88ec103f1d2635b5250c7a316b71f6dee43a576ca6a21a90f85f08c72bbf59","nodeId":"955fbd9e-6f6b-40ca-9e56-ad2962b8e31d","outcome":"completed","summary":"Implemented [Keel](src/Keel.sol): 1,000,000,000 KEEL, 18 decimals, minted once to the deployer, with no further minting or admin controls.\n\nIncluded offline dependencies, deployment documentation, and success/failure tests.\n\nChecks passed:\n- `forge build`\n- `forge test`: 30 tests passed using the required seed\n- `forge fmt --check`","treeHash":"c4c10d0c0662add73761c9d4ad27b864b37f15d8","usage":{"cachedInputTokens":330112,"inputTokens":44095,"model":"gpt-6-astra","outputTokens":13941,"runtime":"codex","turns":4,"wallClockMs":351290}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"f47f953f8e35921e","findings":[{"citation":"resolved","description":"README.md (line 57) lists `sha256sum --check lib/SHA256SUMS` as one of the four build-and-check commands, and THIRD_PARTY.md line 5 states 'Upstream source files and licenses are unmodified; `lib/SHA256SUMS` records the SHA-256 of every vendored file.' Neither claim holds for the tree as committed at HEAD 595e063: seven files under lib/forge-std/src/ (StdJson.sol, interfaces/IMulticall3.sol, console.sol, Vm.sol, interfaces/IERC7540.sol, StdAssertions.sol, StdToml.sol) have different SHA-256 digests from the ones recorded in lib/SHA256SUMS. I confirmed the recorded digests are the genuine upstream forge-std v1.9.7 digests (tarball sha256 45157353ab49...ee94 as THIRD_PARTY.md states, and each of the seven upstream files hashes to the recorded value), and that the differences in the committed copies are whitespace/line-wrapping only (multi-line function signatures collapsed to one line, consistent with `forge fmt` at the project's line_length = 120 having been run over lib/). The vendored OpenZeppelin v5.0.2 files are byte-identical to upstream and all pass. Impact: forge-std is test-only and is not part of Keel's deployed bytecode, and the semantic content is unchanged, so there is no on-chain or economic effect. The defect is that the project's own stated provenance check is false for the delivered tree: a reviewer following the README gets a failed verification, and the 'unmodified' statement in THIRD_PARTY.md is inaccurate. Fix: either restore the seven forge-std files to their upstream bytes, or regenerate lib/SHA256SUMS from the committed files and amend THIRD_PARTY.md to say the forge-std sources were reformatted (not byte-identical) and that only the OpenZeppelin files are byte-identical to upstream. Not in the economics area, reported because it is a documented check that does not pass.","line":57,"path":"README.md","reproduction":"State: the repository at HEAD 595e063, clean working tree (git status reports nothing). Command, from the repository root as README.md line 57 instructs: `sha256sum --check lib/SHA256SUMS`. Expected (per README.md line 57 and THIRD_PARTY.md line 5): every line reports OK and the command exits 0. Actual: lib/forge-std/src/StdJson.sol: FAILED, lib/forge-std/src/interfaces/IMulticall3.sol: FAILED, lib/forge-std/src/console.sol: FAILED, lib/forge-std/src/Vm.sol: FAILED, lib/forge-std/src/interfaces/IERC7540.sol: FAILED, lib/forge-std/src/StdAssertions.sol: FAILED, lib/forge-std/src/StdToml.sol: FAILED, 'sha256sum: WARNING: 7 computed checksums did NOT match', exit status 1. Confirming it is the committed content and not a working-tree change: `git show HEAD:lib/forge-std/src/Vm.sol | sha256sum` gives a1b1c82924aecf0f38b53192fd1e801cccc1e1fd2ecd6b2301e4f4c4ab102a15 while lib/SHA256SUMS records 9068805b59ac1d0ea03a8fa1f15ae49c094e0c6c852a2500e0dd112f264b2cb1 for that path, which is the digest of upstream forge-std v1.9.7's src/Vm.sol. `diff` of each pair shows only line-wrapping differences (e.g. Vm.sol line 827: the four-line `getDeployment(...)` signature in upstream is one line in the vendored copy).","severity":"low","snippet":"sha256sum --check lib/SHA256SUMS","title":"Documented vendored-dependency checksum verification fails on the committed tree (7 forge-std files reformatted after lib/SHA256SUMS was recorded)"}],"hash":"f9d2c2b717c401c874d92697b56fcefd1654f53e1e4b62eb6cd956fb50a45c01","nodeId":"7f6d30de-1082-4e66-adfb-9ebf70b95875","outcome":"completed","summary":"Review complete. The findings file is written and validated, and the scratch test is removed so the tree holds only the review output.\n\n**Outcome:** Keel holds on every check in my area. One low-severity defect is recorded, outside the economics area but concrete.\n\n**What I covered**\n\n- **Economic Security:** the token has no external dependencies, oracles, callbacks, fees, burns, rebases, blacklists, pause or owner. Every launch flow was traced to exact wei: the swarm share to the distributor, the pool seed through the PoolManager, a buy and a sell back, the remainder, and a claim. All arrive whole and return true.\n- **Invariant:** supply is minted once to msg.sender under CREATE2, not tx.origin, and no selector can mint, burn or initialize afterwards. Sum of balances equals total supply under the project's 256x64 invariant run and my own 1024-run fuzz. Over-balance and over-allowance paths revert atomically.\n- **Flow Gap:** with no periphery calls and no exemption lists, there is no seam between execution, external behavior and intent. Runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.\n- **Static-analysis lead:** the large-literal warning is a compile-time constant equal to exactly 10^27. Not a defect.\n- **Dependencies:** the vendored OpenZeppelin v5.0.2 ERC20 files are byte-identical to upstream.\n\n**The one finding (low):** the README instructs running the vendored-file checksum check, and THIRD_PARTY.md says upstream sources are unmodified. On the committed tree that check fails for seven forge-std files. The recorded digests are the genuine v1.9.7 digests. The committed copies differ only by line wrapping, consistent with the formatter having been run over lib. forge-std is test-only, so there is no on-chain effect. The fix is to restore the upstream bytes or regenerate the sums and correct the wording.\n\n**Not reported, by design:** the inherent ERC-20 approve race, and tokens sent to the token's own address being stuck. Both are standard ERC-20 traits with no victim other than the sender.\n\n**Coverage record:** all three entry points are marked holds, plus four invariant and flow rows and one finding row for dependency provenance.","treeHash":null,"usage":{"cachedInputTokens":610126,"inputTokens":322,"model":"claude-fable-5-1","outputTokens":16264,"runtime":"claude","turns":27,"wallClockMs":252242}}],"verification":[{"checks":[{"durationMs":1229,"exitCode":0,"name":"build","output":"Compiling 27 files with Solc 0.8.26\nSolc 0.8.26 finished in 1.14s\nCompiler run successful!\n","passed":true},{"durationMs":4722,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 29 tests for test/Keel.t.sol:KeelTest\n[PASS] testFuzz_OverdrawnTransfersLeaveBalancesUnchanged(uint256,uint256) (runs: 1024, μ: 126959, ~: 127223)\nLogs:\n  Bound result 11\n  Bound result 20614\n\n[PASS] testFuzz_TransferFromHonorsAllowance(uint256,uint256) (runs: 1024, μ: 148551, ~: 160884)\nLogs:\n  Bound result 930752166867682497816651464\n\n[PASS] testFuzz_TransfersConserveSupply(address,uint256) (runs: 1024, μ: 92972, ~: 93240)\nLogs:\n  Bound result 579500218222210239836205126\n\n[PASS] test_AllowanceCanBeRevoked() (gas: 131240)\n[PASS] test_AllowancesAreIsolatedByOwner() (gas: 238653)\n[PASS] test_ApproveEmitsEventAndReplacesAllowance() (gas: 119467)\n[PASS] test_ApproveZeroSpenderReverts() (gas: 37596)\n[PASS] test_ConstructorEmitsSingleMintToImmediateDeployer() (gas: 26564)\n[PASS] test_DeployerCannotMoveAnotherHoldersBalance() (gas: 94913)\n[PASS] test_EntireSupplyCanMove() (gas: 75818)\n[PASS] test_FactoryDeploymentAndExactLaunchTransfers() (gas: 658428)\n[PASS] test_InfiniteAllowanceIsNotDecremented() (gas: 204221)\n[PASS] test_MetadataAndInitialSupply() (gas: 107650)\n[PASS] test_NoMintBurnOrAdministrativeEntrypoints() (gas: 710191)\n[PASS] test_RuntimeHasNoDangerousOpcodesAndFitsDeploymentLimit() (gas: 796500)\n[PASS] test_SelfTransferPreservesBalance() (gas: 51519)\n[PASS] test_SelfTransferStillRequiresBalance() (gas: 35808)\n[PASS] test_TransferEmitsEventAndReturnsTrue() (gas: 93582)\n[PASS] test_TransferFromConsumesFiniteAllowanceAndEmitsTransfer() (gas: 214613)\n[PASS] test_TransferFromOverAllowanceRevertsAtomically() (gas: 115736)\n[PASS] test_TransferFromOverBalanceRestoresAllowance() (gas: 178446)\n[PASS] test_TransferFromToSelfConsumesAllowanceWithoutChangingBalance() (gas: 105422)\n[PASS] test_TransferFromToZeroRestoresAllowance() (gas: 114155)\n[PASS] test_TransferFromZeroSenderReverts() (gas: 35385)\n[PASS] test_TransferOverBalanceReverts() (gas: 54882)\n[PASS] test_TransferToZeroRevertsEvenForZeroAmount() (gas: 71904)\n[PASS] test_UnapprovedSpenderCannotTransfer() (gas: 105257)\n[PASS] test_ZeroTransferFromEmptyAccountEmitsEvent() (gas: 73366)\n[PASS] test_ZeroTransferFromNeedsNoAllowance() (gas: 68896)\nSuite result: ok. 29 passed; 0 failed; 0 skipped; finished in 21.27ms (73.27ms CPU time)\n\nRan 1 test for test/Keel.invariant.t.sol:KeelInvariantTest\n[PASS] invariant_SupplyBalancesAndAllowancesMatchLedger() (runs: 256, calls: 16384, reverts: 0)\n\n╭-------------+--------------+-------+---------+----------╮\n| Contract    | Selector     | Calls | Reverts | Discards |\n+=========================================================+\n| KeelHandler | approve      | 5497  | 0       | 0        |\n|-------------+--------------+-------+---------+----------|\n| KeelHandler | transfer     | 5369  | 0       | 0        |\n|-------------+--------------+-------+---------+----------|\n| KeelHandler | transferFrom | 5518  | 0       | 0        |\n╰-------------+--------------+-------+---------+----------╯\n\nLogs:\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 451938503783963250498144716\n  Bound result 0\n  Bound result 3462\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 5\n  Bound result 5\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 127277318957164865685665779\n  Bound result 2\n  Bound result 158\n  Bound result 0\n  Bound result 1224\n  Bound result 0\n  Bound result 1653\n  Bound result 8\n  Bound result 0\n  Bound result 0\n  Bound result 3976\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 2\n  Bound result 1315\n  Bound result 66310908435974726795105736\n  Bound result 0\n  Bound result 0\n  Bound result 88\n  Bound result 0\n  Bound result 20000000000000000000\n  Bound result 0\n  Bound result 4717\n  Bound result 0\n  Bound result 127277318957164865685664556\n  Bound result 1651\n  Bound result 223253\n\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 4.62s (4.62s CPU time)\n\nRan 2 test suites in 4.62s (4.64s CPU time): 30 tests passed, 0 failed, 0 skipped (30 total tests)\n","passed":true},{"durationMs":35,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"Keel.approve(address,uint256)\",\"Keel.transfer(address,uint256)\",\"Keel.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":4,\"LICENSE\":21,\"README.md\":128,\"SECURITY.md\":36,\"THIRD_PARTY.md\":25,\"foundry.toml\":21,\"launch.json\":24,\"remappings.txt\":2,\"src/Keel.sol\":17,\"test/Keel.invariant.t.sol\":90,\"test/Keel.t.sol\":384},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"7816410587bc61afd59430a2376ebe78a7b74e4b01e43d106c524cb31117b456","verifiedTreeHash":"add71d0b833cc44fc01a9278f72393e76172283f","verifierVersion":"0.1.0+d952fceb"},{"checks":[{"durationMs":2113,"exitCode":0,"name":"build","output":"Compiling 29 files with Solc 0.8.26\nSolc 0.8.26 finished in 2.03s\nCompiler run successful!\n","passed":true},{"durationMs":9623,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 25 tests for test/KeelProperties.t.sol:KeelPropertiesTest\n[PASS] testFuzz_AllowanceIsCheckedBeforeBalance(uint256,uint256,uint256) (runs: 1000, μ: 181196, ~: 184473)\nLogs:\n  Bound result 10\n  Bound result 4\n  Bound result 2\n\n[PASS] testFuzz_AnyDeployerReceivesTheWholeSupply(uint256) (runs: 1000, μ: 32447, ~: 32539)\nLogs:\n  Bound result 36698854003323845325997\n\n[PASS] testFuzz_ApproveOverwritesAndIsIdempotent(uint256,uint256) (runs: 1000, μ: 208592, ~: 208623)\n[PASS] testFuzz_ExactAllowanceIsConsumedToZeroAndNoMore(uint256) (runs: 1000, μ: 177930, ~: 177733)\nLogs:\n  Bound result 530551475663655\n\n[PASS] testFuzz_FailedTransfersLeaveNoTrace(uint256,uint256,bool) (runs: 1000, μ: 137134, ~: 143960)\nLogs:\n  Bound result 942\n  Bound result 115792089237316195423570985008687907853269984665640564039457584007913129639934\n\n[PASS] testFuzz_HolderNeedsItsOwnAllowanceForTransferFrom(uint256) (runs: 1000, μ: 238907, ~: 238697)\nLogs:\n  Bound result 409346391899139749944932955\n\n[PASS] testFuzz_ManyHoldersConserveSupply(uint256,uint8) (runs: 1000, μ: 1930573, ~: 1191514)\nLogs:\n  Bound result 3\n  Bound result 793103192356346894501664565\n  Bound result 97438752809627332399460439\n  Bound result 9572092846762699073961131\n\n[PASS] testFuzz_OneBelowMaxAllowanceIsStillDecremented(uint256) (runs: 1000, μ: 140198, ~: 140575)\nLogs:\n  Bound result 409007345472966264489566798\n\n[PASS] testFuzz_RawCreationCodeDeploysAtPredictedAddressWithSupplyToFactory(uint64) (runs: 1000, μ: 1045902, ~: 1045887)\nLogs:\n  computeCreate2Address is deprecated. Please use vm.computeCreate2Address instead.\n\n[PASS] testFuzz_ReapprovalAfterPartialSpendReplacesRemainder(uint256,uint256,uint256) (runs: 1000, μ: 173046, ~: 174138)\nLogs:\n  Bound result 10\n  Bound result 3\n\n[PASS] testFuzz_RepeatedTransfersAccumulateUntilTheBalanceRunsOut(uint256) (runs: 1000, μ: 197697, ~: 197495)\nLogs:\n  Bound result 28121\n\n[PASS] testFuzz_SpendersAllowancesAreIndependent(uint256,uint256,uint256) (runs: 1000, μ: 204665, ~: 206798)\nLogs:\n  Bound result 10\n  Bound result 4854\n  Bound result 0\n\n[PASS] testFuzz_TransferFromToZeroReportsAllowanceFirst(uint256) (runs: 1000, μ: 135717, ~: 135473)\nLogs:\n  Bound result 852889189655501288154736041\n\n[PASS] testFuzz_TransferFromZeroOwnerAlwaysReverts(uint256) (runs: 1000, μ: 66166, ~: 66115)\n[PASS] testFuzz_TransferRoundTripIsNetZero(uint256) (runs: 1000, μ: 188063, ~: 188503)\nLogs:\n  Bound result 530551475663655\n\n[PASS] test_ApproveEmitsExactlyOneApprovalLog() (gas: 62590)\n[PASS] test_DeployerClaimingWrongSupplyIsRefused() (gas: 1522645)\n[PASS] test_InitialSupplyIsOneBillionWholeTokens() (gas: 38023)\n[PASS] test_NoCallerCanSetAnotherOwnersAllowance() (gas: 175017)\n[PASS] test_SameSaltCannotDeployTwiceFromTheSameFactory() (gas: 978381)\n[PASS] test_SeparateDeploymentsDoNotShareState() (gas: 179366)\n[PASS] test_TokensSentToTheTokenItselfAreAcceptedAndStranded() (gas: 132462)\n[PASS] test_TransferEmitsExactlyOneLog() (gas: 67850)\n[PASS] test_TransferFromEmitsOnlyTheTransferLog() (gas: 127398)\n[PASS] test_TransferToContractWithoutReceiveSucceeds() (gas: 166260)\nSuite result: ok. 25 passed; 0 failed; 0 skipped; finished in 281.59ms (2.92s CPU time)\n\nRan 29 tests for test/Keel.t.sol:KeelTest\n[PASS] testFuzz_OverdrawnTransfersLeaveBalancesUnchanged(uint256,uint256) (runs: 1024, μ: 127025, ~: 127229)\nLogs:\n  Bound result 27735145749653888103\n  Bound result 1000486750432721897054803789328827704152591581593618300548036962944105\n\n[PASS] testFuzz_TransferFromHonorsAllowance(uint256,uint256) (runs: 1024, μ: 147935, ~: 160884)\nLogs:\n  Bound result 684538814512219696009224236\n\n[PASS] testFuzz_TransfersConserveSupply(address,uint256) (runs: 1024, μ: 92932, ~: 93240)\nLogs:\n  Bound result 10450997433440426209724922\n\n[PASS] test_AllowanceCanBeRevoked() (gas: 131240)\n[PASS] test_AllowancesAreIsolatedByOwner() (gas: 238653)\n[PASS] test_ApproveEmitsEventAndReplacesAllowance() (gas: 119467)\n[PASS] test_ApproveZeroSpenderReverts() (gas: 37596)\n[PASS] test_ConstructorEmitsSingleMintToImmediateDeployer() (gas: 26564)\n[PASS] test_DeployerCannotMoveAnotherHoldersBalance() (gas: 94913)\n[PASS] test_EntireSupplyCanMove() (gas: 75818)\n[PASS] test_FactoryDeploymentAndExactLaunchTransfers() (gas: 658428)\n[PASS] test_InfiniteAllowanceIsNotDecremented() (gas: 204221)\n[PASS] test_MetadataAndInitialSupply() (gas: 107650)\n[PASS] test_NoMintBurnOrAdministrativeEntrypoints() (gas: 710191)\n[PASS] test_RuntimeHasNoDangerousOpcodesAndFitsDeploymentLimit() (gas: 796500)\n[PASS] test_SelfTransferPreservesBalance() (gas: 51519)\n[PASS] test_SelfTransferStillRequiresBalance() (gas: 35808)\n[PASS] test_TransferEmitsEventAndReturnsTrue() (gas: 93582)\n[PASS] test_TransferFromConsumesFiniteAllowanceAndEmitsTransfer() (gas: 214613)\n[PASS] test_TransferFromOverAllowanceRevertsAtomically() (gas: 115736)\n[PASS] test_TransferFromOverBalanceRestoresAllowance() (gas: 178446)\n[PASS] test_TransferFromToSelfConsumesAllowanceWithoutChangingBalance() (gas: 105422)\n[PASS] test_TransferFromToZeroRestoresAllowance() (gas: 114155)\n[PASS] test_TransferFromZeroSenderReverts() (gas: 35385)\n[PASS] test_TransferOverBalanceReverts() (gas: 54882)\n[PASS] test_TransferToZeroRevertsEvenForZeroAmount() (gas: 71904)\n[PASS] test_UnapprovedSpenderCannotTransfer() (gas: 105257)\n[PASS] test_ZeroTransferFromEmptyAccountEmitsEvent() (gas: 73366)\n[PASS] test_ZeroTransferFromNeedsNoAllowance() (gas: 68896)\nSuite result: ok. 29 passed; 0 failed; 0 skipped; finished in 281.98ms (396.86ms CPU time)\n\nRan 1 test for test/Keel.invariant.t.sol:KeelInvariantTest\n[PASS] invariant_SupplyBalancesAndAllowancesMatchLedger() (runs: 256, calls: 16384, reverts: 0)\n\n╭-------------+--------------+-------+---------+----------╮\n| Contract    | Selector     | Calls | Reverts | Discards |\n+=========================================================+\n| KeelHandler | approve      | 5497  | 0       | 0        |\n|-------------+--------------+-------+---------+----------|\n| KeelHandler | transfer     | 5369  | 0       | 0        |\n|-------------+--------------+-------+---------+----------|\n| KeelHandler | transferFrom | 5518  | 0       | 0        |\n╰-------------+--------------+-------+---------+----------╯\n\nLogs:\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 2216\n  Bound result 0\n  Bound result 296\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 95\n  Bound result 0\n  Bound result 0\n  Bound result 127277318957164865685665779\n  Bound result 0\n  Bound result 2478893115\n  Bound result 0\n  Bound result 1253\n  Bound result 0\n  Bound result 1604\n  Bound result 1\n  Bound result 0\n  Bound result 0\n  Bound result 1719639409\n  Bound result 739639098\n  Bound result 825\n  Bound result 2459279286\n  Bound result 5\n  Bound result 55\n  Bound result 92838381786592879742830376\n  Bound result 0\n  Bound result 3699\n  Bound result 100000000000000000000\n  Bound result 48\n  Bound result 5000000000000000000\n  Bound result 6\n  Bound result 67\n  Bound result 0\n  Bound result 104\n  Bound result 574\n  Bound result 223253\n\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 4.82s (4.82s CPU time)\n\nRan 1 test for test/KeelFailurePaths.invariant.t.sol:KeelFailurePathsInvariantTest\n[PASS]\nKeelFailurePathsInvariantTest invariants:\n[PASS] invariant_BalancesAndAllowancesMatchLedger\n[PASS] invariant_MetadataAndCodeAreImmutable\n[PASS] invariant_MovedVolumeIsBoundedByMoveCount\n[PASS] invariant_SupplyIsFixedAndFullyAccountedFor\n KeelFailurePathsInvariantTest invariants (runs: 256, calls: 16384, reverts: 0)\n\n╭------------------------+---------------------------+-------+---------+----------╮\n| Contract               | Selector                  | Calls | Reverts | Discards |\n+=================================================================================+\n| KeelFailurePathHandler | approve                   | 1177  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | approveThenOverdrawFrom   | 1125  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | approveUnlimited          | 1203  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | approveZeroSpender        | 1191  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | privilegedCall            | 1138  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | transfer                  | 1176  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | transferAll               | 1221  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | transferFrom              | 1165  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | transferFromAll           | 1222  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | transferFromOverAllowance | 1161  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | transferFromToZero        | 1112  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | transferFromZeroOwner     | 1157  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | transferOverdraw          | 1181  | 0       | 0        |\n|------------------------+---------------------------+-------+---------+----------|\n| KeelFailurePathHandler | transferToZero            | 1155  | 0       | 0        |\n╰------------------------+---------------------------+-------+---------+----------╯\n\nLogs:\n  Bound result 14091\n  Bound result 0\n  Bound result 0\n  Bound result 115792089237316195423570985008687907853269984665640564039457584007913129639934\n  Bound result 4000000000000000000\n  Bound result 0\n  Bound result 3\n  Bound result 125000000000000000000014088\n  Bound result 13866\n  Bound result 0\n  Bound result 0\n  Bound result 9891364347724\n  Bound result 249999999999999999999985909\n  Bound result 249999999999999999999985909\n  Bound result 499999999999999999999999996\n  Bound result 10487\n  Bound result 0\n  Bound result 10971\n  Bound result 0\n  Bound result 499999999999999999999999996\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 1966\n  Bound result 0\n  Bound result 0\n  Bound result 13806\n\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 9.53s (9.52s CPU time)\n\nRan 4 test suites in 9.53s (14.91s CPU time): 56 tests passed, 0 failed, 0 skipped (56 total tests)\n","passed":true},{"durationMs":38,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"Keel.approve(address,uint256)\",\"Keel.transfer(address,uint256)\",\"Keel.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":4,\"LICENSE\":21,\"README.md\":128,\"SECURITY.md\":36,\"THIRD_PARTY.md\":25,\"foundry.toml\":21,\"remappings.txt\":2,\"src/Keel.sol\":17,\"test/Keel.invariant.t.sol\":90,\"test/Keel.t.sol\":384,\"test/KeelFailurePaths.invariant.t.sol\":348,\"test/KeelProperties.t.sol\":444},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"e1a55349cf7e39a6802b7413bc67bd8d0d7521e0651f4bf011800f9989a15dbc","verifiedTreeHash":"b370131427ca484cd1881130c2b578edc177e6fe","verifierVersion":"0.1.0+d952fceb"},{"checks":[{"durationMs":1132,"exitCode":0,"name":"build","output":"Compiling 27 files with Solc 0.8.26\nSolc 0.8.26 finished in 1.05s\nCompiler run successful!\n","passed":true},{"durationMs":4431,"exitCode":0,"name":"test","output":"No files changed, compilation skipped\n\nRan 29 tests for test/Keel.t.sol:KeelTest\n[PASS] testFuzz_OverdrawnTransfersLeaveBalancesUnchanged(uint256,uint256) (runs: 1024, μ: 126959, ~: 127223)\nLogs:\n  Bound result 465045045618814936888311838\n  Bound result 1841061\n\n[PASS] testFuzz_TransferFromHonorsAllowance(uint256,uint256) (runs: 1024, μ: 148551, ~: 160884)\nLogs:\n  Bound result 684538814512219696009224236\n\n[PASS] testFuzz_TransfersConserveSupply(address,uint256) (runs: 1024, μ: 92972, ~: 93240)\nLogs:\n  Bound result 722395572008765493728064074\n\n[PASS] test_AllowanceCanBeRevoked() (gas: 131240)\n[PASS] test_AllowancesAreIsolatedByOwner() (gas: 238653)\n[PASS] test_ApproveEmitsEventAndReplacesAllowance() (gas: 119467)\n[PASS] test_ApproveZeroSpenderReverts() (gas: 37596)\n[PASS] test_ConstructorEmitsSingleMintToImmediateDeployer() (gas: 26564)\n[PASS] test_DeployerCannotMoveAnotherHoldersBalance() (gas: 94913)\n[PASS] test_EntireSupplyCanMove() (gas: 75818)\n[PASS] test_FactoryDeploymentAndExactLaunchTransfers() (gas: 658428)\n[PASS] test_InfiniteAllowanceIsNotDecremented() (gas: 204221)\n[PASS] test_MetadataAndInitialSupply() (gas: 107650)\n[PASS] test_NoMintBurnOrAdministrativeEntrypoints() (gas: 710191)\n[PASS] test_RuntimeHasNoDangerousOpcodesAndFitsDeploymentLimit() (gas: 796500)\n[PASS] test_SelfTransferPreservesBalance() (gas: 51519)\n[PASS] test_SelfTransferStillRequiresBalance() (gas: 35808)\n[PASS] test_TransferEmitsEventAndReturnsTrue() (gas: 93582)\n[PASS] test_TransferFromConsumesFiniteAllowanceAndEmitsTransfer() (gas: 214613)\n[PASS] test_TransferFromOverAllowanceRevertsAtomically() (gas: 115736)\n[PASS] test_TransferFromOverBalanceRestoresAllowance() (gas: 178446)\n[PASS] test_TransferFromToSelfConsumesAllowanceWithoutChangingBalance() (gas: 105422)\n[PASS] test_TransferFromToZeroRestoresAllowance() (gas: 114155)\n[PASS] test_TransferFromZeroSenderReverts() (gas: 35385)\n[PASS] test_TransferOverBalanceReverts() (gas: 54882)\n[PASS] test_TransferToZeroRevertsEvenForZeroAmount() (gas: 71904)\n[PASS] test_UnapprovedSpenderCannotTransfer() (gas: 105257)\n[PASS] test_ZeroTransferFromEmptyAccountEmitsEvent() (gas: 73366)\n[PASS] test_ZeroTransferFromNeedsNoAllowance() (gas: 68896)\nSuite result: ok. 29 passed; 0 failed; 0 skipped; finished in 22.39ms (72.54ms CPU time)\n\nRan 1 test for test/Keel.invariant.t.sol:KeelInvariantTest\n[PASS] invariant_SupplyBalancesAndAllowancesMatchLedger() (runs: 256, calls: 16384, reverts: 0)\n\n╭-------------+--------------+-------+---------+----------╮\n| Contract    | Selector     | Calls | Reverts | Discards |\n+=========================================================+\n| KeelHandler | approve      | 5497  | 0       | 0        |\n|-------------+--------------+-------+---------+----------|\n| KeelHandler | transfer     | 5369  | 0       | 0        |\n|-------------+--------------+-------+---------+----------|\n| KeelHandler | transferFrom | 5518  | 0       | 0        |\n╰-------------+--------------+-------+---------+----------╯\n\nLogs:\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 451938503783963250498144716\n  Bound result 0\n  Bound result 3462\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 5\n  Bound result 5\n  Bound result 0\n  Bound result 0\n  Bound result 0\n  Bound result 127277318957164865685665779\n  Bound result 2\n  Bound result 158\n  Bound result 0\n  Bound result 1224\n  Bound result 0\n  Bound result 1653\n  Bound result 8\n  Bound result 0\n  Bound result 0\n  Bound result 3976\n  Bound result 0\n  Bound result 0\n  Bound result 1\n  Bound result 2\n  Bound result 0\n  Bound result 66310908435974726795105736\n  Bound result 0\n  Bound result 2661\n  Bound result 0\n  Bound result 0\n  Bound result 20000000000000000000\n  Bound result 2\n  Bound result 0\n  Bound result 127\n  Bound result 38952160387377286759185329\n  Bound result 1651\n  Bound result 223253\n\nSuite result: ok. 1 passed; 0 failed; 0 skipped; finished in 4.34s (4.34s CPU time)\n\nRan 2 test suites in 4.34s (4.36s CPU time): 30 tests passed, 0 failed, 0 skipped (30 total tests)\n","passed":true},{"durationMs":35,"exitCode":0,"name":"source-index","output":"{\"v\":1,\"entryPoints\":[\"Keel.approve(address,uint256)\",\"Keel.transfer(address,uint256)\",\"Keel.transferFrom(address,address,uint256)\"],\"files\":{\".gitignore\":4,\"LICENSE\":21,\"README.md\":128,\"SECURITY.md\":36,\"THIRD_PARTY.md\":25,\"foundry.toml\":21,\"remappings.txt\":2,\"src/Keel.sol\":17,\"test/Keel.invariant.t.sol\":90,\"test/Keel.t.sol\":384},\"excluded\":[\"lib/\",\"node_modules/\"],\"truncated\":false}","passed":true},{"durationMs":388,"exitCode":0,"name":"slither","output":"slither: no results at low impact or above","passed":true},{"durationMs":280,"exitCode":0,"name":"aderyn","output":"[low] large-numeric-literal at src/Keel.sol:10: Large Numeric Literal","passed":true}],"detail":"all checks passed","evaluation":"checks","profile":"foundry","status":"accepted","submissionHash":"ef88ec103f1d2635b5250c7a316b71f6dee43a576ca6a21a90f85f08c72bbf59","verifiedTreeHash":"c4c10d0c0662add73761c9d4ad27b864b37f15d8","verifierVersion":"0.1.0+d952fceb"}]}