I found no critical, high or medium findings in Weir v2, so nothing blocks deploying it unchanged. There is one low finding, recorded in .imd-findings.json. This is my own single review, not an independent audit.

Low: the oracle action and signer can't be changed after deployment (src/Weir.sol:131, src/OracleAttestation.sol:134)

• What: the oracle action id is a constant and the signer is fixed. The signer argument 0x5598…2982 is a plain wallet on chain 4663, not a contract, so it has no built-in way to switch to a new key.
• Failing state: if the oracle starts signing with a different key, each dispute still pays the full oracle fee. The ruling is then rejected as a bad signature and the stream stays stuck in dispute for the whole 7-day timeout. During that time the client can't void or refund. A scratch test confirmed this: the delivered ruling fails, void reverts, and expireDispute only works after the 7 days.
• If the action is retired: every dispute reverts with OraclePriceOutOfRange. Streams keep working in both cases.
• Why only low: the README states that changing the signer or action needs a new deployment, as part of the contract having no owner. It's a stated design choice, not a code defect. The fix is to redeploy if the protocol announces a new key or action version.

Read in full:

• src/Weir.sol
• src/OracleAttestation.sol
• src/libraries/OracleText.sol
• src/interfaces/IIntake.sol
• src/LaunchToken.sol (not deployed in this launch)
• launch.json, test/WeirTestBase.sol, test/mocks/MockIntake.sol
• the README's design sections and the earlier review and its resolution notes

I read the rest of the test files only where I needed them. The external contracts (the WEIR token, IMD, the Intake and the signer) have no source in the repository. I checked each one only from outside, by querying it on chain.

Checks:

• Build and tests: forge build && forge test passes all 166 tests.
• Deployment rehearsal: with the exact launch.json arguments the constructor runs, the deployed code is 24,533 bytes (limit 24,576), and it contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. There are no proxies, owner, minting or setup calls after deployment. The constructor calls no other contract.
• launch.json: it has only the allowed keys, all values are strings, the six arguments are in the constructor's order, and the notes are 334 characters.
• Live chain 4663:
  • all three contract addresses have code, and the signer is a wallet with no code;
  • the WEIR token reports symbol "WEIR", 18 decimals and a supply of 1e27;
  • the Intake prices the oracle action at 5e17 IMD and has both functions Weir calls.
• Oracle protocol fit:
  • the attestation format matches the protocol reference, and the conformance test passes;
  • the longest possible dispute question is 1,515 bytes, under the 2,000-character limit;
  • the ruling callback uses 152,394 gas at its most expensive (all storage cold), under the 200,000 limit.

Not verified:

• I couldn't check offline whether the live oracle accepts the request body's consumer field, so it remains unverified. No real paid oracle request was made.
• I reviewed fund flows, accounting, reentrancy, access control, the oracle callback, payouts that can be deferred to a later claim, and the dispute cooldown. A clean result here does not prove there are no defects.

Nothing tracked in the repository was changed. The scratch tests I used were deleted.

Updated launch.json for one Weir with the exact approved arguments.

• Build passed; 166 existing tests plus 5 scratch checks passed.
• Runtime confirmed: 24,533 bytes.
• Oracle limitation reproduced and documented; no medium-or-higher finding confirmed.
• Source and compiler settings unchanged; only the manifest changed for submission.

This was a bounded review, not an independent audit. Deployment handoff is prepared; no transaction was broadcast.

The review is complete and the findings file is written.

Outcome: no finding at medium or above in the Math Precision, Boundary and Numerical Gap areas. Deployment is not blocked from this area.

The file .imd-findings.json holds two informational findings and 26 coverage rows, one for each of the 22 listed entry points plus four invariant and deployment-input rows.

Findings (both info, with concrete inputs)

• Disputer share truncates to zero at src/Weir.sol:561. With a live price of 1 to 4 wei, price * 2000 / 10000 floors to 0 and a fund-paid dispute costs the disputer nothing, contrary to the "never free" comment. Only Intake governance can set such a price. The live price is 5e17.
• Bond floors to zero at src/Weir.sol:472 for stakes below 20 minor units at the 500 bps tier. The dispute proceeds with no bond. The README already says the bond is not a deterrent, so this records the exact edge.

What I checked and found sound

• The accrual formula caps before multiplying, pays the final partial second exactly, never accrues over unfunded time, and never lets streamed exceed balance or fall below withdrawn.
• Every pull and push is exact-receipt checked. Escrow, unclaimed and court fund stay under the contract balance across dispute, failure, expiry and claim paths.
• Expiry is strictly after the timeout and the cooldown opens at exactly ended + timeout. The daily subsidy cap stops at five.
• Live chain reads confirm WEIR has 18 decimals and 1e27 supply, IMD has 18 decimals, the Intake exposes requestWithFailure and prices the action at 5e17, and the constructor argument order matches launch.json.

Not reachable from here

Two external oracle boundaries cannot be verified from the pinned inputs: that the live door accepts the body's consumer key, and that a panel-evidence attestation carries the body's chainId. If either fails, every ruling would be refused and disputes would only resolve by expiry. The README assigns this to the service check, and I recorded it on the onOracleResult coverage row. The signer is an EOA with no rotation path, as already disclosed in the manifest notes. Eight scratch probe tests ran green and were removed; the tree is unchanged apart from the findings file.

The review is complete. The findings file is valid and in place, the scratch directory is removed, and the working tree holds nothing new outside the allowed paths.

Outcome: no medium, high or critical finding in the economics area. Deployment is not blocked by this review. The findings file .imd-findings.json holds one Low finding and 26 coverage rows, one for each of the 22 listed entry points plus the solvency and streaming invariants, the live deployment inputs, and one honest unreached item.

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• Conservation: every writer of the escrow, unclaimed and court-fund counters was traced, and the contract balance always covers them. The existing 166-test suite, including the 256-run solvency invariant, passes with the pinned seed.
• Streaming math: accrual is capped before multiplication, earned funds are never refunded, nothing accrues while a stream is Disputed or Ruled, and the view functions match the write paths.
• Fee and bond economics: the disputer always pays 20% of the live price, the subsidy stops at five per UTC day, and a request-id collision, under-pull or Intake revert unwinds the whole dispute. I reproduced the documented midnight burst, where ten subsidised disputes cost the attacker 1 IMD and remove 4 IMD from the fund, and it matches the README's disclosure.
• Dependency failure: a dead Intake or rotated signer only makes disputes expire with the bond returned and the fee spent, which the launch notes already disclose.
• Live chain 4663, read over the public RPC: the WEIR token has 18 decimals and 1e27 supply, IMD has 18 decimals, the Intake prices oracle-1 at 0.5 IMD and carries the v2 selector Weir calls, and the signer is an EOA. All six constructor arguments match the declaration order.

The one Low finding. A stream the client explicitly paused keeps its pre-pause rate through a dispute, and a permissionless enforce of an accepted ruling restarts it at that rate. Reproduced: with a rate of 1e18 per second, the recipient who raised the dispute enforces it and can withdraw 86,400e18 one day later, before the client pauses again. The README states this behaviour, so the author may keep it; the minimal fix is to resume only a stream that was running when the dispute began.

Still owed before relying on disputes: one paid end-to-end oracle request on a test consumer, to confirm the live attestation's chain id for a panel-evidence question is 4663. If it is not, every ruling reverts and disputes can only expire.

Sources used for the public RPC endpoint: Quicknode guide, NodeFlare.

The review is complete and the findings file is written. Nothing further is needed from the tree.

Outcome: no finding at medium or above. Deployment is not blocked from the control-flow area.

What I did

• Read the Senior Auditor's Mindset and the three assigned guides (Execution Trace, Periphery, First Principles) and checked src/Weir.sol, src/OracleAttestation.sol, src/libraries/OracleText.sol and the vendored OpenZeppelin bases against each failure mode they list.
• Built and ran the suite as it arrived: 166 tests pass, no file in src/, test/, README.md or foundry.toml was touched.
• Traced every state-changing entry point through its guards, storage writes and failure paths, including the cross-transaction sequences the guides target: deposit during a dispute followed by a rejected ruling, a stale first-dispute answer after a re-dispute, a dispute on an already paused stream, failure and expiry exits, and the two gas-capped settlement pushes.
• Ran one scratch probe, since removed, to measure the worst-case oracle question. It is 1,515 bytes against the 2,000-character limit, and the body is 1,759 bytes.
• Checked launch.json against the schema and the brief. Keys, contract name, six string arguments in declaration order, and the notes length all conform.

What is in .imd-findings.json

• One informational note. The README "Launch token" section still describes a factory-minted token supplying a $token argument, while this launch deploys Weir alone against the existing WEIR token. No code or deployment impact.
• A coverage record with 28 rows: all 22 listed entry points marked holds, five invariants I checked (escrow accounting, accrual bound, nonzero saved rate under dispute, no approval residual, manifest validity), and one unreached row.

The one open item The request body sends a consumer object with chainId and verifyingContract. The pinned oracle references name that key but never show its shape, and live acceptance cannot be checked offline. If the Intake door refused it, every dispute would end in onFailure, returning the bond but spending the disputer's IMD share and starting the seven-day cooldown. The README already lists live body acceptance as a post-acceptance check for the deployer, so I recorded it as unreached rather than as a finding.

Review complete. The findings file is written and validated, and no file outside .imd-findings.json and test/scratch/ was touched.

Outcome: no medium, high or critical finding in the Access Control, Trust Gap and Asymmetry area. Deployment is not blocked from this review. This is not an independent audit.

What I checked:

• Permission map. Every state-changing entry point was traced for its caller guard, state guard, storage writes and failure path. All 22 listed entry points have a coverage row, plus rows for the constructor arguments and the custody invariant.
• Paired surfaces. pause/restart/adjust, refund/withdraw, dispute/enforce/expire/onFailure, pushExact/pushOrDefer/defer, and accept versus the two implicit acceptance paths all mirror their writes correctly.
• Live constructor inputs on chain 4663. WEIR at the first argument is a plain 18-decimal token with 1e27 supply, so the 10k hold and the 10M zero-bond tier are reachable. IMD is 18 decimals, the Intake prices the action at 0.5 IMD, and its bytecode carries the v2 requestWithFailure selector. The signer matches the reference table.
• Build and tests. forge build and all 166 tests pass unchanged.

What I recorded:

1. Low. Anyone can call expireDispute one second past the timeout, while the attestation the contract requests stays valid for the same 604800 seconds. A ruling delivered late can be voided by the losing party in the block before delivery. A scratch test demonstrates the sequence.
2. Info. The unbounded dispute(id, note) overload lets the client front-run with a deposit to inflate the recipient's bond. The README already documents this and the bounded overload, so it is recorded as an accepted limitation.

Known limitations already documented by the author (flash-borrowed WEIR for the gate and tier, bond shrinking, court-fund griefing at 20% cost, client voiding ahead of a dispute, immutable signer) were confirmed in the code and treated as trust assumptions rather than findings.

The review is complete and .imd-findings.json holds six findings and a 24-row coverage record.

Verdict: no medium, high or critical defect. Deployment is not blocked.

What I verified on this tree:

• forge build and forge test pass, 166 of 166 tests.
• Runtime is 24,533 bytes and creation code with arguments is 26,342 bytes, both under the factory's limits. The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, and the constructor makes no external calls, so it deploys on an empty chain.
• The manifest has exactly the three schema keys, six string arguments matching the nonpayable constructor in declaration order, and notes of 2,408 characters.
• A cold first ruling costs 152,370 gas in the callback frame, under the Intake's 200,000 stipend with an EOA signer.

Findings kept, each reproduced with a scratch test in test/scratch/JudgeProbe.t.sol:

1. Low. expireDispute is permissionless and the requested attestation validity equals the dispute timeout, so the losing party can expire a dispute one block before a late but still-valid ruling arrives and void it.
2. Low. A permissionless enforce of an accepted ruling resumes a stream the client had paused before the dispute. The README states this is intended, so the author may close it as design.
3. Info. The disputer's 20% share truncates to zero below a 5 wei oracle price.
4. Info. The bond rounds to zero for stakes under 20 minor units.
5. Info. The unbounded dispute(id, note) overload lets a client inflate the bond by front-running with a deposit. Documented, with the bounded overload as the remedy.
6. Info. The README's Launch token section still describes a factory-minted token and a $token argument this launch does not use.

All specialist findings reproduced at their reported severities, so none were dropped, and no two described the same root cause. My own pass found nothing additional. Two things could not be checked offline and are noted in the coverage record rather than as findings: the shape the oracle plane expects for the body's consumer key, and the callback gas if the live signer is a contract rather than a key. This is a review of the specialists' audit plus my own read, not an independent audit.