The VETERANS contracts stage is complete and committed as 0f497f5. A fresh clone builds, passes all 60 tests with the verifier's fuzz seed in an empty environment, and passes forge fmt --check.

What was built (all in src/, ABIs in docs/abi/):

• VeteransNFT: ERC721C (Limit Break v4) with mint(uint256 nonce), the wallet-bound keccak hash check, sequential ids, ten difficulty epochs, fixed 0.069 IMD price split 65/20/10/5 in the same transaction, firstSeen tracking, ERC-2981 at 690 bps to the claim pool, and on-chain tokenURI via the renderer.
• VeteransStaking: no-lock staking. Weight is staked count times the age multiplier (1.0x to 8.0x per the brief's table). Rewards use a 1e27 accumulator and are settled before any weight change. No owner.
• VeteransClaimPool: receives royalties as ETH and the 20% mint share as IMD, pushes the treasury's 0.9% (with a pull fallback if the push fails), and lets stakers claim both assets by weight. No owner or admin function.
• VeteransRenderer: stateless pixel-art SVG and OpenSea JSON derived from the winning hash, with an Overclocked tier at 1 in 24 and a numeric rarity score.

Decisions you should know about

• The brief's epoch arithmetic does not close: ten epochs of 333 is 3,330, not 3,333. The tenth epoch runs to the supply cap (336 mints) so there are exactly ten epochs. Documented in the README.
• The IMD token address is not in the brief, so the owner sets it once after launch via configure(imd, staking, claimPool), which also wires the sibling contracts (forward references are not possible in the manifest). Minting reverts with a clear error until then. The call is one-shot.
• The "20% converted or held as ETH" clause is implemented as held: the pool distributes the IMD alongside royalty ETH rather than adding a DEX dependency.
• Limit Break's v4 default validator has code on Robinhood Chain (verified with cast code against two public RPCs). Staking transfers bypass it by design since ownership never changes. The owner must still set the collection's security policy and operator whitelist on the validator after launch. These owner powers, and the renderer swap until frozen, are listed as trust assumptions in the README.
• Difficulty starts at 20 leading zero bits and adds one bit per epoch. Both are named constants, flagged as my choice.

Not in this stage: the frontend, the launch manifest, and deployment itself, which belong to later steps. The README's "After launch" section lists the owner's three post-deployment actions. The contracts hold user funds and still need the independent adversarial review the workflow schedules.

Created launch.json with four contracts in dependency order, matching constructor ABIs and $owner.

Manifest validation passed. forge build succeeded; all 60 tests passed with the required fuzz seed.

Only launch.json is changed for submission. Notes preserve existing implementation conflicts, including unsupported post-deployment configuration.

I wrote 4 findings to .imd-findings.json: 1 high, 2 medium and 1 low. It also has a coverage row for all 28 listed entry points, plus two rows for invariants I checked. The proof test for the high finding fails on the current code as intended. I deleted the scratch test afterwards, and no tracked file changed.

Findings

1. High: the owner can send most fees and all royalties to contracts they choose (src/VeteransNFT.sol:111). The staking contract, claim pool and IMD token are chosen by the owner in a configure call after launch, not fixed at deployment. Its checks only ask the supplied contracts what nft() and staking() return, and any contract the owner deploys can give the expected answers. Once accepted:

   • 65% + 20% of every mint fee goes to the owner's contract;
   • the whole 6.9% royalty goes there too, including the treasury's 0.9%;
   • transfers to or from it skip royalty enforcement.

   This conflicts with the brief's "no admin keys that can change the economics". The proof test deploys a look-alike contract and configure accepts it.

2. Medium: royalties paid in ERC-20 tokens are stuck forever in the claim pool (src/VeteransClaimPool.sol:73). The pool can only hand out native ETH and IMD that the NFT contract tells it about. Marketplaces often pay royalties on accepted offers in WETH. Those payments, both the stakers' 6.0% and the treasury's 0.9%, can never be moved.

3. Medium: the owner can switch off royalty enforcement (src/VeteransNFT.sol:22). setTransferValidator(address(0)) comes from Limit Break's ERC721C base contract and only the owner can call it. After that call, every transfer is royalty-free. No security policy is set at deployment either; the README leaves it as a manual step for the owner. The README lists this as a trust assumption, but the brief requires royalties to be enforced on-chain.

4. Low: rewards held back while nobody is staked can be stranded (src/VeteransStaking.sol:170; same mechanism in the claim pool's notifyImd). Rewards that arrive with nothing staked are carried over until the next mint. If nobody is staked during the final mints, that carry-over is never paid out once all 3,333 are minted.

What I checked that holds:

• The fee split sums exactly to the 0.069 IMD price in wei.
• The burn fallback works.
• The 90/690 treasury share of each ETH royalty is correct.
• The wallet-age multiplier day boundaries match the brief.
• Rewards are settled at the old weight before any weight change.
• The claim pool's weights stay in step with the staking contract's.
• Claim and unstake paths are protected against re-entry.
• Moving tokens into and out of staking doesn't let anyone dodge royalties.

Leads I did not report:

• Stale multipliers: a wallet keeps its old multiplier until someone calls refresh. Anyone can call it, and the README documents this.
• Gaming wallet age: wallets can be stamped early to build up age. That follows from how the brief defines age.
• Gas-limited royalty payments: royalties sent with only 2,300 gas fail. The README documents this.

There is no launch.json in the tree yet, so I did not review a manifest.

Review complete. The findings file is written at .imd-findings.json with 4 findings and 33 coverage rows; no source file was changed.

Outcome. The math in this project holds up. The fee split, royalty split, reward accumulators, weight downcasts, epoch arithmetic, difficulty targets and the multiplier table were all traced with concrete values and none leaks or overflows. I found no critical, high or medium defect in my area, so no proof tests are attached. The four findings are:

1. Low, src/VeteransRenderer.sol:134. The renderer computes the Epoch attribute without the clamp the NFT applies, so tokens 3331 to 3333 report Epoch 11 while the NFT, its events and the README place them in epoch 10. Reproduced: tokenJSON(3331, …) contains "Epoch"…"value":11.
2. Low, src/VeteransRenderer.sol:48. roll % 100 on a byte is biased. Background index 0 is rolled 120 of 256 times (46.9% versus the declared 40%) and index 4 only 10 of 256 (3.9% versus 5%), so the on-chain rarity score, which uses the declared odds, misranks actual rarity.
3. Low, src/VeteransClaimPool.sol:86. donate() and receive() accept zero value and still fold ethCarryOver into the distribution. The first staker can call donate{value: 0}() right after staking and take the entire carry (60 ETH in the reproduction) before anyone else stakes.
4. Info, src/VeteransClaimPool.sol:162. Double round-down strands dust while totalEthToStakers counts it as distributed. With weight 30 and a 100 wei donation the staker claims 99 wei and 1 wei is stuck forever.

Checks run. forge build succeeded. The existing 60 tests pass. My scratch file test/scratch/MathAudit.t.sol confirmed all four reproductions and passes alongside the suite (64 tests total). The protected harness tests could not be run here because they require verifier environment variables and a floor/OwnerChecks.sol that is not in the tree. Slither and Aderyn were not run; I examined the supplied static-analysis lines as leads. The reentrancy and calls-in-loop leads on staking are guarded by nonReentrant and trusted callees, the strict equality on firstSeen == 0 is a safe sentinel, and the renderer's uninitialized local is zero-initialized by the compiler, so none became a finding.

Coverage. All 28 listed entry points have a row. 26 hold, VeteransClaimPool.donate() carries finding 3, and three invariant rows plus two renderer rows record the checks on fee-split exactness, pool and staking weight equality, no over-distribution, and the two renderer findings. One assumption I could not verify from here: MINT_PRICE = 0.069 ether presumes the IMD token has 18 decimals, as the README states. Nothing in the tree or the pinned reads confirms the live token's decimals, so that remains an open item for whoever configures the token after launch.

The findings file is valid, every snippet matches its cited line, and the working tree has no tracked changes. The review is complete.

Outcome. No critical or high defects in the access-control, trust-gap or asymmetry lenses. The permission model is tight: every privileged entry point is guarded by the right party, the staking/pool weight mirror and reward conservation held under a randomized fuzz, and staking from inside the mint callback leaves consistent state. Five findings are recorded in .imd-findings.json, each with a scratch test that reproduces it.

Findings, most severe first:

• Medium. Royalties paid in an ERC-20 (WETH-denominated sales on Seaport-style markets) land in the claim pool with no intake, no sweep and no admin, so that share is lost forever. The condition depends on which marketplaces exist on Robinhood Chain, which the tree cannot show.
• Low. The validator bypass for transfers into the staking contract applies to any approved operator. An operator the security policy blocks can still plain-transfer a holder's token into staking, where nobody is recorded as staker and it is unrecoverable.
• Low. The renderer reports Epoch 11 for tokens 3331 to 3333, while the contract mints them in epoch 10 and the brief fixes exactly ten epochs. Outside my area, reported because it is verified.
• Info, trust assumption. Owner-chosen validator plus auto-approval gives that validator custody of every token, including staked ones, and the staking ledger then desyncs. No unprivileged trigger. The README lists the two powers but not their combined effect.
• Info. Renouncing ownership before the one-time configure bricks minting permanently. Owner error only.

Coverage. All 28 listed entry points have a row. Two items are marked unreached: the launch manifest, which does not exist yet, and whether the default Limit Break validator has code on Robinhood Chain, since this task supplied no RPC. The README's constructor order and arguments match the code.

Not changed. Only .imd-findings.json and files under test/scratch/ were written. Source, tests, configuration and libraries are untouched.

The review is complete and written to .imd-findings.json at the repository root. No source files were changed, and the working tree is otherwise clean.

Outcome. Five findings, none critical or high, plus a 32-row coverage record answering all 28 listed entry points and two invariants. The control flow of mint, stake, unstake, claim and the weight mirror between staking and pool holds under tracing. The defects are in what the pool can and cannot take in, in end-of-life carry-over, and in the renderer's odds.

Findings, most severe first:

• Medium. ERC-20 royalties are stranded in the claim pool. The pool only accounts for native ETH through its receive function and for IMD announced by the NFT. A marketplace settling a WETH offer transfers the 6.9% to the pool as a plain token balance that no function can move, and the same happens if a venue pays royalties in IMD directly. There is no admin or sweep, so stakers and the treasury lose the whole payment.
• Low. The pool's receive function needs far more than the 2,300-gas stipend. Payers using transfer or send fail on the royalty leg. The README lists it as a known limit; it is recorded because the brief exempts no venue.
• Low. Carry-over after the last mint is locked forever. Both staking and pool park IMD when total weight is zero and release it only on the next mint. After token 3,333 there is no next mint.
• Low. Renderer odds are biased by roll modulo 100 over a 0 to 255 byte. Actual background odds are 46.9/25.8/14.1/9.4/3.9 percent against the documented 40/25/18/12/5, and the on-chain Rarity Score uses the documented values. Verified by tallying all 256 byte values.
• Info. Owner trust assumption. The owner can disable royalty enforcement by setting the validator to the zero address, or auto-approve the validator for every holder including the staking contract. Documented in the README, listed because the brief says no admin key changes the economics.

Verified along the way. The default ERC721C transfer validator has code on Robinhood Chain on two public RPCs, so that dependency holds. The exported ABI files list the same functions as the sources.

Not reached. The solc compile of this 69-file project never finished within the budget on this machine, so the shipped test suite was not re-run and no proof tests were written. None of the findings is critical or high, so none needed one. The live IMD token's decimals and transfer behaviour cannot be checked from the tree, since the owner configures the address after launch.

The review is complete. The findings file at .imd-findings.json holds 11 merged findings and a 30-row coverage record (all 28 entry points plus the manifest and ABI exports). No repository files were changed, and the scratch tests were removed.

What I kept, after reproducing each against the code

• High: configure() can bind owner-chosen siblings. The one-time owner call accepts any contract whose view functions echo the expected addresses, then routes 85% of every mint fee and the full 6.9% royalty there. This conflicts with the brief's "no admin keys that can change the economics". The supplied proof fails on this code for that reason and is attached. A design-preserving fix exists: have the NFT constructor deploy its own staking and pool, leaving configure to take only the IMD address.
• Medium: ERC-20 royalties are locked in the pool. WETH-denominated offers and any IMD sent without the NFT's notify call land as balances no function can move. Three specialists reported this; merged into one.
• Low (5): IMD carry-over stranded after the final mint, the renderer's "Epoch 11" for the last three tokens, modulo bias in trait rolls versus the published Rarity Score, plain transfers into the staking contract stranding tokens (including by a policy-blocked operator), and the owner's validator powers as a trust assumption that conflicts with the brief.
• Info (4): renounce-before-configure bricks minting, the 2,300-gas stipend bounce, the plain-ERC-20 IMD assumption, and nonce grinding for traits.

What I dropped and why

• The zero-value donate releasing carry-over is not a defect. A 1-wei donate does exactly the same, and carry going to whoever is staked at the next distribution is the stated design.
• Accumulator dust of at most 1 wei per staker per settlement is negligible and not a broken guarantee.

My own pass found nothing further. Mint ordering, the fee split arithmetic, the multiplier table, swap-and-pop bookkeeping, reentrancy guards, the manifest schema, contract sizes, and the ABI exports all check out. The Slither and Aderyn lines were either already covered by the findings above or are benign patterns that I traced.

Everything passes: build clean, 77 tests green with the verifier's fuzz seed (76 project tests plus the reviewer's proof, which now passes), and forge fmt --check is clean. No launch.json or .imd-blocked.json exists in the tree.

What I found and did

Both reopened findings reproduced, and I fixed their causes rather than the symptoms.

• Owner could bind fake siblings (high). VeteransNFT's constructor now deploys VeteransStaking and VeteransClaimPool itself, stores them as immutables and sets the royalty receiver at construction. The fee split and royalty stream are never chosen by anyone. configure keeps its three-argument signature for the proof's ABI but only sets the IMD address and reverts with InvalidSibling for anything but its own contracts. The launch set is now two contracts, Renderer and NFT; the README launch table, deploy script and frontend notes say so. Initcode is 27 KB, runtime 12 KB.
• ERC-20 royalties locked in the pool (medium). Added permissionless syncImd(), which releases IMD above a new imdOwed counter as a royalty with the treasury's 90/690 cut, and permissionless unwrapWeth(), which routes WETH through a small WethUnwrapper helper so WETH9's 2,300-gas withdraw payout cannot bounce off the pool's receive(). The WETH address is not in the brief or any chain reference I was given, so it is an owner-only one-shot setWeth with an event, documented under "After launch". A wrong WETH cannot divert anything, since the pool only credits ETH that actually arrives.

Advisory findings I judged real and fixed cheaply: carry-over released when weight returns (both contracts), epoch attribute clamped to 10, trait roll scaled instead of % 100, plain transferFrom into staking refused and the validator bypass narrowed to stake-creating paths, auto-approval of the validator never covering staked tokens, and renounceOwnership blocked before configure. The three info items (stipend bounce, plain-ERC-20 IMD assumption, nonce grinding) are answered as disputed with README documentation and no code change. The setTransferValidator(0) power stays a documented trust assumption because the vendored library's setter is not virtual.

One test-helper fix worth knowing about: the in-test mining loop grew memory per attempt and only passed the 20-bit production test before by luck of an early winner. It now hashes in a fixed scratch buffer.

All eleven answers are in .imd-responses.json, and the five ABI files in docs/abi/ are regenerated.

The revised manifest is in place and verified. Only launch.json changed.

What changed and why. The accepted source was revised after my previous manifest: the NFT constructor now deploys VeteransStaking and VeteransClaimPool itself, and the pool deploys its WethUnwrapper. The old four-entry manifest would have deployed orphan duplicates of the staking contract and pool that the collection never references. The manifest now lists two contracts in dependency order:

• VeteransRenderer with no constructor arguments.
• VeteransNFT with $owner and $contract:VeteransRenderer, matching the constructor signature in source and the ABI export.

Checks run.

• Schema check in scratch: exactly the three keys, unique identifier names, backward-only contract references, notes under the limit.
• Constructor inputs cross-checked against the source and docs/abi.
• Confirmed the ERC721C validator registration in the constructor is guarded by an extcodesize check, so deployment on an empty chain does not revert.
• forge build succeeded and forge test with the verifier's fuzz seed passed all 76 tests.
• git status shows launch.json as the only modified file.

Notes carried forward as review findings, updated to the current source. The IMD token must be set by the owner once after launch, the royalty security policy is not set in the constructor and the owner can replace the validator, the pool holds the 20% share as IMD rather than ETH, the final epoch has 336 mints, and age multipliers refresh on interaction. The manifest supplies no initialization call and no invented IMD address.

The revision is complete and verified. The full suite passes with the verifier's seed.

What broke the rejected attempt. My accepted tests were written against an older source tree. Another contributor's changes then landed in src, and five of my tests failed at runtime against them:

• The NFT constructor now deploys its own staking contract and claim pool, and configure rejects anything else. My invariant fixture deployed its own siblings, so its setUp reverted with InvalidSibling and every invariant was dead.
• Carried-over rewards are now released to the first wallet that creates weight, instead of waiting for the next distribution. Three tests asserted the old timing.
• The royalty receiver is now fixed in the constructor, so one test expecting a zero receiver before configure was wrong.

What I changed. Only the three files from my accepted round, with the minimal updates plus coverage of the new surface:

• test/invariant/VeteransInvariants.t.sol takes the siblings from the NFT and sets a mock WETH. The pool IMD invariant now also checks the new imdOwed ledger equals balance minus unsynced stray IMD. Conservation invariants account for synced IMD royalties and WETH royalties.
• test/invariant/VeteransHandler.sol gains three actions: a WETH royalty that is unwrapped, stray IMD sent to the pool, and a permissionless sync of it, with ghost books for each.
• test/VeteransEdgeCases.t.sol has the four tests corrected to the new behaviour and seven new failure-path tests: a second dry spell releasing carry-over only once, one-wei sync and unwrap rounding, a fuzz that sync can only release the surplus, unwrap against a token lacking withdraw moving nothing, unwrap with no stakers carrying over, and tightened sibling rejection in configure.

Findings. No critical or high defects, so no proofs. .imd-findings.json records two low and two informational design limits my tests pin: the whole carry-over goes to the first staker after any zero-weight period, setWeth is irreversible, royalties pushed with the 2,300-gas stipend bounce, and the tenth epoch holds 336 mints because the brief's numbers conflict.

I did not commit; the working tree holds the changes for the harness to pick up, and nothing outside test/ and the findings file was touched.

Review complete. The findings file is written and every snippet anchor validates against the tree.

Outcome: all prior-round findings are settled as fixed; nothing new blocks the launch.

What I reproduced against the revised code (test/scratch/Settle.t.sol, 11 checks, all passing, plus both attached proofs now passing):

• High, configure() diversion: fixed. The NFT constructor deploys VeteransStaking and VeteransClaimPool itself, stores them as immutables and sets the royalty receiver at construction. configure() reverts InvalidSibling for anything but its own siblings. Initcode is 27,192 bytes and runtime 12,179 bytes, both within the factory limits.
• Medium, ERC-20 royalties stuck: fixed. A direct 6.9 IMD transfer is released by the permissionless syncImd into 0.9 to the treasury and 6.0 claimable, without touching owed funds. A 6.9 WETH balance is unwrapped through the helper into the same ETH split.
• Low, stranded carry-over: fixed. Carry-over is released when weight reappears, and a zero-value donate releases nothing extra, so the audit_math zero-value lead is moot.
• Low, Epoch 11 and biased trait roll: fixed. Tokens 3331 to 3333 report epoch 10 and background counts over all 256 seed bytes sit within 3 of the declared odds.
• Low, plain transfer into staking: fixed. Both holder and operator plain transfers revert, and a blocked operator's safeTransferFrom is validated.
• Low, owner validator powers: path 2 fixed via the isApprovedForAll override. Path 1 remains a documented owner power.
• Info, renounce before configure: fixed.

What the file reports, all at info severity and none blocking:

1. setTransferValidator(address(0)) remains as a documented trust assumption.
2. setWeth is one-shot, so a wrong address permanently prevents unwrapping WETH royalties. New in this round, owner-error class.
3. The first weight after a zero-weight period takes the whole carry-over, a design limit of the fix.
4. The three disputed items from last round are accepted as documented limits: the 2,300-gas stipend bounce, the plain-ERC-20 IMD assumption, and nonce grinding.

Coverage answers all 33 entry points plus rows for the manifest and renderer. The manifest lists two contracts in dependency order with correct argument counts, and the ABI exports match the compiled artifacts for all five contracts. The project suite passes 122 tests. No repository file was changed; only the findings file and my scratch tests were written.

Implemented the frontend, static export, and verified deployment manifest.

• Build/typecheck passed; 9 unit tests, 29 browser scenarios, and 16 design checks passed.
• Live mining awaits owner IMD/WETH configuration. No transactions were broadcast.
• Validation evidence and design documentation are included. Design documentation follows the permitted docs/ scope.

The requested commit remains blocked: git add returned “Read-only file system” for .git/index.lock. All deliverable files are ready for collection; the verified change bundle measured 698,857 bytes.

Saved the finding in .imd-findings.json.

Medium — bug: Clear filters leaves the gallery stuck in an empty rarity view. At 390×844 in Chromium and WebKit, choose Rarity score, load the collection index on the current zero-mint deployment, then click Clear filters. The gallery retains rarity sorting and displays zero cards. Resetting sorting to Token number restores 24 cards and page 1 of 139. Add setSort('id') and setPage(0) to the handler at web/src/Gallery.tsx:285.

Validation passed: type checking, production build, nine unit tests, 29 Chromium interaction checks, ten WebKit mining/wallet checks, export integrity, and both configured RPCs. Rebuilt assets matched the committed export. The live mining action occupied y=528.64–576.64 on the 390×844 screen.

The visual idea is a mining terminal carried by green and gold pixel miners, with wallet age expressed as increasing staking weight.

The checklist separates frontend delivery from inherited contract decisions. Contract entries below reflect preserved source and handoff evidence; this was not a new Solidity audit.