The findings file is in place, every snippet matches its line, and the only new files are the findings JSON and the scratch tests, which the harness itself excludes from the tree. No source, config or library file was changed.

Outcome: 2 medium, 3 low, 3 info findings in .imd-findings.json. The proof test for the top finding fails on the current code and is attached.

Contracts read: VaultFactory, VestingVault, TreasuryVault, both test files, README, brief, foundry.toml, and the OpenZeppelin 5.1.0 pieces they import. The existing suite passes (38 tests). Not reached: the live IMD token on Ethereum (the fork test needs an RPC and was not run), the swarm launch factory that pays remainderTo, and the radar's off-chain seal logic.

Findings, most severe first:

• Medium, with proof. Nothing bounds start, so a vesting vault created with a start 28 days in the past, cliff 0 and duration 28 days is 100% releasable in the block that creates it. The seal reads the registry, not the schedule. Minimal fix: reject or clamp a start before block.timestamp in the VestingVault constructor.
• Medium. Tokens that land in an open launch vault after start + cliff are unlocked on arrival in proportion to elapsed time, contrary to the README's "vests from then on". A slipped launch can make the whole remainder withdrawable at once. A start floor does not fix this. The adapter must choose between per-asset arrival anchoring and documenting the calendar schedule.
• Low. The treasury cap is per fixed calendar epoch, so 43.75% of a balance can leave across one epoch boundary. This is documented in a dev comment but weaker than the objective's wording.
• Low. start + cliff is unvalidated. An overflowing schedule pulls the tokens in and then every release reverts forever.
• Low. recover() on a bound vault lets a double-entry-point token leave during the cliff. The standard balance-before-and-after guard fixes it.
• Info. A project that makes a pre-launch vault and later a bound vault pays the 5 IMD fee twice, since nothing links the open vault to its token.
• Info. TreasuryVault's own constructor does not enforce the 24h minimum delay. Only the factory does.
• Info. Coverage note listing what was read, what passed the checklist (no owner, pause, upgrade, delegatecall, selfdestruct, proxy, or constructor external calls; reentrancy and accounting hold), and what could not be reached.

The remaining leads each have a reproducing test in test/scratch/Leads.t.sol that passes on the current code to demonstrate the behaviour.

The work is complete and verified: forge build succeeds and forge test passes 54 tests with the verifier's fuzz seed and three others.

What I found. All seven concrete audit findings reproduced on the code as it arrived (checked with a scratch test each before changing anything). The factory itself already fits the launch kind: a nonpayable two-argument constructor, no external calls, no owner, so src/VaultFactory.sol is untouched.

What I changed, each with a test in the new test/Audit.t.sol:

• Past start (medium). The vault constructor now refuses a start before the current block, so nothing can be unlocked in the block that locks it.
• Late arrival to an open vault (medium). Open vaults record each token's arrival once, via the new public sync or the first release. That token's linear unlock begins at the later of start + cliff and its recorded arrival, so a launch that slips past the schedule still vests from the day it pays the vault. Bound vaults and top-ups keep their documented calendar behaviour. Two existing launch tests now call sync after the stand-in launch, with a comment saying why.
• Schedule overflow (low). The constructor and extendDuration require start + cliff + duration to fit in 64 bits, so tokens can no longer be trapped by a typo.
• Double-entry token through recover (low). A bound vault reads the vested token's balance before and after the transfer and reverts if it fell.
• Treasury 24h floor (info). The treasury constructor enforces its own MIN_DELAY as well as the factory.
• Epoch boundary cap (low). Left as designed, since the source and README already describe fixed epochs and the brief says to keep the rules as written. The NatSpec and README now state the real bound of 43.75% across a boundary at the 25% ceiling, and a test pins it.

Left alone and explained in ADAPTATION.md: the double fee for a pre-launch vault plus a later bound vault matches the brief's "fee keyed to the vault address" and is now documented in the README. The coverage note needed nothing. The fork test still skips without an RPC.

The README gained a fourth launch step telling projects to call sync(token) right after their launch, which the deployer's radar may also do on their behalf. Nothing was committed, since the git directory is off limits for this task. Nothing needs to be called after deployment.

Created launch.json naming only VaultFactory, with the specified IMD address and $owner constructor arguments.

Validation passed: manifest and ABI checks, forge build, and all 54 tests using the supplied fuzz seed, including the Ethereum fork test.

Only launch.json changed for submission.

I found four defects in the permission area and wrote them to .imd-findings.json, with a coverage row for all 23 entry points plus two invariant rows. Each of the three medium findings comes with a Foundry proof, and I ran each proof to confirm it fails on the current code for the stated reason. I changed no source files; the scratch tests have been deleted.

Findings

1. Medium – src/VestingVault.sol:102: an open (launch) vesting vault tracks each token by its address. A token with two addresses sharing one balance therefore vests twice. On a 4-week schedule, sync both addresses and call release on each after one week: the beneficiary gets 437.5e18 of 1000e18 (43.75%) instead of at most 25%. recover() was already fixed against this same kind of token, but release() was not.
2. Medium – src/TreasuryVault.sol:159: the treasury's weekly cap is also kept per token address. The manager queues 250e18 against the main address and 187.5e18 against the second address, and both execute in the same block. That is 43.75% leaving in one week instead of 25%.
3. Medium – src/TreasuryVault.sol:154: the 14-day expiry is measured from the current delay, so raising the delay brings expired withdrawals back. A withdrawal queued at T0 with a 1-day delay is expired at T0+20d. The manager then calls increaseDelay(20 days), and in the same block anyone can execute it and pay out 250e18. So a change meant to make the rules stricter loosens the expiry. The fix is to store each withdrawal's expiry when it is queued.
4. Low – src/TreasuryVault.sol:223: a manager change already proposed keeps the old, shorter delay. Propose a new manager with a 1-day delay, then increaseDelay(30 days): the new manager can still accept after 1 day. I confirmed this with a quick test, but it has no proof attached.

Coverage: five entry points are marked finding (acceptManager, execute, increaseDelay, release, sync). The other 18 are holds, none are unreached. I found no owner, admin, pause, upgrade or emergency path. The fee recipient's only role is receiving fees, and the factory keeps no funds or privileged state.

I treated the static-analysis lines as leads. The strict-equality and timestamp warnings didn't lead to a defect in this area. I didn't report anything about third parties using execute to fix the epoch cap early, because that only makes the cap stricter.

The review is complete and .imd-findings.json holds three findings and a coverage row for all 23 entry points plus three invariants. The working tree is otherwise untouched apart from the scratch tests, which are not kept.

What I checked. I traced every division, cast, boundary comparison and sentinel branch in the three contracts against the Math Precision, Boundary and Numerical Gap guides. The core arithmetic holds: vestedAmount rounds down and caps at the total, the schedule is bounded to fit uint64, the treasury epoch cap never lets spent exceed cap, all delay and eta sums are bounded by 30 days, and the straddle bound of 43.75% matches what the README states. The vendored SafeERC20 (OpenZeppelin 5.1.0) refuses targets without code, and IMD on mainnet has 18 decimals and symbol IMD, so the hardcoded 5e18 fee is right. The existing suite of 54 tests passes.

Findings, most severe first.

1. Low, with a failing proof. An open vault counts a double-entry token (one balance reachable through two addresses) as two allocations, because released is keyed per address while the balance is shared. On a 28-day schedule the team receives 43.75% in the first week instead of at most 25%. The proof test fails on this code with that exact number. Only a vault holding such a token is affected, and IMD launch tokens have one entry point.
2. Low. The open-vault clock starts on any nonzero balance, including 1 wei. A deposit made after the schedule has run is 100% releasable in the same block. This is the documented top-up design, but it means the 25%-a-week rule only holds for each token's first tranche, and the radar would show the balance as locked.
3. Info. The treasury cap floors to zero for small balances (any balance under 10,000 units at 1 bps, or 3 units at 25%), so an asset can never be fully withdrawn. A direct consequence of the rule as written.

Not reported. Intermediate overflow in total * elapsed or balance * rateBps needs a balance above 2^192, which no real token reaches. The epoch-zero window default only matters on a chain younger than seven days.

I added two test files. With the verifier's seed, forge build and forge test pass: 90 tests, 36 of them new, and the run also passes with a second seed. I found one real defect and two minor issues; they are reported in .imd-findings.json instead of being asserted as correct. No source file was changed.

test/Invariants.t.sol: random call sequences (256 runs × 64 calls) over everything that holds value:

• Vesting: one bound vault and one open vault holding two tokens. The handler mixes time jumps, top-ups, sync, release by anyone, duration extensions, beneficiary handovers, attempts by strangers, and recover of the vested token. The checks:
  • what the vault holds plus what it released equals what it received, and only beneficiaries ever get paid;
  • nothing is released during the cliff or beyond what has vested;
  • at most 25% vests in any 7 days;
  • the duration only grows and never drops below 4 weeks;
  • an open vault records each token's arrival once and never moves it.
• Treasury: a restricted treasury holding a token and ETH. Withdrawals can't run before the delay (never under 24h) or after the 14-day grace period, never run twice, and only go to listed destinations. Per epoch, no more than the rate × the balance at the first withdrawal leaves. Delay only rises, rate only falls, the destination list only shrinks and never reaches zero, and the treasury never reopens.
• Factory: the radar wallet holds exactly 5 IMD per paid project or vault, never a second charge. The factory holds no tokens and the registry lists every vault it made.
• Two fixed-sequence tests show the random runs really do reach paid withdrawals and releases, so the checks aren't passing on empty runs.

test/EdgeCases.t.sol: 25 failure-path and boundary tests. They cover every error the contracts declare that the earlier tests never triggered, the exact second either side of each delay, cliff, grace period and handover, the weekly cap exactly reached and then exceeded by 1 wei, and a failed fee payment leaving nothing behind. They also cover an ETH payment to a destination that refuses it: the call rolls back, spends no cap, and can be retried. A fuzz test checks that nothing is ever paid out beyond what was deposited.

Reported findings:

• Low: the treasury's weekly cap can be doubled (src/TreasuryVault.sol:159). The cap is tracked per token address. Some tokens have two contract addresses sharing one balance, the same kind of token an earlier audit fix guarded against in recover(). With such a token, the manager can withdraw through each address and get two caps. Reproduced: from a treasury holding 1000, 437.5 left in one block where 250 is the limit. The failing test is attached as proof.
• Info: the vesting creation event can overstate what's locked (src/VaultFactory.sol:81). For tokens that take a fee on transfer, the event records the amount requested, not what the vault received. The radar reads this event to show locked amounts.
• Info: anyone can file vaults under any project's token (src/VaultFactory.sol:145). Once the project has paid, further vaults are free, and a stranger can register a treasury under another project's token with themselves as manager. Nothing can be stolen, but the radar must not treat that list as the project's own vaults.

Nothing is committed.

Review complete. No tracked file changed; the findings file and two scratch tests are the only new files, and both are ignored by git.

Outcome: one medium and one low finding, written to .imd-findings.json with a Foundry proof for the medium and a coverage row for all 23 entry points plus 4 invariants.

Finding 1, medium: late tranches vest retroactively. vestedAmount applies the elapsed fraction of the schedule to the whole current balance, so any token arriving after the unlock has started is unlocked by that fraction on arrival. A bound vault whose 4-week schedule has ended is a pass-through: a 1-wei vault plus 3% of supply sent 28 days later is fully releasable in the same block, which satisfies the radar's "3% locked" seal with liquid tokens. The launch flow has the same gap: after the remainder is recorded in an open vault, a second tranche 21 days in unlocks 75% on arrival. Both are shown by test/scratch/TopUpPassThrough.t.sol, which fails on the current code. The README documents top-ups as design, so I stated the fix (per-tranche accounting with each tranche vesting from its own arrival, the rule round 1 applied to first arrivals) and the alternative (restate the rule and count locked supply as balance minus releasable) as a judge's scope decision.

Finding 2, low: free registry entries under a paid token. The fee is keyed only to the token address, so once a project has paid, any stranger with no IMD can file unlimited treasuries under that token at 1.68M gas each, all appearing in vaultsByToken. No funds at risk; it is registry pollution the radar should filter by creator event.

What holds in my area. The treasury cap, delay, expiry, stricter-only setters and manager handover trace clean. Flash or donated deposits cannot inflate the cap profitably because the deposit stays locked. The 43.75% epoch-straddle bound was already accepted as design in round 1 and is not re-reported. I verified the live IMD token on-chain: an OpenZeppelin ERC20 under LayerZero OFT, 18 decimals, no tax, pause or blacklist, and the fork test passes against it, so the 5 IMD fee path is sound.

Unverified lead, not reported: VestingVault has no receive(), so a launch that also forwards ETH to remainderTo would revert. The launch factory is not in the tree, so I could not confirm whether it does.

The review is complete. The findings file at .imd-findings.json holds four findings and 28 coverage rows, all snippets verified against the tree, and no tracked file was changed (scratch tests live only under test/scratch/).

Findings

1. Low, TreasuryVault.execute: the weekly cap is keyed by asset address, so a double-entry token (TrueUSD legacy entry, Synthetix proxy/target) gets two 25% windows over one balance. Reproduced: 43.75% of the treasury leaves in a single epoch. Proof test attached in test/scratch/DoubleEntry.t.sol, fails on the current code.
2. Low, VestingVault.release in an open vault: the same token class is vested once per address, so the beneficiary takes 43.75% in week one instead of 25%. Reproduced in the same scratch file.
3. Low, TreasuryVault.increaseDelay: because expiry is derived from the live delay, raising the delay revives an already expired withdrawal and lets it execute in the same block, with no fresh notice window. Reproduced in test/scratch/Edges.t.sol. Proposed fix stores the expiry at queue time.
4. Info, VestingVault.vestedAmount: a tranche sent after the schedule ran is 100% releasable immediately. Documented design, but it means the radar should count balance minus releasable as locked, not balance.

What held

• All 23 listed entry points were traced. Checks, state changes, CEI ordering and failure paths hold for everything except the three functions above.
• Reentrancy through a hooked token into execute and release is blocked. An ETH destination that rejects leaves the withdrawal open and consumes none of the window. The last destination cannot be removed.
• The live IMD token on Ethereum is a LayerZero OFT ERC20 with no fee, pause or blacklist selectors. The project's fork test against it pays exactly 5 IMD to the recipient.
• VaultFactory runtime is 17,180 bytes, under the deployment limit, with both vault creation codes embedded.

Not reached: nothing in the assigned area. The straddle bound and the double fee for pre-launch vaults are documented design, not reported again.

The review is complete and .imd-findings.json holds 8 findings plus a 25-row coverage record. No tracked file was changed; only the ignored findings file and test/scratch/ were written.

What I verified

• The build passes and all 90 existing tests pass. The factory's runtime and initcode sizes are well under the deployment limits, its constructor makes no external call, and launch.json matches the brief.
• All four specialist proofs fail on the current code for the stated reasons. I wrote one more scratch suite that confirms the five lower-severity claims by asserting the current behaviour.
• The live IMD token on Ethereum is a plain 18-decimal ERC20 with an owner, so the fee path is standard.

Findings kept, after merging duplicates across the five reports

1. Medium, with proof. The treasury's weekly cap is keyed per asset address. A double-entry token gets a fresh 25% cap per entry point, so 43.75% leaves in one block. Three specialists reported it; merged into one.
2. Low, with proof. Raising the delay revives an expired withdrawal and lets anyone execute it in the same block, with no new announcement. Two reports merged.
3. Low. An open vesting vault vests a double-entry token once per address, 43.75% in week one. Three reports merged. No proof attached, because every contract-side guard I could find is either a design change the brief rules out or a gas-griefable loop. The fix I propose is documentation plus the radar refusing such tokens.
4. Low. Top-ups vest retroactively, so a finished vault is a pass-through and a 1-wei vault can earn the 3% seal. Three reports merged, downgraded from medium because the README documents it. The radar should count balance minus releasable, or the author accounts per tranche; that is a scope decision.
5. Low. Once a token has paid, anyone files free vaults under it and can grow the unbounded registry view. Two reports merged.
6. Info. A pending manager change keeps its original delay after increaseDelay.
7. Info. The vesting creation event logs the requested amount, not what a fee-on-transfer token delivered.
8. Info. The weekly cap rounds to zero for small balances, so an asset can never be fully withdrawn.

My own pass over every entry point found nothing beyond these. The static-analysis lines are all intended sentinel checks or timestamp reads, none reproduced as a defect.

The factory stays well under the 24,576-byte runtime limit, the diff is confined to the three contracts, the audit test file and the two docs, and the untracked .imd-responses.json is in place. The work is complete.

Outcome. The reopened finding reproduced and is fixed. The reviewer's proof now passes, the full suite passes with the verifier's fuzz seed and two others, and every finding has an answer in .imd-responses.json.

What changed in the contracts.

• Treasury shared cap (medium, held to proof). The treasury now tracks every ERC-20 asset the manager has ever queued. Each ERC-20 withdrawal reads the other tracked balances before and after the transfer, and any balance that fell is charged against that asset's weekly window too. Two addresses to one balance therefore share one 25% window, in whichever order they are used. Reads use a static call that treats failure as zero, so a mistakenly queued address never blocks other withdrawals, and ETH is not tracked since a token transfer cannot move it.
• Expiry fixed at queue time (low). The withdrawal struct stores its expiry, so raising the delay can close a queued withdrawal but never revive an expired one.
• Pending manager follows the current delay (info). The proposal time is stored and pendingManagerEta() becomes a view over it plus the current delay, with the same name and return type.
• Creator in the registry (low). The factory records creatorOf[vault] and both creation events carry the creator, so the radar can filter vaults to the paying project. The fee rule itself is unchanged.
• Received amount in the event (info). VestingCreated logs what the vault actually received from a fee-on-transfer token.

Documented rather than changed. Three advisory findings reproduce but ask for documentation or an off-chain rule, and a code change would redesign behaviour the brief says to keep: the open vault's per-address accounting for double-entry tokens, calendar-based top-ups, and the cap rounding to zero for dust. The README now states each limitation, counts locked supply as balance minus releasable, and says the radar refuses its seal to an open vault holding a double-entry token.

Not run. The fork test against the live IMD token still skips without an RPC variable, as in the previous round.

Revised launch.json is in place and verified. Only that file changed.

What I found. The accepted manifest from my previous round still had the correct deployment entry: one contract, VaultFactory, with the IMD token address as the first argument and $owner as the fee recipient. The constructor in the accepted source is unchanged, takes exactly those two parameters in that order, and calls no other contract, so it deploys cleanly on the protected harness's empty chain. The notes, however, were written before the other contributor's second audit round changed the treasury and factory, and no longer described the accepted tree.

What I changed. Only the notes string. It now describes the accepted implementation:

• Treasury withdrawals have a fixed expiry set when queued, so raising the delay can never revive an expired one.
• Every ERC-20 asset the manager ever queues is tracked, and a withdrawal that lowers another tracked balance is charged against that asset's window, so two addresses to one balance share one 25% cap.
• A pending manager change waits the current delay.
• The registry records the creator of each vault, and creation events carry the creator and the amount actually received.
• The open-vault, fee, vesting floor and no-admin rules are stated as before.

Verification.

No .imd-blocked.json was needed, since every argument is fixed by the brief and the launch policy.

The latest implementation round had broken my earlier tests' build. They compile again, I added tests for what that round changed, and forge test now passes: 109 tests, both with the verifier's seed and with a second seed. I didn't change any source files and didn't write .imd-findings.json, because nothing I probed showed a defect I could reproduce.

What broke: treasury withdrawals gained an expiresAt field, so my tests' reads of them no longer compiled. I fixed those reads in test/EdgeCases.t.sol and test/Invariants.t.sol. In the random-sequence treasury tests, I replaced the old expiry check (queuedAt + current delay + 14 days) with a stricter one: the expiry is recorded when a withdrawal is queued, and the tests check it never moves and that nothing executes after it. The factory random-sequence test now also checks that every vault is recorded under the wallet that created it.

New file test/SharedCap.t.sol:

• Random-sequence tests over the new shared weekly cap. A test token has two addresses that share one balance, and a second unrelated token sits beside it. A test contract deposits, queues through either address, cancels, executes, tightens the rate and delay, and moves time forward. After every step two things are checked:

  • Within each 7-day period, the total leaving the shared balance stays within one 25% cap, whichever address is used.
  • Every token held is accounted for.

  My first version passed without exercising anything: almost no withdrawal ever executed, because the test also called the helper's read-only functions and tightened the rules in big jumps. I fixed that and confirmed that runs now reach real withdrawals and real over-cap refusals.

• Boundary tests:

  • A withdrawal can execute exactly at its expiry and is refused one second later.
  • When a delay increase moves the due time onto the expiry, there is exactly one second left to execute.
  • A fuzz test checks the expiry never moves when the delay is raised.
  • The same asset is tracked once, ETH is never tracked, and only the manager can add assets.
  • When the rate is lowered, cap periods already open keep their limit and new ones use the lower rate.
  • The documented 43.75% maximum across two weeks' cap periods holds.
  • A tracked token whose balance can't be read doesn't block other withdrawals, but can't itself leave until it can be read.
  • A manager handover restarts its waiting period when proposed again and clears when cancelled.
  • Each open treasury costs its own fee.

What I tried and couldn't break in the new treasury code:

• Order of use: withdrawing through one address and then the other, in either order.
• Late tracking: the second address is only queued for the first time later in the same week.
• Week boundaries: withdrawals on either side of the switch to a new 7-day period.
• Unreadable balances: a tracked token whose balance read fails, including deliberately starving that read of gas. That would need a balance read costing millions of gas, so it isn't practical.

The changes are in the working tree and not committed.

Review complete. The findings file is written at .imd-findings.json with no open findings and coverage for all 23 entry points plus two invariants. The working tree is otherwise unchanged.

Settlement of my earlier findings

• Treasury cap per address (medium, c693ed06): fixed. The attached proof now passes against this code. I traced the new tracked-asset logic in execute() in every order: main first, legacy first, legacy queued after main already withdrew, and three addresses. Every outflow through a tracked address is charged to each other tracked address whose balance fell, so the window opened first in an epoch bounds the epoch total. The tester's shared-cap invariant suite also passes.
• increaseDelay revives an expired withdrawal (low, 960ccd81): fixed. Expiry is stored at queue time and checked directly. The proof passes. A raise that pushes the due time past the expiry closes the withdrawal, as I proposed.
• Pending manager keeps the old delay (info, 5811a810): fixed. The eta is now proposal time plus the current delay.
• Free vaults under a paid token (low, 8d4b11e3): fixed as proposed. The registry and both creation events record the creator, and the README tells the radar to filter by it and read events, not the unbounded view.
• VestingCreated logs the requested amount (info, 28e462ee): fixed. The factory emits the measured balance difference.
• Open-vault double-entry vesting (low, 93c43379) and retroactive top-up vesting (low, 7f9d9778): closed by documentation. Both were resolved with the documentation option I offered, and I said then that no contract change would be required. The old proofs for them still fail, which is expected. README and NatSpec now state per-address accounting, the seal refusal for double-entry tokens, and that locked supply is counted as balance minus releasable.
• Cap rounds to zero (info, cc57dd0d): documented, as requested.

The specialist reports this round describe the pre-fix code and all map onto the items above, so nothing new came out of them.

Verification

• All 109 project tests pass, including the 11 new audit tests and the tester's SharedCap invariant and edge tests.
• VaultFactory runtime is 18,760 bytes and initcode 19,030 bytes, within the deployment limits.
• I could not run the protected floor tests: they import the verifier's floor harness, which this tree does not carry.

Not reported as a finding. A manager could queue a junk token whose balanceOf burns all gas, permanently blocking ERC-20 executions. I left it out because the manager can already freeze the treasury for good under the agreed design, for example by restricting destinations to a dead address, so it adds no new power. The staticcall in _tryBalance could be given a gas stipend if the author wants to close it anyway.