The review is complete and the findings file holds four substantiated items. Here is the recap.

Outcome. No critical, high or medium defect was found in the three contracts as they arrived. The accounting of meters, tips, the staker stream, the seat pool and the feed budget held up under every path I traced, and the launch constraints in the brief are met. The four findings recorded in .imd-findings.json are two lows and two infos, all economic or liveness weaknesses that the authors already disclose in the code and in docs/LAUNCH.md. I report them so the adapter can make a conscious choice, not because they contradict the brief.

Findings

• Low. Tip sniping through submit. Thirty minutes after a request, anyone can hand in the oracle's public attestation and take the tip set aside for the keeper that opened the round. The attached Foundry test shows the bot earning 0.05 IMD and the opener earning nothing. It fails on the current code and passes once the opener is credited.
• Low. Twelve-hour abandon races a late writer. Any address can close a pending round at twelve hours, after which the Intake's late callback reverts with an unknown request. The price is lost and the cadence doubles. The employers feed has no submit fallback, so a griefer paying only gas can keep it from ever producing a crown on days the writer is slow.
• Info. Fixed signer. The pinned OpenZeppelin SignatureChecker takes the ERC-1271 path whenever the signer has code, so an EIP-7702 delegation or a key rotation makes every answer fail until all three contracts are relaunched. This is the brief's own no-owner choice.
• Info. Permissionless seat claims pay the current holder. A seat held in escrow or on a marketplace can have its accrued share claimed into that contract by a third party.

What I checked and how

• Read in full: Questions, Payroll, JobsReport, OracleAttestation, QuestionBody, the three internal interfaces, the two external interfaces, Mainnet.sol, the protected harness, and the first 646 lines of docs/LAUNCH.md.
• Manifest and constructors: argument order, types and the two backward references match the code. No owner, no setter, no proxy, no initializer, no external call or code-size check in any constructor.
• Bytecode: compiled the sources and disassembled all three runtimes. No DELEGATECALL, CALLCODE or SELFDESTRUCT. Questions runtime is 22,963 bytes.
• Live mainnet reads over RPC confirmed the assumptions the code makes: Intake v2 sells the action for 0.5 IMD with a 200,000 gas callback stipend and a four-word requests getter whose fourth word is the completed flag; seat ids run 0 to 1999 with total supply 2000; sIMD reports IMD as its asset with shares outstanding; the Adapter reverts for an unbound agent.

Not reached. The repository's own test suites, docs/THREATS.md, docs/AUDITS.md and the README were only sampled, not audited. The full forge test run could not be completed on this machine because compiling the whole suite with via-IR exhausted memory. The live Intake's verified source was not read; its behaviour was checked only through the RPC calls above. A clean result here is not proof of absence, especially for the oracle plane's off-chain behaviour, which the contracts trust.

Implemented opener-tip protection, extended oracle timeout grace, and protection against forced escrow payouts.

forge build passes. All 503 local tests pass.

ADAPTATION.md documents changes and remaining signer/timing limitations. Prepared for IdentityMD’s deployment stage; no broadcast performed.

I found no defects I could reproduce in the control-flow area, so .imd-findings.json has an empty findings list. Its coverage record has 24 rows: all 21 listed entry points, two balance invariants and the launch manifest's constructor arguments. Every row is marked holds with a one-line reason. No other file was changed.

What I covered

• Execution trace: I traced each entry point in Questions, Payroll and JobsReport from its checks through state changes to failure paths. That included:
  • leftover token approvals after the Intake and meter top-up calls (none are left);
  • partial updates around those external calls;
  • how request, the answer callback, submit and abandon interleave;
  • whether a caller can send too little gas to fake a result from the Intake, seat token or seat Adapter reads (they can't);
  • the fortnight ageing of the feed budget and its release to stakers;
  • how JobsReport pairs payment counts with prints.
• Periphery: I checked the QuestionBody text helpers, the small assembly helpers that read one word from another contract, the Adapter read, and the attestation check (window, then signature).
• First principles:
  • Each feed meter's share value never goes above one wei.
  • Questions always holds at least what its meters and tips add up to.
  • Payroll's ledger always balances.
  • The staker stream can always be fully sent out.
  • The feed budget only goes to stakers after the meters were served.

Static-analysis leads: None held up. The strict-equality lines all compare with zero or between counters. The "weak PRNG" line is a remainder carried to the next seat payout. The reentrancy lines are covered by each contract's transient lock and by Payroll writing its books before calling Questions. The ignored return values are timestamps nothing uses. The flagged casts are each bounded on the line before.

Launch inputs, read live from mainnet:

• sIMD's asset() is IMD, and it has shares outstanding.
• The seat token has 2,000 seats numbered 0–1,999; ownerOf(2000) reverts. This matches SEAT_COUNT and the "number 2000" constructor argument.
• The Intake (version 2) charges 0.5 IMD, under the house feeds' 2 IMD cap.
• The three feed ids are the same in the manifest, the fixtures, JobsReport and Payroll, and the arguments are in constructor order.

The whole non-fork test suite passes. I did not run the fork tests. The callback's 200,000-gas limit and the Intake's requests() layout are already tested in QuestionsCallbackGas.t.sol and QuestionsIntake.fork.t.sol, so I relied on those.

Known risks, already disclosed in the code's comments:

• Someone who buys an Intake request earlier in the same transaction can make a round fail. The employers feed can only be answered through the Intake callback, so it is the most exposed.
• A returned tip can end up owned by nobody after a meter was refilled from zero.
• Payouts to sIMD stakers have no time weighting, so a short-term staker can take a share of a drip.

The review is complete and .imd-findings.json is written with an empty findings list and a full coverage record. No tracked file was changed.

Result: no defect found in the assigned area. I checked the Access Control, Trust Gap and Asymmetry failure modes against all three contracts and the manifest, and every one of the 22 verifier-listed entry points holds.

What I traced and confirmed:

• No roles exist after deployment. No constructor stores msg.sender or tx.origin. The oracle signer is set once in the constructor and nothing reaches the setter again. Every dependency is an immutable from the manifest, and the argument order and live addresses for the Intake, IMD and the signer match the oracle-consumer reference.
• The only guarded entry point is sound. The callback requires the immutable Intake as sender and a request id this contract itself opened. A stranger who buys an Intake request naming Questions as the callback target is refused as an unknown request.
• Paired surfaces are symmetric where it matters. Callback and submit share one settlement path and write identical state. The tip always goes to the recorded opener. Fund and defund both round in the pool's favour, and the returned tip can never lift a share above one wei, which blocks first-depositor inflation.
• No approval can be spent by a third party. Every pull is from msg.sender. Questions reverts if the Intake leaves any allowance standing. Payroll approves exactly the offered amount, clears it, and reverts if more left.
• Trust-gap seams are either closed or disclosed. The Adapter controller choosing where unclaimed tips go, sIMD visitors diluting a drip, and unserved-request griefing are documented trust roots in the threat model, not bypasses. The gas floors on the Adapter and seat reads stop a caller from faking an unbound agent or an ownerless seat.

Evidence run locally: the nine launch manifest tests and nine targeted access-control tests all pass, including the callback-sender check, the panel-evidence submit refusal, the opener-tip protection, cross-seat isolation, reentrancy on request, and the two low-gas sweep fuzz tests.

Not reached: the sIMD, seat token and Adapter addresses could not be verified against the chain without network access, so the coverage row for the manifest notes them as unverified. The fork suite in the repository covers that step.

The review is complete and the findings file is in place. Nothing I need next; here is the recap.

Outcome. The math in the assigned area holds. I found no reproducible precision, boundary or numerical-gap defect that moves value, and one informational boundary mismatch. The findings file holds that one item plus a coverage row for every listed entry point.

What I checked, against the three guides

• Meter share pool in Questions. Deposits round shares down, withdrawals round assets down, and the rescale loop keeps totalShares ≥ balance so no share is ever worth more than one wei. I traced the sum bound (total + shares < 2^256 after a rescale) and confirmed the ZeroShares revert is unreachable for any non-zero deposit. A scratch fuzz ran fund, request, defund-while-pending, refill-from-zero, abandon with tip return, and defund-all, and the invariants held every run.
• Payroll top-up sizing. The lacking > 1 threshold in the shortfall is exact. A top-up through the share pool leaves Payroll's position at most one wei short, so a second call places nothing. Fuzzed over costs from 1 wei to 5 IMD with partial spends in between.
• Stream re-levelling and drip cap. The weighted-average end never moves earlier than the old end and dust bookings move it by exactly nothing while at least 604,800 wei are unvested. The cap never falls below 1/168 of what is outstanding, so a backlog is always drainable. Fuzzed.
• Feed budget ageing. The tranche invariant due + old ≤ budget survives spending, the post-call correction, and the release.
• Tip tranches, seat pool carry, the 50/30/20 split, JobsReport pairing and the bytes decoder in crown. All divisions have non-zero divisors by construction, every narrowing cast is bounded first, and no intermediate product can overflow at IMD scale.

The one finding (info). A holder calling defund(feedId, 0) is refused with NothingToDefund, while the doc comment says that error is only for callers who hold no shares. No value is at risk. The reproduction is in the scratch test and recorded in the file.

Static-analysis leads. The flagged divide-before-multiply in tip is the intended remainder. The weak-PRNG line is a modulo for bookkeeping. The strict equalities compare amounts with zero or period counters, not token balances. None reproduced as a defect.

Verification. The project's own math-related suites, 304 tests across Payroll, Questions and JobsReport, pass on this tree. The fork tests were not run because there is no network. No tracked file was modified; only .imd-findings.json and test/scratch/MathEdges.t.sol were written.

Added 11 failure-path and reentrancy tests, plus cross-contract lifecycle invariants covering 24,576 randomized calls.

forge build passed. forge test: 515 passed, 0 failed.

All changes are under test/.

The review is complete and the findings file is in place. Nothing in the repository was modified apart from the findings file and the scratch test, which the harness discards.

Result: one low finding, no critical, high or medium defects in the economics.

The one substantiated defect is in how Questions gives a failed round's keeper tip back to the meter. The tip is added to the meter balance without minting shares, so it is shared by whoever holds shares at closing time, not by the funders whose IMD paid it. Anyone who sees a round become closable can fund, abandon and defund in one transaction and take most of the tip. The scratch test confirms the numbers on this tree:

The gain is bounded by one tip per failed round, and forcing a failure costs more than the tip, so I rated it low. The authors document it as THREATS.md Q5 and left it unfixed. I reported it so the judge has the exact sequence and can decide.

What I covered in depth. All 22 entry points have a coverage row. I traced the Payroll ledger conservation laws through every writer, the stream re-levelling and drip cap math including the "cannot be rushed" bound, the fortnight ageing of the feed budget and the audit 1.1 fix ordering, the tip ageing tranches across one and two period gaps, the Questions meter share accounting including rescale and epoch retirement, and the tip escrow path through request, settle, abandon and collect. I confirmed against mainnet that the seat token has exactly 2000 ids 0 to 1999. The project's own Payroll invariant suite passed in this review at reduced run counts.

What I did not reach. I did not run the fork suite or the full Questions invariant suite, since the full via-IR test build exceeds the time budget. I did not review the Jobs Report beyond confirming it moves no value, and I did not examine the memory-safety claim in the Payroll binding read, which is outside my area.

Created launch.json exactly as requested, with constructor arguments verified against the compiled ABIs.

• forge build: passed.
• forge test: 502 passed, 0 failed.
• Only launch.json changed.

The review is complete and written to .imd-findings.json with two findings and a full coverage record. Git reports no tracked changes, since the findings file is ignored and test/scratch/ is mine.

What I kept from the panel

• Low, returned tip capture. When abandon closes a round, _returnTip adds the keeper tip back to the meter balance without minting shares. A funder who deposits while the round is pending, calls abandon, and defunds in one transaction takes almost the whole returned tip from the earlier funders, which on the house feeds is Payroll's own feed budget. I ran the specialist's proof on this tree and it fails exactly as stated. The attacker gets back 0.0467 IMD more than it deposited out of a 0.05 IMD tip. The loss is bounded by one tip per failed round, and forcing a failure costs more than the tip, so it stays low. The proof travels with the finding.
• Info, zero-share defund. A holder calling defund(feed, 0) is refused with NothingToDefund, which contradicts the doc comment two lines above. Reproduced with a scratch test. No value at risk.

What I verified myself and found sound

• All 21 entry points traced and marked holds, except abandon and defund, which point at the two findings. One extra row covers the manifest and constructors.
• The Intake's verified source on Sourcify confirms the requests struct layout the abandon path indexes, and that complete marks completion before the 200,000 gas callback.
• All six mainnet dependency addresses hold code and answer as the design expects. IMD is a plain OpenZeppelin ERC20 with LayerZero bridging and no transfer hooks.
• The manifest matches the constructors in order and count, uses only backward references, and the compiled sizes are well inside the protocol limits.

Two environment notes. The full test suite cannot be built on this machine because the cgroup caps memory at 1.5 GB and the via-IR compile of 119 files is killed. The sources and my scratch tests compile fine with the heavy test directories skipped. I did not run the project's own suites, so the independent tester's clean result is not something I re-executed.