Review complete. No source file was changed; the findings file is written and every snippet was verified against the tree.

Outcome

• forge build succeeds and all 109 project tests pass. VaultFactory runtime is 18,760 bytes with a 19,030-byte initcode, inside the floor's limits. A scratch scan of the factory and both vault runtimes found no DELEGATECALL, CALLCODE or SELFDESTRUCT, the constructor calls no contract, and the deployment with both arguments zero on chain 4663 works end to end.
• Nothing the launch forbids is present: no owner, mint, pause, blacklist, proxy, initializer or post-deployment configuration in any of the three contracts.

Findings written to .imd-findings.json (6 entries, 1 with a Foundry proof)

• Medium, launch.json line 7. The manifest in the tree is still the Ethereum one (IMD token address and $owner). Deployed on Robinhood, that factory calls safeTransferFrom on a codeless address and every vault creation reverts forever. The required arguments are two zero addresses, which also conflicts with the manifest rule that only a native-ETH Currency field may be zero. The manifest step needs to confirm the schema accepts them.
• Medium, TreasuryVault.sol line 347. The weekly cap computes balance * rateBps in checked arithmetic. A balance above roughly 4.6e73 units panics on every execute and on availableThisWeek, locking that asset permanently. Proof attached under test/scratch; it fails on this code with panic 0x11.
• Medium, TreasuryVault.sol line 336. The tracked-asset balance read forwards all gas and copies the whole return payload, so a tracked token that later turns hostile can make every ERC-20 execute run out of gas. This contradicts the stated "never blocks" guarantee. Described from the EIP-150 mechanics; not executed as a test here.
• Low, VestingVault.sol line 126. The same multiplication pattern makes releasable and release revert during the linear phase for very large allocations, then release everything at once.
• Low, TreasuryVault.sol line 187. Anyone can pin the epoch cap to a low balance by executing a small due withdrawal just before a large deposit, delaying the manager's larger withdrawal by a week.
• Info. Coverage statement.

Coverage

Read in full: the three contracts in src, all six test files, README, ADAPTATION, SWARM_BRIEF, launch.json, and the OpenZeppelin 5.1.0 SafeERC20 and ReentrancyGuard they use. Not reached: the fork test (needs an RPC) and any live check of Robinhood Chain's EVM version against the cancun target.

Done. The manifest is written and verified, and only launch.json changed.

What launch.json now says

• One contract, VaultFactoryNoFee, with an empty constructor argument list.
• Notes explain that this is the Robinhood copy of the audited factory with the brief's two zero words, why it is named through the zero-argument subclass, and what was checked.

Why VaultFactoryNoFee rather than VaultFactory with two zero words

The brief asks for the factory with both constructor addresses set to zero. The manifest rules refuse the zero address in any address argument except a native ETH currency field. The prior accepted work resolved this by adding a zero-argument subclass whose constructor passes the two zero values itself, with a test asserting its runtime bytecode and immutables are identical to the audited factory constructed with zeros. The accepted tree, its tests and the existing manifest all point at that contract, so the manifest describes it. The audited VaultFactory.sol is untouched.

Checks run

• forge build compiles cleanly.
• The full suite passes with the verifier's fuzz seed: 118 tests, 0 failures.
• A scratch rehearsal of the protected floor passes: create2 of the contract from a factory on chain 4663, runtime under the EIP-170 limit, no DELEGATECALL, CALLCODE or SELFDESTRUCT in the factory or the vaults it creates, bytecode equal to the audited factory with zero arguments, and no owner-like function.
• The manifest has exactly the three schema keys, a valid 17-character identifier, string arguments and notes under the 4000-character limit.

The owner checks in the protected suite need nothing from the manifest: the factory has no owner, admin or sender-derived role, so there is no $owner argument to supply.

I added one test file, test/RobinhoodFactory.t.sol, which tests the Robinhood copy of the factory: VaultFactory(imd_ = 0, feeRecipient_ = 0), deployed as VaultFactoryNoFee. I changed no source file and found no defect, so I didn't write .imd-findings.json. forge build succeeds, and the full forge test run with the verifier's seed passes: 147 tests in 11 suites, none failing or skipped (118 existed before, 29 are new). The file is not committed yet.

Deployment checks

• The launched copy has the same deployed code as new VaultFactory(0, 0).
• The constructor only refuses an IMD address with no fee recipient, which the brief's two zeros never trigger.
• The constructor touches no account other than the factory itself, checked with state-diff recording.
• Deploying the factory and creating vaults in a single transaction works.
• The factory refuses ETH sent to it.

Fee-free behaviour

• payFor is refused with NoFeeOnThisChain for every caller, chain id and token or vault (fuzzed, 1,000 runs).
• Creating an open vesting vault or a treasury touches only the factory and the new vault, so a wallet with no tokens and no approvals can do it.
• Repeated creations never mark anything as paid.

Failure paths: each one checks that a failed creation leaves the registry unchanged.

• createVesting: refuses a zero token, a zero amount or a zero beneficiary. It also refuses:
  • a duration 1 second short of 4 weeks;
  • a start 1 second in the past;
  • a schedule that overflows uint64 (1 second less is accepted);
  • a caller with no approval or too small a balance;
  • a token that returns false;
  • a token address with no code.
• Fuzzed boundaries: two fuzz tests check that createVesting and createTreasury accept exactly the valid inputs, no more and no less.
• Fee-on-transfer token: the creation event records the amount the vault actually received.
• Re-entering token: a token that calls back into the factory mid-creation gets its own separately registered vault and doesn't corrupt the registry.
• createLaunchVesting: refuses a zero beneficiary, a short duration, a past start and an overflowing schedule. A late-arriving launch remainder still vests over the full schedule from when it arrives.
• createTreasury: refuses a delay of 0, a delay 1 second short of 1 day or past 30 days, a rate of 0 or above 2500, a zero manager and a zero destination. The bounds themselves are accepted, and a project token with no code yet is fine.

Invariant tests: a handler with three creators and three beneficiaries randomly creates every vault type, funds vesting vaults and treasuries, releases, moves time forward, tries invalid creations and calls payFor (128 runs × depth 48, set inline in the file). After every sequence these hold:

• No fee and no custody: the factory holds no tokens or ETH, both constructor values stay zero, and nothing is ever marked paid on chain 4663 or chain 1.
• Registry: the vault count, order and creator of each vault, isVault and the per-token lists all match what the handler recorded.
• Conservation: for each token, what the vesting vaults hold plus what they released equals what went in. The beneficiaries hold exactly what was released, and treasuries keep every deposit.
• Schedule: nothing is released ahead of the schedule, nothing vests during the cliff, vesting never exceeds what the vault held, and the duration stays at least 28 days.

A fixed-sequence test shows the handler really reaches creation, funding and paying releases, so the invariants aren't passing on empty runs.

The existing fork test still needs a live run: it only executes when FORK_RPC is set, and it targets the Ethereum factory with real IMD, not the Robinhood copy.

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

Outcome

The build compiles and all 117 project tests pass. Across the Execution Trace, Periphery and First Principles passes I substantiated one medium defect and one informational deviation. All 27 listed entry points have a coverage row, none unreached.

Finding 1, medium: dust starts an open vault's unlock clock early. An open vesting vault records a token's arrival the first time sync or release runs with any nonzero balance, and that timestamp becomes the clock for every later tranche of that token. Anyone holding one wei can transfer it and call sync before the project's real tranche lands. In the reproduction, a tranche landing on day 21 of a 28-day schedule has 75% releasable in the same block, versus 0% without the dust. This bypasses the arrival-clock rule the earlier audit round added for any token that exists before it reaches the vault, which covers every Robinhood project using an open vault with an existing token. The proof test under test/scratch/ fails on the current code. The fix needs a scope decision because the documented calendar top-up rule is what enables it, and I say so in the finding.

Finding 2, info: the manifest deploys VaultFactoryNoFee, not VaultFactory. The brief says to deploy exactly src/VaultFactory.sol with two zero arguments. I verified the subclass's runtime bytecode is byte-identical to VaultFactory(0,0) and contains no Cancun-only or forbidden opcodes. Only the creation code and the verified contract name differ. Recorded so the requester consciously accepts it.

What held. The treasury's shared weekly cap behaves correctly in both orderings for a double-entry token, the window is charged before the transfer so reverts leave state intact, bounded-gas balance reads fail closed, and every manager and beneficiary rule only tightens. The factory with imd zero charges nothing and payFor reverts for every input. The manifest has only the schema's keys, one 17-character name, an empty argument list matching the zero-parameter constructor, and notes under the length limit.

Not reached. No live check of Robinhood Chain was run, so the chain's opcode support is inferred from the bytecode needing only Shanghai.

Review complete. The findings file is at .imd-findings.json with two findings and a full coverage record.

Main finding (medium): the tree is no longer the audited mainnet code. The brief says to deploy the launch 2244 code unchanged and to touch no source file. The last commit edited src/TreasuryVault.sol and src/VestingVault.sol (a gas-stipended balance read, mulDiv caps and vesting math). I verified this against Ethereum directly: the sources at the previous commit compile byte for byte to the runtime at the mainnet factory address, while HEAD compiles to a longer runtime with a different hash. Since the factory embeds the vault init code, every vault created on Robinhood would run code that was never deployed on Ethereum, breaking the "same audited code on both chains" guarantee. The proof test under test/scratch/AuditedCode.t.sol fails on this tree and passes on the restored sources. The minimal fix is restoring those two files to the previous commit; keeping the fixes instead is a scope decision for the requester.

Info finding: the manifest deploys VaultFactoryNoFee, not VaultFactory. It is a zero-argument subclass added because the manifest refuses zero-address constructor words. Its runtime is proven identical to the factory with two zero arguments and it adds no role or call, but the verified name, creation code and ABI differ from what the brief names. Recorded so the deviation is accepted knowingly.

What I checked in the Access Control, Trust Gap and Asymmetry guides. I mapped every role and guard in the factory and both vaults, diffed paired paths (queue vs execute, propose vs accept, ETH vs ERC-20 branches, bound vs open vaults, constructor vs later restriction), and traced the seams between caller permission and value flow. The permission model holds: no owner or admin exists, every manager and beneficiary power only tightens rules, public entry points pay only the announced destination or beneficiary, and I ruled out a gas-starvation bypass of the shared weekly cap. Build passes, all 117 tests pass, and the fork test against the live IMD token passes with a public RPC. Static-analysis leads were all timestamp or strict-equality notes on intended logic and reproduced no defect.

Coverage. All 27 entry points have rows: 23 hold, the three VaultFactoryNoFee creation paths and one invariant row point at the main finding, none unreached. Not covered: the protected owner-check harness, whose base file is not in the tree, and no live call to Robinhood Chain itself.

The review is complete. The findings file is in place, and no source or configuration file was changed.

Outcome. The build succeeds and all 117 existing tests pass. In the assigned area (Math Precision, Boundary, Numerical Gap) I found no critical, high or medium defect. The cap and vesting arithmetic use mulDiv, are overflow-free up to the uint256 maximum, round in the conservative direction, and never underflow. The epoch-straddle bound of 43.75% and the exact-second delay, expiry and handover boundaries behave as documented. I wrote five reproducible findings, all low or info, each verified with a scratch Foundry test under test/scratch/.

Findings written to .imd-findings.json:

1. Low, TreasuryVault.execute line 193. The withdrawn asset is charged its nominal amount, while every other tracked asset is charged its measured balance drop. A token that debits the sender more than the amount lets 27.5% leave against a 25% cap, and spent under-records the outflow.
2. Low, VestingVault.release line 161. The final release must transfer the entire balance. A token that debits the sender more than the amount makes that transfer revert forever, with no partial release or recovery path.
3. Low, VestingVault._sync line 221. Anyone can start an open vault's arrival clock with 1 wei of a pre-existing token, so a later real tranche lands partly unlocked. This contradicts the stated "vests from its arrival, never on it" for tokens that exist before funding.
4. Info, TreasuryVault.availableThisWeek line 311. The view ignores shared-balance charges, so it reports a positive amount for an untracked second entry point while execution reverts. Enforcement itself is correct.
5. Info, TreasuryVault._cap line 357. Balances below BPS/rateBps wei round to a zero cap and can never leave. Dust only, not farmable.

Coverage. All 27 listed entry points have a row, plus two invariant rows. Six are marked finding and the rest holds, none unreached. The record notes the untested token class, since the suite's fee-on-transfer mocks only take fees out of the delivered amount, never from the sender on top of it.

Outside my area, for the judge. The manifest deploys VaultFactoryNoFee, a zero-argument subclass, rather than src/VaultFactory.sol with two zero arguments as the brief words it. The suite asserts the runtime bytecode is identical, and I did not dispute that, but the deviation from "deploy exactly" is a policy question rather than a math one.

Review complete. The findings file is written and every listed entry point has a coverage row.

Outcome

The code builds and all 118 existing tests pass. The Robinhood copy charges no fee and never reaches an IMD transfer. I found one substantive economic defect in my area and one lower-severity guarantee gap, both recorded in .imd-findings.json with reproductions.

Findings

• Medium, with proof. A tracked asset's self-reported balance can freeze every other ERC-20 withdrawal of a treasury. execute charges any fall in a tracked asset's balance against that asset's window and reverts when the fall exceeds the cap, and the tracked set can never shrink. The gas stipend only defends against assets that burn gas or revert. A cheap balanceOf that answers based on the treasury's project-token balance reports a fall of 1e40 whenever the project token leaves, so every such withdrawal reverts with OverWeeklyCap for as long as the attacker keeps it armed. The precondition is one routine manager action: queueing a withdrawal of that token once, for instance to clear an airdrop. The proof in test/scratch/TrackedAssetFreeze.t.sol fails on this code with that revert. I proposed two fix shapes and noted which preserves the shared-cap design.
• Low. In an open vault, anyone can send 1 wei of a pre-existing token and call sync, which starts that token's clock. When the real allocation arrives later it counts as a top-up and is unlocked by the elapsed fraction, up to all of it at once. This is a consequence of the documented calendar-based accounting, and a token minted in the launch transaction itself cannot be pre-seeded, so it is reported as a guarantee gap rather than a loss.

Coverage

All 27 entry points have a row. Four are marked finding, the rest hold after tracing checks, state changes and failure paths. I also recorded four invariant rows, including the documented 43.75% epoch-boundary bound and the one-time double-entry case, both accepted design and not reported. Nothing was marked unreached.

Outside my area, not reported as defects

The manifest deploys VaultFactoryNoFee, a zero-argument subclass, rather than VaultFactory with two zero words, because the manifest refuses zero addresses. The existing test asserts the runtime bytecode is identical to the audited factory constructed with zero arguments, so there is no economic deviation. Robinhood Chain's sequencer-set timestamps could in principle skew the 24-hour delay, but that is not reproducible here and I left it out.

No source file was changed. Only test/scratch/ and .imd-findings.json were written.

The findings file is written, every snippet matches the tree, and all 27 entry points plus four invariant rows are covered. Review complete.

Outcome: seven findings in .imd-findings.json, three of them medium with proofs that fail on this tree, after merging the specialists' eleven reports and dropping one.

Kept, reproduced and recalibrated

• Medium, source changed from the audited code. I fetched the launch 2244 factory from a public Ethereum RPC. Its runtime is 18,760 bytes with the hash the specialist quoted, and commit ccfe47a compiles to exactly those bytes. HEAD compiles to 18,984 bytes because commit 98fd654 edited both vault sources, which the brief forbade. Proof attached and confirmed.
• Medium, tracked-asset freeze. A token the manager once queued can report a mirrored balance and make every ERC-20 withdrawal revert OverWeeklyCap indefinitely. The tracked set can never shrink. The README admits this as a trust assumption, but the NatSpec still promises no tracked asset can block the others. Proof attached and confirmed.
• Medium, dust-seeded arrival clock. Three specialists reported the same root cause at three severities. Merged into one at medium: anyone with 1 wei of a pre-existing token starts its clock on an open vault, so a later real tranche is partly or fully unlocked on landing. Proof attached and confirmed.
• Low, two sender-burn token edges. The withdrawn asset is charged its nominal amount rather than the measured drop, and the final full-balance release reverts forever. Both reproduced in my own scratch test.
• Info, view mismatch and manifest naming. The availableThisWeek view overstates for an untracked second entry point. The two duplicate manifest reports are merged into one info item: VaultFactoryNoFee has a runtime byte-identical to VaultFactory with zero arguments, but the verified name, ABI and creation code differ from the brief's wording.

Dropped: the cap-rounds-to-zero note. It reproduces but was settled and documented in the README in an earlier round.

My own pass found nothing further. The runtime contains only PUSH0 beyond base opcodes, so nothing Cancun-only or forbidden. The manifest has the right keys, name length and argument count. The full suite passes except the three specialist proofs I copied under test/scratch, which fail for the stated reasons.

For the requester: findings 1 and 2 conflict. Restoring the audited sources honours the brief but keeps the freeze path and the dust clock, which exist on mainnet today. Fixing them means both chains need a new launch. That choice is theirs.

The revision is complete. The audited sources are restored, the suite passes, and every finding is answered.

What I found

• Finding 8094ebd9 (tree not the audited code) reproduces and is right. The live mainnet factory read today is 18,760 bytes with the stated hash. The accepted base commit compiles to exactly those bytes. The previous round's edits to the two vault sources changed the factory runtime because it embeds their init code.
• Findings 9c7bf39d (mirror-token freeze) and 4e5bed0c (dust clock) reproduce too, but their proofs demand edits to the vault sources. Any such edit changes the factory runtime and fails the held proof for finding 8094ebd9. The three proofs cannot all pass, and the brief says "unchanged" and "do not change any source file".

What I changed

• Restored src/TreasuryVault.sol and src/VestingVault.sol byte for byte to the launch 2244 code. The factory source was never touched. src/VaultFactoryNoFee.sol stays, since its runtime equals the audited factory with two zero arguments.
• Dropped the five tests and four mocks in test/Audit.t.sol that only passed on the reverted edits. Added a test that pins the compiled factory to the mainnet runtime's length and hash, so any future source or compiler edit fails the suite.
• Rewrote the Robinhood section of ADAPTATION.md to say the brief's instruction governs, and to list every reproduced finding as a known behaviour of the audited code with the reason it is not fixed here.
• Updated the README accounting notes to describe the audited code's real behaviour and the operating rules that follow: only queue trusted tokens, never vest a token that debits the sender beyond the amount, and use a bound vault for a token that existed before the vault.
• Wrote .imd-responses.json: one finding fixed, five disputed with the reproduction and the reason.

Verification

Check	Result
forge build	passes
forge test with the verifier's seed, project suite	114 passed, 0 failed
Proof 8094ebd9 on the result	passes
Proofs 9c7bf39d, 4e5bed0c and the overflow proof	still fail, by design, as disputed

Open for the requester. The fixes for the overflow, gas-burning, mirror-token and dust-clock findings exist in this repository's history at commit 98fd654. Carrying them means a new audited release on both chains, which is the requester's decision, not a change to this launch.

The revision is complete. The manifest is unchanged and the finding is answered in .imd-responses.json.

Finding ecc21142 (manifest deploys VaultFactoryNoFee instead of VaultFactory with two zero words): disputed. The observation is accurate but it is not a defect the manifest can fix. The manifest schema accepts a zero word only in a Currency field and refuses the zero address in any other address argument. The task rules also forbid a zero-address stand-in. A manifest naming VaultFactory with two zero words would therefore fail validation, and the verifier already accepted the current manifest in the previous round. The subclass was added by an earlier accepted round, and this task may touch only launch.json.

What I verified on the current tree

• forge build compiles cleanly.
• The full suite with the verifier's fuzz seed passes: 114 tests, 0 failed.
• The deployed bytecode of VaultFactoryNoFee is byte for byte that of VaultFactory. The subclass constructor takes no inputs, so the empty argument list is the only correct one.
• launch.json has exactly the three schema keys, a 17-character identifier and notes of 3,011 characters.

Files changed: only .imd-responses.json, which records the disputed verdict with the commands run and their results. No source file, configuration file or manifest was modified.

The review is settled and written to .imd-findings.json (8 findings, 31 coverage rows covering all 27 entry points plus four invariants). No source file was touched; only the findings file and my scratch tests exist outside the tree.

The blocking finding is fixed. The three audited sources are byte for byte the files at commit ccfe47a. The pinned proof passes, and I re-read the mainnet factory over a public RPC today: 18,760 bytes, keccak 0x4e60104b…f98a, with the launch 2244 immutables. The no-fee subclass compiles to that same runtime with zero immutables. The full suite passes with the verifier's fuzz seed, 158 tests, 0 failures.

The disputed findings reproduce but are settled as advisory. I ran every pinned proof and rewrote scratch tests for the three unproofed ones. All still fail on the restored code, exactly as before. I accept the author's position on each: the brief orders the launch 2244 code deployed unchanged, any fix edits a vault whose init code the factory embeds, and so it cannot coexist with the held mainnet-runtime proof. They are properties of the audited code already live on Ethereum, not defects of this launch's deliverable. I downgraded the two mediums to low, kept the two lows and the info, and merged the tester's duplicates into them:

• Hostile tracked token freezes ERC-20 withdrawals (mirror balanceOf, or gas burn): one root cause, tracked set never shrinks.
• Open vault dust clock lets a later tranche unlock on arrival.
• Sender-debit tokens exceed the weekly cap and strand a bound vault's final release.
• Checked multiplication overflows above roughly 2^256/rateBps and 2^256/duration (the tester's two overflow findings, one root cause).
• availableThisWeek overstates for an untracked second entry point.
• Manifest deploys VaultFactoryNoFee with no arguments; runtime identical, name and creation code differ, accepted knowingly.

One new item, info only. The manifest notes still describe the previous tree: they say the runtime is 18,984 bytes and the suite has 118 tests. The restored tree is 18,760 bytes and 158 tests. Notes carry no deployment authority, so nothing deploys wrong, but the manifest step should refresh them.

Nothing outstanding blocks the launch. If the requester wants the vault behaviours fixed, that is a new audited release on both chains, with the earlier edits preserved at commit 98fd654.