Implemented both contracts, on-chain SVG artwork, vendored dependencies, and deployment documentation.

Verified: 60 tests pass with the supplied seed, including clean offline checks. forge build and forge fmt --check pass. Both contracts are under 24 KB.

Owner configuration and operational responsibilities are documented in README.md.

I found no defects I can back with a concrete failing input in the permission model of KeelNotes. .imd-findings.json holds an empty findings list and one coverage row for each of the 19 listed entry points, all marked holds, plus a row for the liability invariant. I changed no project files, and the existing 60 tests all pass.

I went through the Access Control, Asymmetry and Trust Gap guides in that order:

• Access control:
  • Every owner function is onlyOwner, and setKeelToken can only be called once.
  • Ownership is handed over in two steps, and the constructor takes the owner explicitly, so it isn't trapped at the factory.
  • redeem and upgradeToGold require the caller to be the note's owner, not just an approved operator.
  • readTokenSymbol can only be called by the contract itself.
  • There is no receive, fallback or initializer, and no public burn: transfers to the zero address revert, so redeem is the only way to burn a note.
• Asymmetry:
  • Mint sets the note's reward starting point (its checkpoint); upgrade settles earnings first, including sub-wei remainders.
  • Redeem clears the note before paying and removes its weight.
  • Burning never decrements goldCount or clears usedBackingToken, so Gold slots and backing tokens stay used.
• Trust gap:
  • Mint passes are tied to the sender, the chain and this contract.
  • rescueToken refuses IMD, so the owner can't take funds owed to notes.
  • The owner's other powers (setArt, setPassSigner, renouncing ownership) don't touch IMD. I've noted them as trust assumptions rather than findings.
  • Rounding in reward accounting always favours the contract, so the IMD balance stays at or above what it owes.

Static-analysis leads I checked and dropped:

• Strict equalities (goldCount == MAX_GOLD, amount == 0, received == 0): these are intended cap and zero checks.
• Calling the KEEL token before updating state in mint: that token is set by the owner, and every function that moves value shares one reentrancy lock.
• _mint instead of a safe mint: the brief asks for _mint.

What I didn't check:

• I couldn't confirm that the real KeelVault's project() return layout matches the interface. It only matches what the brief describes.
• If the caller of upgradeToGold sends too little gas, the symbol read fails and "?" is engraved permanently. Only the note owner, who is also the creator, can trigger this, so I didn't report it.
• I didn't review the art contract beyond reading it once.

I found one defect (medium) in the control-flow review of KeelNotes and KeelNoteArt. I didn't modify any project file. The results are in .imd-findings.json: 1 finding and 22 coverage rows, one for each of the 19 entry points plus 3 for the invariant and the helper code.

Finding 1 (medium): IMD sent straight to the contract can go to notes that didn't exist when it arrived (src/KeelNotes.sol:225, creditSurplus)

• Cause: IMD transferred directly only counts as rewards when someone calls creditSurplus(). It is then split by the total weight at that moment. mint, upgradeToGold and redeem all change the total weight without crediting that waiting IMD first.
• Result: a note minted later shares in IMD that arrived before it existed, which breaks "later notes get no earlier rewards". A note upgraded to Gold collects that IMD at weight 5 instead of 1. Anyone who sees a large direct transfer can mint or upgrade first and then call creditSurplus().
• Reproduction, confirmed by a test that fails on the current code:
  • Alice mints, 100 IMD is sent directly, Bob mints, then creditSurplus() is called. Expected 100/0; actual 50/50.
  • Alice and Bob both hold Standard notes, 120 IMD is sent directly, Bob upgrades to Gold, then creditSurplus() is called. Expected 60/60; actual 20/100.
• Proposed fix: a private step that credits any IMD above liabilities to the current notes, called before the weight changes in mint, upgradeToGold and redeem. It does nothing when no notes exist or nothing is waiting.
• The full test file is in the finding's proof field.

Checked and holding:

• mint: the signed pass binds the caller, the deadline, a non-zero minKeel and the live Keel balance. One mint per wallet and the 1111 cap hold.
• upgradeToGold: the owner, creator, launched-token, used-token and 111-Gold checks hold, and rewards are settled before the weight changes.
• fund: it credits the IMD actually received, and rounding favours the contract.
• redeem: only the owner can call it, it reverts when nothing is pending, state is updated before payment, and solvency is re-checked after paying.
• Other entry points: rescueToken refuses IMD. The owner setters and the transfer and approval functions behave as intended.
• Invariant: IMD balance ≥ liabilities ≥ total pending holds on every path that changes liabilities.
• Helper code:
  • The symbol reader returns "?" for reverting, malformed, too-long or gas-heavy symbols.
  • The decoded tokenURI JSON and SVG both parse. The text matches the brief ("No. 0001 / 1111", "BACKS $ABC123", "HOLDS 12.34 IMD").

Static-analysis leads I rejected:

• Strict equality: each counter only moves by 1, so == can't be skipped.
• State change after an external call: those calls are read-only and the functions are nonReentrant.

Trust assumptions, not defects: the owner can replace the art contract or renounce ownership, which freezes configuration and means minting can never be reopened.

Left out: an upgrader who supplies too little gas gets "?" as their engraved symbol. Only the note's owner, who is also the token's creator, can trigger that, so it only harms themselves.

The scratch test folder has been removed.

Created launch.json with KeelNoteArt first, then KeelNotes using ["$owner", "$contract:KeelNoteArt"].

Verified manifest structure and constructor ABIs. forge build succeeded; all 60 tests passed with the supplied fuzz seed.

Only launch.json changed.

I added two test files and found no defects in KeelNotes, so I wrote no .imd-findings.json. forge build succeeds, and the full forge test run with the verifier's fuzz seed passes: 71 tests in 7 suites, 0 failed. The two files are not committed, since that wasn't asked for.

The existing suite already covered the brief's checklist. Its one invariant suite only made valid calls, and with 16 wallets it could never reach the 111-Gold cap. My additions close those gaps:

test/AdversarialInvariant.t.sol is an invariant suite over random call sequences.

• Setup: it mints 140 notes and upgrades 100 to Gold, so runs cross the Gold cap. I checked with a throwaway probe that runs do reach 111 Gold and do include redemptions, so the cap and redeem checks aren't empty.
• Valid actions: mint, fund, direct IMD transfer plus creditSurplus, upgrade (singly and in batches), transfer, redeem, time jumps, and depositing and rescuing an unrelated token. Redeem must pay exactly the pending amount; upgrade and transfer must leave pending unchanged.
• Hostile actions: each must revert with the specific expected error:
  • redeem by a stranger, by an approved operator, or of a burned note
  • a second mint by the same wallet, or a pass used by a different wallet
  • upgrades with an already-used backing token, by a non-creator, or with an unlaunched token
  • upgrades past the cap, or of a note already Gold
  • rescuing IMD, a rescue by a non-owner, or sending ETH
  • funding more than the caller has
• Invariants checked after every call:
  • The IMD balance equals everything credited plus uncredited, minus everything paid.
  • The contract's recorded debt equals credits minus payouts, and covers every note's pending amount.
  • Rounding loss stays at most one wei per credit, per live note and per redemption.
  • Gold count is at most 111 and never drops when a Gold note burns.
  • Total weight equals one per live Standard note plus five per live Gold note.
  • Supply figures stay consistent, the contract holds no ETH, and rescue moves only the amount it states.

test/EdgeFuzz.t.sol adds stateless fuzz and unit tests:

• Mint pass: passes signed by any other key are refused; changing any signed field is caught; the wallet's current Keel balance must meet the minimum and minting takes none of it; expired passes are refused.
• Rewards: the 1:5 split holds exactly for every mix of Gold among 8 notes, paying out at most the amount funded and losing at most one wei per note. A note minted later earns nothing from earlier funding and can't redeem zero.
• Edges: the zero address or the note contract itself can't be a backing token. Redeeming a Gold note removes 5 weight but keeps its cap slot. Closing minting blocks a valid pass. Minting can't reopen once the pass signer is revoked.

One harness quirk to know about: with via_ir on, block.timestamp can be re-read after vm.warp, which made an early version of the expiry test fail for no real reason. That test now uses fixed timestamps; it was never a contract bug.

The review is complete and the findings file is written and validated. Nothing tracked in the tree was changed; only .imd-findings.json and the scratch tests under test/scratch/ were created.

Result: the reward math holds. I traced every division, carry and boundary in the accumulator against the Math Precision, Boundary and Numerical Gap guides and found no value-leaking defect.

• Accumulator and fraction carry are exact. Each credit adds floor(received·1e36 / totalWeight), each note takes floor(delta·weight / 1e36) plus a sub-wei fraction that is carried across the Standard-to-Gold upgrade and across transfers. A scratch fuzz compares every note's payout to the exact rational entitlement and matches to the wei, and the project's own invariant suite passed at 512 runs by depth 200.
• Solvency is guaranteed by construction. Per credit, the sum of weighted increments never exceeds the received amount, so liabilities always cover the sum of pending claims. Locked rounding dust is bounded at under 1 wei per credit or redemption, which the code documents as intended.
• Boundaries behave. The 1111 and 111 caps use strict equality but only ever increment by one, the deadline is inclusive, and the art formatter truncates correctly at decimals 0, 1, 2 and 77 through 80 where the power-of-ten arithmetic sits at the edge of uint256.
• Live dependencies checked on mainnet. IMD has 18 decimals and exposes decimals(), so tokenURI works; the factory and vault have code.

Reported findings (all in .imd-findings.json with reproductions):

1. Low. setKeelToken is one-shot but accepts any non-zero address. Pointing it at an address without code makes every mint revert forever with no repair path. Reproduced in a scratch test.
2. Info. The accumulator reverts permanently once cumulative weighted credits reach about 1.16e41 base units. With IMD's supply near 4.17e24 this is roughly 16 orders of magnitude out of reach, so it is recorded only for completeness.
3. Info. The live vault's project() returns 15 ABI words against the 14-field interface. The decoder tolerates the extra word (confirmed with a mock), but without archive log access I could not confirm that the creator really sits in word 0. This is a note for the judge, not a defect.

Coverage: all 19 listed entry points have rows, plus four invariant rows. No entry point was left unreached. Out of area but worth noting for the economics specialist: a project creator can front-run a visible fund or creditSurplus with upgradeToGold to capture a 5x share of that credit, which the brief's rules permit.

The review is complete and the findings file is written and verified against the tree. Nothing tracked in the repository was modified.

Outcome: no accounting defect found in the reward economics. The accumulator math, upgrade settlement, redemption ordering and the balance >= liabilities >= sum(pending) invariant all hold under the project suite, my scratch tests, and the live token behaviour. Four items are recorded in .imd-findings.json, two low and two informational:

• Low. Pre-mint IMD is swept by the first minter. fund() refuses to run while no note exists, so the only way to seed rewards early is a direct transfer. That surplus goes to whoever holds weight when creditSurplus() is called, and the first minter can mint, credit and redeem in one transaction and take all of it. Reproduced in a scratch test.
• Low. A note sent to the collection contract with transferFrom is dead weight forever. It can never be redeemed, keeps earning its share of every later funding, and that IMD cannot be rescued. Reproduced in a scratch test. A one-line _update guard fixes it.
• Info. The live KeelVault returns 15 words from project(), not the 14 the brief and interface declare. I queried mainnet for the two launched tokens. The creator is still word 0 and Solidity tolerates the extra trailing word, so Gold upgrades work. The interface and README should be corrected before anyone tightens the decode.
• Info. minKeel is a same-block balance snapshot. One KEEL balance or a flash loan satisfies any number of passes, so the pass signer is the only real sybil gate on free reward-earning mints. This matches the brief and is recorded as a trust assumption.

Live dependency checks. IMD is a verified LayerZero OFT ERC-20 with plain transfers and no fee, pause or blacklist. The factory's isLaunched matches its verified ABI. The vault is unverified, so its layout was inferred from on-chain calls against launched tokens.

Coverage. All 19 entry points have a row, plus rows for the three economic invariants, locked dust, and accumulator overflow. No entry point was left unreached. Static-analysis leads were all checked: the strict equalities are correct sentinel checks, and the flagged reentrancy in mint is a static balance read before state changes under a guard.

All snippets match their lines, and git shows nothing changed outside the ignored findings file and scratch directory. The review is complete.

Outcome: the findings file at .imd-findings.json holds five findings and a 23-row coverage record covering all 19 entry points plus four invariants. The existing test suite passed 70 of 71 tests under a random seed, and the one failure is a test-harness defect reported below, not a contract defect.

Findings kept, after reproduction:

• Medium, surplus timing. Direct IMD transfers are credited to whichever weights are live when someone calls creditSurplus, not when the IMD arrived. A note minted later takes a share, a Gold upgrade collects at weight 5 retroactively, and a holder who redeems before the credit forfeits their share. This merges the audit_flow finding and the audit_economics pre-mint sweep, which share one root cause. I attached a self-contained proof with inline mocks that fails on the current code in three cases.
• Low, dead weight. A note moved to the KeelNotes contract with transferFrom can never be redeemed, so its weight and all future share of funding are locked forever. Reproduced in a scratch test.
• Low, one-shot token setting. setKeelToken takes any non-zero address and can never be corrected, so a typo or an address without code bricks every mint permanently. Reproduced in a scratch test.
• Low, test suite flakiness. The adversarial invariant handler adds the loop index to a fuzzed seed with checked arithmetic, so a max-uint256 seed panics and both invariants fail under any seed except the README's pinned one. Confirmed by running with the pinned seed after clearing the failure cache, which passes, and with two random seeds, which fail.
• Info, live vault layout. The mainnet KeelVault returns 15 words where the interface and brief declare 14. I confirmed this with a live call. The creator sits in word 0 and Solidity ignores trailing data, so upgradeToGold works as specified. The two specialist notes on this were merged.

Dropped: the accumulator overflow ceiling note, which needs roughly 2.8e16 times the IMD supply, and the minKeel snapshot note, which is exactly the behaviour the brief specifies.

Independent pass: I traced mint, Gold upgrade, funding, redemption, rescue, ownership and the art renderer against the Pashov and entry-point checklists. Signature binding, replay protection, checks-effects-interactions in redeem, the balance-versus-liabilities invariant, the contract sizes and the manifest all hold. No new contract-level defect appeared beyond those listed.

All four findings reproduced and are fixed. The reviewer's proof now passes, the full suite passes with the verifier's fuzz seed, and a clean offline copy builds, tests and formats cleanly.

Medium, surplus timing (held to the proof). Reproduced with the reported values. The accumulator was stale across weight changes: direct IMD was divided by whatever weights existed when someone called creditSurplus(). Fix in src/KeelNotes.sol:

• A private surplus sync credits the uncredited balance to the live weights. Mint calls it before adding weight, upgrade before settling, redeem before computing the payout.
• The public credit function runs the same sync and is now a harmless no-op when nothing is uncredited, which the proof requires.
• IMD that arrives while no note is live is folded into the reserve and emits SurplusStranded. It is never paid to the first minter nor to anyone. The README says not to send IMD before the first mint.
• New file test/SurplusSync.t.sol covers the four reported cases, both stranding cases, shortfall behaviour and a seeded fuzz. The invariant handler now credits donations at the same moments and tracks stranded IMD.

Low, transfer to the collection. Reproduced. An _update override now rejects any transfer whose recipient is the collection. Tested for both transfer paths and an approved operator.

Low, one-shot Keel token with no validation. Reproduced. The setter now refuses an address without code or whose static balanceOf probe fails, and stays unset so the owner can retry. Tested with a no-code address and a contract lacking the function.

Info, 15-word vault answer. Confirmed with a live mainnet call. The 14-word struct was kept on purpose because it decodes both layouts, and lengthening it would break upgrades against a vault answering exactly 14 words. Added a comment on the struct, a 15-word mock vault and a Gold upgrade test against it.

Results:

The answers to all four findings are in .imd-responses.json. README, docs/SECURITY.md and docs/VALIDATION.md are updated. Nothing is committed, and no launch or blocked file was written.

The manifest in the working tree is correct and complete, so no change is needed.

What I verified

• launch.json has exactly the keys kind, contracts and notes, with kind set to evm_contracts.
• The contract order matches constructor dependency: KeelNoteArt first with no arguments, then KeelNotes with $owner and $contract:KeelNoteArt. That matches the KeelNotes constructor signature (address owner_, address art_) at src/KeelNotes.sol:99, and KeelNoteArt has no constructor.
• Both names are unique Solidity identifiers under 32 characters. Notes are a single string of 591 characters.
• Ownership goes to $owner through Ownable2Step, never to the factory or IMD, which satisfies the protected owner check.
• Both runtimes stay under the EIP-170 limit the protected deployment test enforces.

Checks run

forge build succeeds with only lint warnings. forge test with the verifier's fuzz seed passed all 71 tests across 6 suites. The working tree is clean, so no file other than the previously accepted launch.json is touched.

The revision brief listed no concrete findings against the manifest, and rewriting an accepted, correct file would only give the reviewer a different artifact to read. The deliverable is the existing launch.json.

The finding reproduced and is fixed. The only changed file is the adversarial invariant handler, and the response file answers the reviewer.

What I found

• The reported overflow is real. The handler's upgradeMany looped over seed + i with checked arithmetic, so a max-uint256 seed panicked before any contract call, and the suite only passed under the pinned seed.
• The handler was also stale against the merged contract. The other contributor's accepted revision made mint, upgrade and redeem credit directly sent IMD first, and turned creditSurplus into a silent no-op. A random seed shrank to a donate followed by a redeem, where my handler expected a NoRewards revert but the contract correctly paid the note's share. The contract behaves as the README now documents, so this was a harness defect, not a contract bug.

What I changed in test/AdversarialInvariant.t.sol

• Wrapped the seed increment in unchecked, since the seed only picks a note id by modulo.
• Added a ghost surplus sync with credited, stranded and uncredited counters, applied at the same moments the contract syncs.
• The creditSurplus action now asserts a no-op changes neither liabilities nor the accumulator when nothing is uncredited.
• The redeem action handles the donate-only case with a try/catch that accepts only a NoRewards revert, checks the note survives a revert, and otherwise requires a positive payout at least equal to the previously visible pending amount.
• The upgrade action requires exact settlement when nothing is uncredited and no loss otherwise.
• The conservation invariant now includes stranded IMD on both sides.

Verification

No contract defects surfaced, so no findings file was written. The reviewer's finding is answered as fixed in the responses file.

The review is complete. The findings file is written and validated, the scratch directory is removed, and the working tree is clean apart from the excluded findings file.

Outcome: every earlier finding is confirmed fixed, and nothing new blocks the launch.

• Medium, stale accumulator across weight changes (fixed). The private sync now runs at the start of mint, upgradeToGold and redeem, before any weight or payout is computed, and creditSurplus is a no-op when nothing is uncredited. Both attached proofs pass on the revised code. The author's SurplusSync tests cover all four cases I reported, and my own mixed sequence of donations, a Gold upgrade, a transfer, a fund and three redemptions paid every unit to the weights live at arrival and left exactly one unit of rounding dust in reserve.
• Low, note transferred to the collection (fixed). The _update override rejects a recipient equal to the collection on transferFrom and both safeTransferFrom overloads, including by an approved operator. Verified with my own scratch test.
• Low, setKeelToken bricking mint (fixed). The setter refuses an address without code or whose static balanceOf fails or returns under 32 bytes, and leaves the token unset so the owner can retry. Once-then-permanent is preserved.
• Low, invariant handler overflow (fixed). The increment is wrapped in unchecked. The full suite of 82 tests, including both invariant campaigns with zero reverts, passes under an unpinned fuzz seed.
• Info, 15-word vault layout (addressed). The interface carries a comment not to tighten decoding, and a 15-word mock vault test exercises the creator check.

One informational note recorded. The pre-mint path now strands IMD into liabilities permanently instead of handing it to the first minter. This is the option I offered, it is documented in the README and security notes, and no holder can be harmed by it, but the locked IMD is unrecoverable because the brief forbids rescuing IMD. It does not reopen the work.

The coverage record answers all 19 entry points as holding, with mint pointing at the informational note, plus rows for the solvency invariant and the launch manifest. Both contracts are well under the runtime size limit and the manifest's constructor arguments match the declarations in order.