Implemented PIC and ownerless HolderClaim, including vesting, locked-NFT holder resolution, duplicate protection, and atomic payouts. Dependencies are vendored; deployment assumptions and responsibilities are documented.

Verified with Solidity 0.8.26:

• forge build and offline rebuild pass.
• forge test: 43 passing, including 8,192 invariant actions.
• forge fmt --check passes.

The truncated claimableFor requirement is implemented as the sum for distinct supplied IDs currently held by the account.

I found no math defects in HolderClaim or PICToken, so .imd-findings.json has an empty findings list and a coverage record. I read the code and worked the numbers by hand; I wrote no Foundry test and ran neither the project's tests nor forge.

What I checked against the precision, boundary and numerical-gap guides:

• Per-id share: SHARE comes out to 7,207,207,207,207,207,207,207,207 wei per id. All 111 shares add up to 23 wei less than 800M PIC, so the contract always holds enough to pay, and those 23 wei stay locked as the spec says.
• Vesting curve: SHARE * elapsed / VESTING never goes down over time and stops at exactly SHARE once 20 days have passed. Multiplying before dividing keeps the rounding loss under 1 wei per call, and nothing comes close to overflowing.
• Claim accounting: claimed[id] is set to the vested amount before the single transfer, so claimed never exceeds vested. A repeated id in the same array pays 0 the second time.
• Id bounds: ids 0 and 112 are rejected, ids 1 and 111 are accepted. In claimableFor, the shift 1 << (id - 1) is at most 1 << 110, which fits.
• Static-analysis leads:
  • Slither's strict-equality warning is the amount == 0 check, which only skips ids with nothing to pay. It is not a bug.
  • Its timestamp warnings are expected, because the vesting is meant to be time-based.
  • The rest (unused return, calls in a loop) don't change any amount.
• PICToken: it is the standard OpenZeppelin ERC-20 with a fixed supply of 1,000,000,000 × 10¹⁸ minted once to the deployer. Its approve, transfer and transferFrom contain no custom math.

All four listed entry points are marked holds, plus one extra row for the "never pays out more than 800M" invariant.

Created launch.json, matching the accepted contracts and constructor arguments. No other submitted files changed.

forge build succeeded; all 43 tests passed.

Required economics are preserved verbatim. Notes flag that they leave HolderClaim unfunded, conflicting with the requested 80% allocation.

The review is complete and .imd-findings.json is written and valid. No code defect was found in HolderClaim or PICToken.

What I checked, in my area (Execution Trace, Periphery, First Principles)

• claim path traced end to end. Each id is validated, resolved through the PFP, matched to the caller, accounted before the single transfer, and deduplicated by the cumulative claimed write. The subtraction cannot underflow because claimed only ever holds an earlier value of the monotone vesting floor. Reentrancy is guarded and the PFP reads are staticcalls.
• The holder identity assumption was tested against the live PFP logic, not the mock. I pulled the verified FWAIRPFPs source from Sourcify and built it at the fixed mainnet address in a scratch harness. Its transfer hook refuses any transfer into the PFP except through lock, escrow can only leave to the recorded holder, withdraw deletes the record, and locked ids cannot be burned. So an id owned by the PFP always has a correct, non-zero lock holder, and burned ids resolve to no holder. Nine scenarios passed, including a 111-id batch.
• Periphery integrity. The vendored OpenZeppelin v5.1.0 and forge-std v1.9.7 files match the upstream archives once formatter whitespace is ignored, and the archive hashes match the VENDORED.md records.
• Static-analysis leads (strict equality, unused betaId, calls in loop, timestamp use) were each traced and none produces a reproducible defect.

What I reported

One info-level note, not a code defect. HolderClaim's operability depends entirely on the launch routing the 80% remainder to it. The README tells the manifest step to point the remainder recipient at HolderClaim, while the launch reference says the remainder address is copied from the job verbatim. The task text says the launch sends the share to the contract by name, so this is for the manifest and admission stage to confirm.

Coverage record

All four listed entry points are marked holds, plus rows for the holder identity assumption, vesting arithmetic, the views, library integrity, static-analysis leads and the funding dependency.

Scratch tests were deleted, and git status --porcelain is clean apart from the required findings file.

The findings file is in place and the tree is clean apart from git-excluded paths. The review is complete.

Outcome: no defects found in HolderClaim or PICToken within the Economic Security, Invariant and Flow Gap areas. The findings file holds two info-level notes and a coverage record for all four listed entry points plus six invariant and flow rows.

What I checked

• Traced claim end to end: per-id cumulative accounting, duplicate handling, the single SafeERC20 transfer, reentrancy guard, and rollback on a failed, false-returning or no-code token. Vesting math cannot overflow and repeated claims lose no rounding.
• Fetched the verified FWAIRPFPs source from Sourcify and compiled it under a scratch test at the real PFP address. HolderClaim's holder resolution matched the genuine contract for escrowed, withdrawn, sold and burned ids. The real contract refuses direct transfers into itself and clears approvals on transfer, so a stale or empty lock record while the PFP owns the token is unreachable.
• Read live mainnet state: beta 1 ended on 2026-10-08 with 15 PFPs still escrowed, and an escrowed id returns a non-zero lock holder, so the lock branch is live in production today and behaves as specified.
• Diffed every vendored OpenZeppelin file the contracts import against upstream v5.1.0. All are byte-identical except SafeERC20.sol, which differs by whitespace only.
• Ran the existing suite: 43 tests pass, including the 128-run stateful invariant campaign.

Info notes recorded

1. Entitlement follows the holder at call time, as the brief requires. A seller can claim in the same block ahead of a sale, and a borrowed or rented PFP lets the borrower take the lender's accrued vesting. This is a buyer-side trust assumption rather than a code defect, with a concrete sequence given.
2. The vendoring note claims the OpenZeppelin sources are unmodified, but SafeERC20.sol was reformatted. Semantically identical; hashes and the diff are in the reproduction.

Not covered: launch-side behaviour (whether the factory routes the 80% remainder to HolderClaim by name, and any seed dust forwarded with it) sits outside the code in this tree and could not be verified here. The scratch test directory was removed after use.

Review complete. The findings file is written and no source files were changed.

Outcome: no defects found in the Access Control, Trust Gap or Asymmetry areas. The permission model holds as specified, and both entries in .imd-findings.json are informational.

What I checked:

• Access control. The only state-changing entry point in HolderClaim is claim. It refuses a zero holder, requires the live holder to equal the caller, writes claimed[id] before the single transfer, and is guarded against reentrancy. There is no owner, admin, withdraw or recovery function in the ABI. The token's three entry points are byte-identical OpenZeppelin v5.1.0 ERC20 with no overrides.
• Trust gap with the real PFP. I fetched the verified FWAIR PFP source from Sourcify. Its transfer hook only lets an NFT enter the PFP through lock, which sets the record first, only releases it to the recorded holder, deletes the record on withdraw, and refuses to burn a locked id. So holderOf cannot be fooled by a stale lock record or an unrecorded escrow. The PFP owner's powers (start or end a beta, base URI, recover ETH) cannot move an NFT or alter a lock record.
• Fork verification. A scratch test on a mainnet fork against the real PFP bytecode confirmed: an escrow-locked holder (id 2, one of 15 currently locked) claims its full share after 20 days, the PFP address itself is refused, a direct owner claims half at day 10 and a buyer gets only the other half, and a burned id has no holder. All three tests passed. The scratch directory was removed afterwards.
• Asymmetry. claimableFor deduplicates and skips non-held ids while claim reverts on them; this matches the brief and the README. Duplicate ids in claim pay zero on the second pass.

The two informational entries are the design-inherent seam that claim rights follow custody at call time (a seller can front-run a sale with claim, so buyers must price that in), and a provenance note that six vendored OpenZeppelin files are whitespace-reformatted while VENDORED.md says they are unmodified. Neither needs a contract change.

Coverage rows are recorded for all four listed entry points plus three invariant rows, all holds. The existing suite of 43 tests also passes.

Added failure-path and fuzz tests, plus expanded randomized invariants for PIC and HolderClaim.

Offline forge build and forge test passed: 53 tests, including 45,056 invariant calls.

All changes are under test/. No implementation defects were reproduced.