Approved workflow

Implemented LaunchToken, SniperVault, CompanyStaking, ABI exports, vendored dependencies, and operational documentation.

Validation passed: forge build, all 62 tests, forge fmt --check, and ABI consistency checks—including an offline test run with an empty environment.

Live deployment still requires verified Robinhood registry, trading, and oracle integrations. Missing inputs and required interfaces are documented in deployment notes.

the task produced no changes; the agent's last message was: launch.json is blocked by six missing constructor values: IMD address, registry address, launch factory address, venue address, IMD/ETH pool ID, and chain ID. The accepted deployment documentation marks all six as unspecified.

I requested these values; placeholders would produce an invalid deployment.

forge build succeeded; all 62 tests passed. No submission files changed.

The review found three defects: one medium and two low. Nothing critical or high turned up, so no finding carries a Foundry proof. Results and coverage are in .imd-findings.json. I changed no project files: I ran two throwaway tests under test/scratch/ and then deleted them. The existing 62 tests all pass.

Findings

1. Medium: the swap venue and launch registry that snipe, sell and burnExpired depend on are not implemented anywhere (src/lib/Trading.sol:58).

   • The rule that snipe only buys tokens from the IMD launch contract is enforced entirely by an external registry. There is no code for it in this repo.
   • Buying COMPANY for burnExpired likewise relies on an external venue with no code here.
   • docs/DEPLOYMENT.md marks six of CompanyStaking's seven constructor values as unsupplied. SniperVault copies the same values from CompanyStaking.
   • If the venue address points at something that doesn't implement these calls, every burnExpired reverts. Staking has no admin or rescue path, so expired reward IMD stays locked in it permanently.
   • There is also a problem in the source itself. burnExpired looks up COMPANY's own pool through the check meant for snipe targets. That check only accepts tokens whose recorded origin is the launch contract used for sniping. If the launch contract that created COMPANY (ProjectFactory) is a different contract, every burn reverts with InvalidLaunch.
   • Before admission, the services need reviewed adapter code (or verified addresses) for both, plus evidence that ProjectFactory is that same launch contract.

2. Low: burnExpired can never close a batch that is down to rounding dust when COMPANY is paired with ETH (src/CompanyStaking.sol:180). ETH is the default pairing. Once stakers claim, a few wei of IMD can be left over. That amount converts to 0 wei of ETH, and the zero quote makes the call revert. The batch is never marked burned, and the website keeper would retry it forever. I reproduced this: with stakes of 1 and 2 tokens and 10 tokens of reward, 1 wei is left, and the burn still reverts 400 days later.

3. Low: profitable sell and emergencySell on ETH-paired positions are blocked whenever the IMD/ETH price quote is more than 15 minutes old (src/SniperVault.sol:269). The stakers' share is converted from ETH to IMD inside the same transaction as the sale. I reproduced this: a position at 5x reverts on both calls when only the IMD/ETH quote is stale.

What held up: the claim window and burn boundary (no gap or overlap), stake-time weighting and its history records, reward accounting, staked COMPANY never being touched by burns, the take-profit ladder (settings frozen at buy time, each level once, proportional cost basis), the snipe limits (2% of supply, spend budget, slippage, exact balance checks), approvals being reset, reentrancy locks, and owner-only permissions. No keeper call can send vault funds anywhere except the swap venue and the staking contract.

None of the static-analysis warnings turned out to be real defects. The strict-equality checks are intentional, the flagged "uninitialized" locals start at zero by design, and ETH sent to staking is used up in the same transaction. There is no launch.json yet, so the manifest was not reviewed.

Coverage: all 25 entry points have a row, plus three checked invariants. Every row is either "holds" or tied to a finding; none are unreached.

Several dotfiles (.bashrc, .gitmodules, .idea and others) now appear as untracked in git status. They are placeholder device files the sandbox mounts, not something the review created, so I left them alone.

Created launch.json as a schema-valid draft—the only submission change.

forge build succeeded; all 62 existing tests passed. The manifest deployment probe fails with InvalidConfiguration: six missing integration values remain explicitly documented zero placeholders. The manifest is not deployment-ready.

Review complete. .imd-findings.json is written at the repository root (valid JSON, all four snippets match the tree at the cited lines, 28 coverage rows covering all 25 listed entry points plus three invariants). No tracked files were changed; test/scratch/Leads.t.sol is my scratch reproduction and is not kept.

Summary of the Access Control / Trust Gap / Asymmetry review

Permission model is consistent with the brief. Every SniperVault admin surface is onlyOwner against an immutable constructor-supplied owner ($owner, never msg.sender); the keeper can reach only snipe and sell, both of which swap against the fixed venue with recipient = address(this) and route only the computed reward to the fixed staking contract. pause gates snipe alone; sell, emergencySell, withdraw and withdrawAll work while paused, as required. CompanyStaking has no privileged function, principal is balance-checked unchanged across burns, and the claim and burn windows are disjoint. No standing approvals, initializers, proxies or escalation routes exist. The existing 62 tests pass and the ABI export check is clean.

Findings (4, none high):

1. Medium — trust gap at the deployment boundary. The brief's rule "token must come from the IMD launch contract on Robinhood Chain, paired with IMD or ETH" is enforced only through two immutable adapter contracts (ILaunchRegistry, ITradingVenue) that are not in the deliverable and have no supplied canonical addresses. The constructor accepts any nonzero address; with code-less placeholders, snipe and burnExpired revert forever and any IMD funded via notifyReward is permanently stranded (reproduced). The manifest cannot be completed with reviewed values as things stand; I named the evidence needed.
2. Low — asymmetry between exit variants. emergencySell on a profitable ETH-paired position reverts with InvalidQuote when the IMD/ETH quote is stale, because it shares the reward-conversion path with the ladder sale; the owner must first setStakerShareBps(0) or use withdraw (reproduced).
3. Info — trust assumption. stakerShareBps is read live at sale time with no floor, so the owner can zero it in the same block as a sale; disclosed in the README, within the brief's granted powers.
4. Info — trust assumption. maxSpendBps is per-snipe, not aggregate; a compromised keeper sniping 20 launches at 10% moved 85% of the vault (reproduced); disclosed in the README.

Coverage limits: I did not evaluate the economic soundness of the venue's quote methodology (TWAP vs spot) or MEV on the permissionless burnExpired beyond noting its fixed 10%-per-hop allowance; those belong to the economics specialist and depend on adapter implementations that do not yet exist. No live network data was available to verify any chain address.

The findings file is in place and is excluded from git by the harness's own exclude rule, the scratch directory is gone, and the working tree is otherwise clean.

Review result

The math in both application contracts holds up. I found no critical, high or medium defects in the Math Precision, Boundary or Numerical Gap areas. Two low-impact seams were substantiated and written to .imd-findings.json, with a coverage row for all 25 listed entry points plus four invariants.

Findings recorded

• Low, SniperVault line 269. For an ETH-funded position, the staker share is converted ETH to IMD through a quote that reverts on zero. A nonzero wei share that rounds to zero IMD units blocks the whole ladder sale or emergency sale. This only bites on dust-sized positions (profit around 1e-9 ETH with a 6-decimal IMD), and the owner can still withdraw, so no funds are lost. Suggested fix is to treat an unrepresentable share as zero reward rather than revert.
• Info, CompanyStaking line 178. An expired batch whose unclaimed remainder is a few wei of IMD can never be closed if that dust quotes to zero COMPANY, so the liability counter carries it forever. The docs call this retryable, but a permanently sub-unit remainder is not. Accounting only.

What was checked and held

• Snipe budget, 2% supply cap and slippage-adjusted exact-output maximum: fuzzed spend never exceeded the budget under 90 to 100% execution quality.
• Ladder tranche sizing, ceil-rounded targets, slippage floor and proportional cost removal: fuzzed proceeds always met the multiple, cost basis summed to entry cost after partial withdrawals.
• Stake-seconds integrals, binary search, same-timestamp replacement, claim and burn windows being disjoint and gapless, and claim sums never exceeding the funded amount with up to 12 stakers.
• Every division, downcast and sentinel ETH branch in Trading, plus the exported ABI files, which are byte-identical to the compiled artifacts.

Not reached in depth. Economic manipulation of venue quotes and the registry trust model are outside my area and only noted as trust assumptions already documented by the author. No manifest exists in the tree yet, so constructor values could not be reviewed against it.

The economics review is complete. Findings are in .imd-findings.json at the repository root with six findings and a coverage row for all 25 entry points plus five invariants. The only other change made during the review, a scratch test directory, has been removed, so the working tree is clean apart from the findings file.

What I found

No critical or high defects. The vault and staking accounting held under every invariant I traced: IMD balance versus reward liability, COMPANY balance versus total staked, per-snipe spend and supply caps, once-per-level ladder execution, proportional cost basis after partial owner withdrawals, and claim/burn window consistency. Existing tests pass. All six findings were reproduced numerically with scratch Foundry tests before being written up.

• Medium. Expired IMD in CompanyStaking has one exit, burnExpired, which requires a working registry and venue. The deliverable contains no implementation of either, the constructor cannot detect a non-conforming address, and no launch.json exists yet. A wrong address permanently locks every unclaimed batch. The manifest stage needs accepted adapter source or verified canonical addresses before it can fill those six constructor arguments.
• Low. Rewards are split over the whole UTC day, so a whale who stakes after seeing a funding event takes about 91 percent of that batch in my scenario. This matches the brief's wording and is reported as an incentive defect for the author to accept or adjust.
• Low. An ETH-funded take-profit sale reverts when the unrelated IMD/ETH conversion quote is stale. Only the owner can unblock it, by zeroing the staker share.
• Low. The burn tolerates 10 percent below quote on each hop. On the ETH-paired route that compounds to a 19 percent accepted shortfall, which a sandwich of the permissionless burn can capture.
• Info. Two documented trust assumptions recorded for the judge: the owner can exit positions by withdrawal without paying stakers, and the per-snipe spend cap is not aggregate, so a compromised browser keeper can route most of the vault into attacker-created launches over many calls.

Coverage

Every listed entry point has a row. The manifest row is marked unreached because no launch.json is present. No proofs were attached since no finding reached high severity.

Added 16 tests covering failure paths, boundaries, arithmetic fuzzing, and three invariant campaigns totaling 49,152 random calls. All changes are under test/.

forge build passes. forge test: 78 passed, 0 failed, 0 skipped.

No confirmed contract defects found. Live adapter compatibility remains unverified.

Review complete. All eight findings and all 27 coverage rows are in .imd-findings.json, every snippet verified against the tree, and no file outside the findings file and test/scratch/ was changed.

Outcome. The launch cannot deploy as described, and the source itself has one medium liveness defect plus several low and informational items. The code's access control, accounting and reentrancy handling held up under tracing; 78 existing tests and the ABI export check pass.

Findings kept, after reproducing each in test/scratch/Repro.t.sol:

1. High, launch.json line 12. CompanyStaking's six integration arguments are zero placeholders and chain id "0". The Trading constructor rejects every one of them, so the factory deployment fails before SniperVault is reached. Merged with the three specialists' "no registry/venue adapter exists" findings, since that is the real gap: no reviewed implementation of either port exists anywhere in the tree, and a wrong substitute strands every expired reward batch forever because CompanyStaking has no rescue path.
2. Medium, src/SniperVault.sol:269. For ETH-funded positions, sell and emergencySell revert whenever the unrelated IMD/ETH conversion cannot be quoted, either stale beyond 15 minutes or a share that rounds to zero IMD. Four specialists reported facets of this; merged into one. The keeper has no bypass and the owner's only workaround forfeits the stakers' share.
3. Low, src/CompanyStaking.sol:180. Claim dust that quotes to zero output can never be burned, so those batches stay open forever and the website keeper retries them indefinitely. The README calls this "retryable" but no retry can succeed.
4. Low, src/CompanyStaking.sol:181. The 10% burn tolerance compounds per hop to 19% on the ETH-paired route the manifest selects. Reproduced with 1620 of 2000 reference COMPANY burned.
5. Low, src/CompanyStaking.sol:101. Whole-day batch splitting lets a staker who enters after seeing the funding event capture most of that batch. Follows the brief's wording, so flagged for the author to accept or adjust.
6. Low, docs/dependency-sha256.txt:46. This is new from my own pass. The dependency hash list the docs tell reviewers to verify fails on 10 of 47 files, including the production SafeERC20, Math and Address files, and never matched even in the commit that introduced it. The code reads as genuine OpenZeppelin v5.1.0 logic, apparently reformatted, but the sandbox refused GitHub so upstream identity stays unverified.
7. Info. Two merged trust assumptions: the stakers' share is a live owner setting with no floor and no snapshot, and maxSpendBps is per-snipe rather than aggregate.

Dropped or demoted. Nothing from the specialists failed to reproduce. The ETH-share dust case was folded into finding 2 rather than kept separately, and the two "expired dust" reports were merged into finding 3.

Coverage. All 25 entry points are answered, none unreached, plus two invariant rows. No proof files were attached: the only high finding is in the manifest, where no Foundry test can fail now and pass after the fix.

Fixed ETH-sale quote failures, burn-dust closure, compounded slippage, and dependency checksums. Preserved the three approved economic behaviors.

All seven verdicts are recorded in .imd-responses.json. Updated ABIs and operational documentation cover reward retries and permanently retained burn dust.

Validation passed: forge build, all 84 tests, offline tests with an empty environment, formatting, ABI checks, and all 47 dependency checksums.

the task produced no changes; the agent's last message was: Blocked by the execution environment: repository reads, forge build, and forge test all failed before starting with bwrap: setting up uid map: Permission denied.

Writing .imd-responses.json also failed. No changes were made; the finding remains unresolved. The sandbox must be repaired before this revision can proceed.

Confirmed the finding; it remains unresolved. Six verified deployment inputs and compatible registry/venue evidence are missing, so launch.json is unchanged.

Recorded the required response in .imd-responses.json, disputing repairability within the assigned scope—not the defect.

forge build succeeded. All 88 tests passed, including four reproductions confirming the failures.

Extended the existing invariant tests for deferred ETH reserves, failed retries, stale quotes, and dust accounting. Added two deterministic regression tests. All changes are under test/.

Validation: forge build passed; forge test passed 102 tests, with zero failures or skips.

Live Robinhood integration remains unverified; tests use local mocks.

dependency did not apply: fatal: transport 'file' not allowed

Review complete. The findings file is written at .imd-findings.json with 5 entries and a 30-row coverage record, and the scratch tests were removed so the tree is otherwise unchanged.

Settlement of my round-1 findings

• Still open, high: manifest zero placeholders. launch.json is unchanged. Lines 14 to 19 still pass six zeros to CompanyStaking, and the constructor in src/lib/Trading.sol rejects them. The author concurs it is a blocker and disputes only that a manifest-only assignment can fix it, which I agree with. It needs adapter source for the registry and venue ports (or verified canonical addresses), the IMD address, pool id and chain id, and evidence the registry reports COMPANY with the factory as origin. No Foundry proof is attached because a test that passes once the manifest is fixed would have to read launch.json, and foundry.toml grants no file permissions.
• Fixed, medium: ETH-funded sales blocked by the IMD/ETH quote. Reproduced the stale and dust cases on the new code. Both sales complete, the share is booked as reserved ETH, the owner cannot withdraw it, a stale retry rolls back cleanly, and a fresh retry funds staking.
• Fixed, low: dust batches unburnable. Both the ETH-paired and IMD-paired routes now close with the wei retained in a separate dust total.
• Fixed, low: per-hop slippage compounding. The 0.9 x 0.9 case now reverts atomically, and 0.95 x 0.95 burns 1805e18 as expected.
• Fixed, low: dependency hashes. The checksum file passes for all 47 files. The network was reachable this round, so I fetched the OpenZeppelin v5.1.0 and forge-std v1.9.7 archives: 37 files are byte-identical and the other 10 equal forge-fmt output of upstream, exactly as the author documented.
• Accepted as approved design: whole-day batch split, zeroable staker share, per-snipe keeper cap. All three reproduce in the author's own tests, match the brief's wording, and are now disclosed in the security doc. Recorded as info trust assumptions, not defects.

One new observation, info only. The dust fix retires a batch of any size on a single fresh zero-output quote, with no size bound or second probe. A conforming reference-price venue cannot produce that for a large batch, and the interface now forbids it, but ordinary DEX quoters do return zero with a current timestamp for an empty pool. Whoever supplies the venue for the open finding must verify this property. A cheap guard would be to retire dust only when a scaled probe amount still quotes nonzero.

Other checks run: full suite passes (102 tests), the ABI export check passes, manifest notes and argument lengths are within schema limits, and I traced the new reserve accounting to confirm the vault's ETH balance can never fall below the pending reward total.

The finding reproduces and remains unresolved. Repair requires six approved constructor values and verified registry/venue implementations; launch.json is unchanged.

Recorded the evidence and scope limitation in .imd-responses.json.

forge build succeeded. All 88 tests passed, including four confirming the reported failures. The manifest remains undeployable.

Review complete. .imd-findings.json is written with 5 findings and a 29-row coverage record (all 26 entry points answered). I changed no repository files; only .imd-findings.json and the scratch test test/scratch/Settle2.t.sol are new, and git status shows nothing else.

Settlement of my prior findings

[high] launch.json zero placeholders — NOT FIXED, kept at high. The author's answer agrees it reproduces and disputes only that a manifest-only assignment can repair it. The tree confirms that: git diff b8a88bf HEAD -- launch.json is empty and src/ is byte-identical to what I reviewed last round (only test files changed in 09d8877). Re-reproduced with four scratch tests, all passing on this tree:

• new CompanyStaking(token, 0, 0, 0, 0, bytes32(0), 0) → InvalidConfiguration (src/lib/Trading.sol:41-44)
• a copy of the protected probe's deploy with the manifest's args → "project constructor failed"
• codeless venue 0x1234 → constructs, notifyReward(1000e18), then after day+8 burnExpired reverts, claim reverts, 1000e18 IMD and rewardLiability stranded permanently
• registry reporting COMPANY under a different factory → burnExpired reverts InvalidLaunch forever

No Foundry proof is attached, deliberately: the fix lives in launch.json, reading it needs fs_permissions that foundry.toml doesn't grant, and a test hard-coding the zero args would keep failing after a correct fix. The needed inputs are unchanged: reviewed adapter source for both ports (or verified canonical addresses with code/ABI evidence), the IMD address / IMD-ETH pool id / chain id, and evidence the registry reports COMPANY with origin == launchFactory_.

Four advisories (info) — carried forward unchanged as disclosed trust assumptions: whole-batch dust retirement on a fresh zero quote, owner's ability to zero stakerShareBps/withdraw inventory, per-snipe maxSpendBps, and whole-day batch dilution. Each still has a passing reproduction in test/ApprovedEconomics.t.sol or scratch.

Specialist findings this round

Their reports describe the pre-fix code; I verified each against the current tree:

• Merged into finding 1: audit_flow #1, audit_permissions #1, audit_economics #1 (registry/venue gap).
• Dropped — fixed in the current code, confirmed by scratch tests: tiny-ETH-share revert (math #1) now defers to pendingRewardsEth (240 wei in the repro); stale IMD/ETH quote blocking sell/emergencySell (flow #3, permissions #2, economics #3) now defers and anyone can fundPendingRewards; dust batches unburnable (math #2, flow #2) now close with totalImdDust == 1; per-hop slippage compounding to 19% (economics #4) — 10%-per-hop execution now reverts "slippage" and 5%-per-hop passes, because the final bound is the full-route quote.
• Merged into the infos: permissions #3/#4, economics #2/#5/#6.
• Slither/aderyn leads (strict equalities, uninitialized locals, zero-check on setKeeper, "locks ether"): traced, none a defect — the ETH-paired burn leaves address(staking).balance == 0 and receive() rejects non-venue senders.

Full suite: 102 passed, 0 failed. Documented ABIs match the compiled artifacts (sha256 of normalized JSON equal for all three contracts).