The work is complete and committed as 0131a0f. A fresh clone of that commit builds, passes all tests and the format check offline.

What was built

The brief's site describes KEPT as "promises the swarm enforces": a team locks tokens behind milestones, the IMD swarm signs verdicts, kept tranches unlock and missed ones burn. The delivery is three contracts under src/:

• KeptToken is the token itself: keptonchain / KEPT, 18 decimals, one billion minted once to the deployer (the factory) in the constructor. It is a plain ERC-20 with holder-only burn and ERC-2612 permit. It has no owner, no mint, no pause and no transfer rule, which is exactly what the site demands of tokens the vault accepts and what the protected floor requires of launch flows.
• PledgeVault locks any plain ERC-20 behind up to eight milestones. The beneficiary requests checks, paying up to 0.5 IMD each to an owner-set intake. Anyone submits the panel's EIP-712 verdict, verified against the signer set and quorum. Kept tranches release to the beneficiary. Milestones not proven within three days of the deadline burn through the token's own burn, or stay stranded forever if the token has none. Oracle changes wait seven days after the first configuration. Nothing can withdraw, pause or upgrade. Owner comes from a constructor argument, never from the deployer.
• RefereeFund holds donated IMD and refunds the check of each kept milestone when it can. Only the vault may draw.

Verification

Dependencies are vendored as plain files: forge-std 1.9.7 and OpenZeppelin 5.1.0, no submodules.

Documented limits and open items

• The site's "1% of every KEPT/IMD trade feeds the Referee Fund" needs a Uniswap v4 dynamic-fee hook. This launch deploys no hook and uses the fixed 1.25% policy fee, so the fund is donation-funded. The README states this and notes a later hook launch can route fees in.
• The IMD swarm's intake address, check price, signer panel and quorum are values only the oracle operator holds. They are owner-set after launch through a timelocked setter and documented under "After launch". Check requests revert as not configured until then. Pledge creation works before configuration so KEPT's own roadmap can be locked on day one.
• Slither was not available on this machine. The code avoids the six rejected detector patterns by construction.
• Tests passing are not an audit. The vault holds other people's tokens and needs independent adversarial review before anything of value is locked.

launch.json is written and verified. It is the only changed file in the tree.

What the manifest describes

• Token KeptToken, name keptonchain, symbol KEPT, 18 decimals, empty constructorArgs, totalSupply of one billion in minor units. This matches the constructor, which takes no parameters and mints the fixed supply once to msg.sender.
• PledgeVault takes the requester as owner, written as $requester, and the IMD address as its paired currency. The owner is the remainderTo address, so the owners check that forbids factory or IMD ownership is satisfied.
• RefereeFund takes the IMD address and $contract:PledgeVault, listed after the vault so the dependency resolves.
• pool and economics are copied verbatim from the launch reference: IMD as pairedCurrency, fee 12500, tickSpacing 60, the one-to-one initialPrice, and the requester's economics object.
• notes explain the token, both contracts, the owner's post-launch configuration calls, and that no contract receives KEPT at launch.

Verification

• forge build succeeds and forge test with the verifier's fuzz seed passes all 54 tests.
• A scratch script checked the manifest against the compiled ABIs: schema keys only, one argument per constructor parameter in order, unique names under 32 characters, lowercase nonzero addresses, and notes under 4000 characters.
• git status shows only the new launch.json.

One detail worth knowing: the README refers to the vault's owner placeholder as $owner, which is not a manifest placeholder. The manifest uses $requester, which the schema defines as economics.remainderTo, so the owner is the requester's address as intended.

The math review of KeptToken, PledgeVault and RefereeFund is done: three findings, each reproduced with a Foundry test that fails on the current code. I made the three passes (Math Precision, Boundary, Numerical Gap) myself; no helpers were used. The findings and coverage are in .imd-findings.json; no source files were changed, and the scratch tests were deleted after running.

Findings

1. Medium – a token whose balance can shrink breaks the per-pledge accounting (src/PledgeVault.sol:497). The "plain token" check runs only once, when tokens are deposited. All pledges of one token share the vault's balance, and each tranche is paid out as a fixed amount. If the token later shrinks the vault's balance (a negative rebase, decay or an admin burn), whichever pledge is kept first is paid in full and later pledges can never be paid.

   • Reproduction: two pledges of 100e18 each, then the vault's balance drops by 10e18. Pledge A's kept verdict pays out 100e18; pledge B's then reverts with ERC20InsufficientBalance(vault, 90e18, 100e18).
   • This contradicts the comment in KeptToken.sol:13, which says the vault refuses tokens with "rebasing or balance decay".
   • A standalone proof test is attached to the finding.

2. Low – deadlines have no upper limit (src/PledgeVault.sol:238).

   • With a deadline near the 64-bit maximum, deadline + GRACE overflows, so requestCheck, submitVerdict and settleMissed all fail with an overflow error at any time.
   • Without the overflow, a mistaken deadline such as a millisecond timestamp (around the year 59,000) has the same effect.
   • Either way the milestone never settles, so reclaimBudget is blocked for good, including IMD that third parties added with addBudget.

3. Low – a check can be bought when no answer can arrive (src/PledgeVault.sol:295). Requesting a check and submitting its verdict share the same cutoff (deadline + 3 days). A check requested at the cutoff still costs 0.5 IMD; the verdict submitted one block later reverts with GraceOver, and the tranche is then burned with no refund.

Coverage

The record has 23 rows: all 21 entry points plus two invariants (that the vault's IMD covers all pledge budgets, which holds, and that its token balance covers all pending tranches, which is finding 1). None were left unreached.

Static-analysis leads I checked and dropped

• The "uninitialized" warnings for _milestones, total, lastDeadline and last are false: these variables start at zero by design.
• The strict equality in _burnTranche is intended: it is the exact-burn check.
• The reentrancy report at line 341 is guarded: the function is nonReentrant and the fund is set once and must name this vault.
• The subtraction before - amount in _burnTranche can't underflow with a standard burn.

Limits: I only modelled the shrinking-balance case with a mock token, not a real rebasing token. I didn't look at anything outside the math area in depth.

The review is complete. The findings file is valid JSON, present in the repository root, and the only files I created are the gitignored findings file and the scratch test, so no tracked file changed.

Outcome. The economics of the KEPT launch hold up well. The token is a plain OpenZeppelin ERC-20 with burn and permit, and the vault's token and IMD accounting are conservation-safe on every normal path. I found no critical or high defect, so no finding carries a proof file. I reported four low findings and one informational trust-assumption record, each reproduced in a scratch test that passes as written against the current code.

Findings, in order:

• Unbounded milestone deadline. A deadline above type(uint64).max - 3 days makes the grace arithmetic overflow in both requestCheck and settleMissed, so the tranche can never be released or burned and the budget never reclaimed. Fix is one bound in createPledge.
• Referee Fund token not validated. setRefereeFund checks that the fund names the vault but not that it pays the same IMD token. A mismatched fund credits budgets the vault has no IMD for, and a later pledge's reclaim reverts with insufficient balance.
• Referee Fund drainable at zero net cost. Anyone can lock 1 wei of a self-deployed token behind trivially true checks and cycle 0.5 IMD per check from the fund to the intake, emptying donations meant for real teams. The actor does not profit, so this is low, but the design has no minimum stake or refund cap.
• README names a $owner placeholder for the vault's owner argument. The manifest rules only define $token, $requester and $contract:Name, so a manifest written from the README would not resolve. This is outside my area but launch-blocking if followed.
• Trust assumptions recorded as info: tokens can be locked before any oracle exists and the first panel applies instantly, an open check has no timeout, and a never-configured or renounced owner means every pledge burns.

Coverage. All 21 verifier entry points have a row, plus four invariant rows. The three guides were each applied as a full pass. Static-analysis leads were all checked: the reentrancy and uninitialized-state lines are false positives, since every mutator is nonReentrant and the milestone array is populated in createPledge. IMD on mainnet was confirmed as an 18-decimal token, so the 0.5e18 price cap is consistent. The full test suite and the format check both pass.

The review is complete. The findings file is written, validated against the tree, and the single proof test fails on the current code and passes under either fix.

Area covered: permissions, using the Access Control, Trust Gap and Asymmetry guides against KeptToken, PledgeVault and RefereeFund. I mapped every role and guard, diffed the paired inflow/outflow paths for IMD budgets and tranches, and traced each of the 21 listed entry points. All 54 existing tests pass.

Findings written to .imd-findings.json:

1. Medium, with proof. The vault credits a kept-verdict refund from whatever the Referee Fund's refund returns, never from IMD it measured arriving, and setRefereeFund checks only the fund's vault(), not its imd(). The project's own unmodified RefereeFund deployed with a different token passes the one-shot setter, and every kept verdict thereafter credits a budget with IMD the vault never received. That pledge then reclaims IMD belonging to other pledges, and the last creators to reclaim revert with their budgets stuck. A malicious owner can use the same gap to drain all budgets, which contradicts the README's guarantee that the owner cannot touch budgets. Every user-driven inflow uses the exact-arrival check in _pullExact; this is the one inflow that does not. The scratch test at test/scratch/RefundCreditedByReturnValue.t.sol fails here and passes under either a token check in the setter or a balance-delta credit.
2. Low. The README tells the manifest step to fill the vault's owner with $owner, a placeholder the launch manifest does not define. The intended value is $requester.
3. Info, trust assumptions. The first oracle configuration applies with no notice to pledges already locked, the owner may be sole signer, quorum and intake at once, and renounce is one step. Documented in the README, recorded with concrete sequences, not reported as defects.

Coverage: 24 rows, one for each listed entry point plus three invariants. Three entry points and one invariant point at finding 1. Everything else holds, including the EIP-712 replay surface and the 7-day notice, which cannot be shortened because the intake address can never return to zero.

Not reached in depth: economics-only angles outside my area, such as anyone converting Referee Fund donations into intake revenue at zero net cost through trivially kept pledges. I left it for the economics specialist since it is not a permission defect.

The review is complete and .imd-findings.json is written and validated: all four snippets match their cited lines, and all 21 entry points plus four invariants have coverage rows.

Outcome. The control-flow area of the KEPT launch is sound: no critical or high defect. The token is plain OpenZeppelin ERC-20 with burn and permit. The vault's verdict path is replay-safe, its state writes precede external calls, its grace and verdict windows do not overlap, and the real IMD token on mainnet is a LayerZero OFT with no pause, blocklist or tax, so the IMD legs cannot be frozen from outside. Two low and two informational findings are reported, each with a concrete reproduction, and the two low ones were confirmed with scratch Foundry tests.

• Low, createPledge line 238. No upper bound on a milestone deadline. A deadline within 3 days of type(uint64).max makes every later path overflow, so the milestone can never be checked, kept or burned and the budget can never be reclaimed.
• Low, submitVerdict line 341. The kept release and the Referee Fund refund are coupled with no isolation or arrival check. A fund set by the owner that reverts turns certified-kept milestones into burns. One that over-reports lets one pledge's creator reclaim other pledges' IMD. This needs the owner to set a non-canonical fund, so it is reported as a trust-assumption gap.
• Info, README line 14. The README tells the manifest step to use $owner, which is not a manifest placeholder. The vault's owner argument should be $requester.
• Info, PledgeVault line 293. Pledges can be locked before the oracle exists, but renounceOwnership is not disabled and the first configuration applies with no notice. Both are owner-side states worth stating plainly as trust assumptions.

Coverage. All three guides were applied by me directly as passes with no helpers. I did not attach proof tests, since none of the findings reaches high severity. Slither's and aderyn's medium-or-higher lines were all checked: the uninitialized-state and uninitialized-local lines are false positives, the strict equalities are sentinel checks on zero, and the reentrancy line is covered by the reentrancy guard and the trusted fund. The scratch tests under test/scratch/ are mine and nothing there is part of the submission.

Added failure-path, fuzz, and stateful invariant tests for KEPT, PledgeVault, and RefereeFund.

forge build and forge test pass with the supplied seed: 93 tests, including 57,344 randomized handler calls.

Reported two reproduced defects in .imd-findings.json, with proofs:

• Medium: mismatched fund currency creates unbacked IMD budgets.
• Low: partial burns overstate stranded balances.

I finished the review and wrote 8 findings, plus a coverage row for each of the 21 entry points, to .imd-findings.json. Nothing else in the tree changed: I ran the specialists' proofs from test/scratch/ and then deleted that folder.

Kept findings, after merging duplicates and adjusting severity:

1. Medium – Referee Fund refunds are trusted without checking what arrived (src/PledgeVault.sol:341). This merges four reports. setRefereeFund checks the fund's vault() but not which token it pays out, and it can only be called once. submitVerdict then adds whatever number refund() returns to the pledge's budget without checking that any IMD came in. The result is budgets with no IMD behind them, paid out of other pledges' IMD. It also breaks the stated promise that "the owner never touches locked tokens or budgets": the owner could install a fake fund to drain budgets, or one that reverts so tranches certified as kept burn instead. The attached proof (Proof_25bf54b8863d) fails on the current code as claimed and passes with either fix.
2. Low – Pledges in the same token share one vault balance (:337). If a token's balance can shrink after deposit, the first pledge to be kept is paid in full and later ones can never be paid. The proof reproduced this. I lowered it from medium because KEPT and other plain tokens are unaffected, and the docs already say to use plain tokens only.
3. Low – Deadline overflow (:238). This merges three reports. A deadline within 3 days of type(uint64).max makes m.deadline + GRACE overflow on every later path. That locks the tranche and the IMD budget forever, including IMD other people added with addBudget.
4. Low – Checks are sold up to the last second of the grace period (:295). A check opened at the cutoff can't be answered, so the fee is lost and the tranche burns.
5. Low – The Referee Fund can be drained into the intake address (:342). Pledges of worthless tokens with obviously true checks can recycle 0.5 IMD of working capital until the fund is empty, at gas cost only.
6. Low – Wrong placeholder in the README (README.md:64). This merges three reports. The README says to fill the vault's owner with $owner, which the launch manifest doesn't define; it should say $requester.
7. Info – The stranded counter is overstated after a partial burn. It is only a counter, and no funds are affected.
8. Info – Owner trust assumptions, merged from three reports: the first oracle setup takes effect immediately, renounceOwnership is one step, and a check the panel never answers blocks any retry.

I dropped nothing as unreproducible: every specialist finding held up, either through its proof or by tracing it through the code. Findings 3–5 were confirmed by tracing the code, not by running tests.

My own pass: The KEPT token is plain OpenZeppelin code, with the fixed supply minted once to the deployer. All three contracts are well under the deployment size limits (PledgeVault is 15,468 bytes deployed). I found nothing the specialists missed.

Static-analysis leads: None of them held up:

• the "uninitialized" _milestones is filled by push;
• the strict-equality checks are intended;
• reentrancy is blocked by nonReentrant.

Coverage: 13 rows hold and 8 point to a finding.

I fixed the medium finding and three of the low and info findings. I disputed the other four with reasons. All eight answers are in .imd-responses.json. forge build, forge test (60 passed, 0 failed, run with the verifier's fuzz seed) and forge fmt --check all pass. The required proof, Proof_3faae70e1fe9, now passes against the changed code. Nothing is committed.

Fixed:

• Refund credits IMD that never arrived (medium, 3faae70e…):
  • setRefereeFund now also refuses a fund that holds a different token from the vault's IMD (new error FundTokenMismatch).
  • When a verdict is "kept", the vault now credits only the IMD that actually arrived, measured by its own balance and capped at the price paid. It no longer trusts the number the fund reports back.
  • A fund whose refund fails now credits nothing and no longer blocks the release of a kept tranche.
  • New tests cover a fund holding another token, a fake fund that reports a refund without paying, and a fund whose refund always fails.
• Deadline overflow (6e35872a…): createPledge now rejects a deadline too close to the largest possible timestamp (DeadlineTooFar), so every milestone can still be settled after its grace period. I had the limit one second off at first; a new test caught it and I corrected it.
• Stranded count after a partial burn (f3885963…): stranded[token] now counts only the part of a tranche the burn did not remove, not the full amount.
• Rebasing and decaying tokens (9f3ceb7f…): I fixed the comment in KeptToken.sol that wrongly claimed the vault refuses rebasing or decaying tokens. The README now warns that a token whose balances can fall later may leave the last pledges of that token unpayable. I did not change the vault's accounting; KEPT and ordinary ERC-20s are unaffected.

Disputed, no code change:

• Late check requests (5313b7ce…): asking and answering sharing the deadline-plus-three-days cutoff follows the site's rule. The README now tells teams to request checks early.
• Referee Fund drained by trivial pledges (d7c72df6…): uncapped refunds are the stated design, and a cap would be a rule the brief doesn't give. The README now tells donors refunds are uncapped.
• $owner in the README (61dc8c9c…): the launch guidance for this task explicitly says to fill the owner argument with $owner. $requester stands for the address that receives the remaining 20%, which isn't necessarily the owner. I left the README as it was.
• Owner trust assumptions (a1d9d608…): the report itself says this is intended owner behaviour, not a defect. I added one point to the README: an open check that the panel never answers has no timeout.

The working tree also shows untracked entries I didn't create, such as .bashrc, .gitmodules, .mcp.json and items under .claude/. They are links to /dev/null put there by this machine's sandbox, not real files, so I left them alone.

The existing launch.json is correct and I left it unchanged. The brief says this is a revision round but lists no findings, so I verified the manifest against the accepted tree instead of rewriting it.

What I checked

• Token section matches src/KeptToken.sol: contract name KeptToken, name keptonchain, symbol KEPT, 18 decimals, no constructor arguments, and totalSupply of one billion times 10^18 minted once to msg.sender.
• Application contracts match their constructors in declaration order. PledgeVault takes the requester as owner and the IMD address. RefereeFund takes the IMD address and the earlier PledgeVault via the contract placeholder.
• Pool and economics are byte for byte what the launch reference gives: IMD as the paired currency, fee 12500, tick spacing 60, the one to one provenance price, and the requester's verbatim economics object.
• Shape uses only schema keys, lowercase addresses, string uint256 values, numeric fee, tick spacing and decimals, and notes well under the 4,000 character limit.
• Owners protected test is satisfied: PledgeVault's owner is the requester, not the factory or IMD, and RefereeFund has no owner.

Verification

• The build succeeds, and the accepted suite passes with the verifier's fuzz seed.
• A scratch test in test/scratch parses the manifest, deploys all three contracts in manifest order as the factory with the resolved arguments, and confirms the supply, decimals, name, symbol, owner and wiring. It passes.

One note outside my scope: README.md still describes the vault's owner argument as $owner, which is not a manifest placeholder. The manifest correctly uses $requester. I did not touch the README since only launch.json is writable in this task.

All earlier findings are settled and no new defect reproduces. The findings file holds an empty list and 24 coverage rows, one for each of the 21 entry points plus three invariants.

Settled findings

• Medium, refund credited from the fund's return value. Fixed. The vault now requires the fund's token to match at src/PledgeVault.sol:440 and credits only the measured IMD delta, capped at the price, inside try/catch at lines 346 to 351. My proof now passes, and the author's three new tests pass.
• Low, deadline overflow. Fixed at src/PledgeVault.sol:242. The boundary test rejects max minus grace and settles max minus grace minus one at the last uint64 timestamp.
• Low, decaying tokens share one balance. Settled by documentation, which was one of the two fixes I offered. The code is unchanged, so the old proof still fails, but the misleading claim in KeptToken.sol is gone and the README states the risk.
• Low, check sold at the end of grace. Disputed by the author as a product rule and documented. I accept that and drop it.
• Low, fund cycled to the intake. Disputed as the site's stated design and documented for donors. Dropped.
• Low, README names $owner. The manifest now exists and uses $requester, which deploys correctly. README lines 14 and 66 still say $owner, a stale wording only. Dropped from findings and noted in coverage.
• Info, partial burn overstates stranded. Fixed. Stranded now grows by the unburned remainder only.
• Info, owner trust assumptions. Documented in the README as agreed. No change needed.

Verification run

• Full project suite: 106 tests pass, including the two invariant suites.
• Changed lines read as new code. The try/catch cannot be reentered because of nonReentrant, the balance snapshot follows the tranche release of a non-IMD token, and a fund that lies or reverts credits nothing.
• Manifest checked against the schema and the constructors. Runtime and initcode sizes are well under the CREATE2 limits. The IMD address returns symbol IMD with 18 decimals and has code on mainnet.

The scratch copies of the proofs were removed, so the tree holds only the findings file.