Approved workflow

Added the missing LaunchToken.sol: fixed 1 billion tokens, 18 decimals, no admin functions. Added six tests, ABI export, and documentation while preserving COMP behavior.

Passed: forge build, all 55 tests, forge fmt --check, and ABI consistency checks.

The existing factory-initialization conflict remains documented for deployment review.

Expanded unit/revert tests, uint128 fuzzing, invariants, and exact liquidation payout checks.

• Offline forge build and forge test pass: 78 tests.
• Invariants passed 32,768 random calls.
• Source coverage reports 100% across all five concrete contracts.

Reported two findings in .imd-findings.json: factory initialization authority is inaccessible, with a reproduced failing proof; and withdrawal-driven liquidation conflicts with the required health guard. Successful liquidation tests explicitly use synthetic collateral loss.

Fixed factory authorization by binding setup and faucet permissions to the approved workflow operator. Its two one-time initialization calls remain required; both permanently lock afterward.

Preserved the 150% withdrawal guard and clarified synthetic liquidation tests. Recorded both findings in .imd-responses.json.

Validation passed: build, 63 tests including the supplied proof, formatting, and ABI consistency.

Updated test setup calls to use the approved operator, preserving existing assertions and coverage. Only test/ files changed.

forge build passes. All 84 tests pass, including 1,000-case uint128 fuzz tests and 32,768 invariant calls.

Withdrawal-triggered liquidation remains incompatible with the 150% guard; documented synthetic fixtures verify exact liquidation math.

Created launch.json, the only submission change.

Schema/ABI validation and forge build passed. All 92 tests passed, including protected checks.

Manifest notes preserve existing source blockers: hard-coded privileged authority and required post-deployment initialization calls.

I found two problems, a medium and a low, both in how the contracts get linked together after deployment. The 84 existing tests all pass. I wrote the findings, with a coverage row for each of the 21 entry points plus two invariant rows, to .imd-findings.json. I changed no files; the scratch test I used to confirm both findings has been deleted.

Finding 1 (medium): after the launch, nobody can borrow COMP until one hard-coded wallet makes two more calls.

• What happens: once the factory deploys the contracts as launch.json lists them, CompToken.vault() and CDPVault.oracle() are both still unset. Every mintCOMP call then reverts with NotInitialized (src/CDPVault.sol:100).
• Only one wallet can fix it: setVault and setOracle can only be called by the constant APPROVED_OPERATOR in src/DeploymentConfig.sol:223. The launch process never makes those calls. If that key isn't available, or the policy owner is a different address, borrowing stays disabled permanently.
• Why it's a finding: the launch rules require contracts to be fully set up in their constructors and privileged addresses to come from policy ($owner), never hard-coded. The approved brief itself names this wallet and asks for the two follow-up calls, so this is a conflict between the brief and the platform rules, not a hidden backdoor. It still needs a decision before the launch is admitted.
• Possible fixes: either have CDPVault's constructor create CompToken and MockWorkOracle itself, so no follow-up calls are needed, or pass the operator in as a constructor argument filled from $owner. Both change the constructor signatures in the brief, so that choice is yours.

Finding 2 (low): if the operator links the wrong contract, borrowing is disabled for good.

• What happens: setOracle (src/CDPVault.sol:157) and setVault (src/CompToken.sol:200) only check that the address holds some code. Each can be called only once.
• Reproduced: I linked the vault to an oracle from a second deployment. The setup call succeeded, then every mintCOMP reverted with Unauthorized, and a second setOracle reverted with AlreadyInitialized, so there is no way to repair it. Linking the vault to the COMP token contract by mistake is accepted too.
• Fix: make each setter check that the other contract points back to it. Doing this fully for the oracle means adding a vault() function to the oracle interface, which you'd need to approve, because a real oracle is meant to drop in later.

What I checked and found sound

• Accounting and access: deposit, withdraw, repay and liquidate, plus access control on minting and burning COMP. The health check is exactly "collateral × 100 ≥ debt × 150" and can't overflow. The ratio display is rounded correctly. The liquidation payout matches the brief's debtToRepay*110/100.
• Invariants: total COMP supply always equals total debt, and every position with debt stays at or above 150%.
• ABI files: the ABIs in docs/abi match the compiled contracts.
• Static-analysis warnings: none held up. The reentrancy warnings are blocked by the reentrancy guard, and the collateral token has no transfer hooks. The division-before-multiplication warning is fine because the remainder is added back. There are no ETH transfers.
• Liquidation can't happen with real balances: at the fixed 1:1 price, no position can drop below 150%, so it only runs in tests that set up artificial state. That's by design, so I didn't report it.

Coverage:

• Mine: 15 entry points hold and 6 are tied to the two findings; none are unreached. I covered my three areas (execution flow, helper and library code, and assumptions in the code's own logic) in full.
• Other passes: I didn't run separate passes for the other specialties (economics, invariants, arithmetic and so on); I only checked where they overlapped with these paths.

The review is complete. Findings are in .imd-findings.json at the repository root, with three findings and coverage rows for all 21 listed entry points plus two invariant rows. No source files were changed, and the scratch tests were removed.

What I checked (Math Precision, Boundary, Numerical Gap)

• The health comparator in _healthy is exactly collateral*100 >= debt*150 with no overflow. A 2000-run fuzz over the mint and withdraw gates confirmed this at the ceil(1.5·debt) boundary on both sides.
• The ratio view splits quotient and remainder and reproduces floor(collateral*100/debt) exactly, with correct saturation. The slither divide-before-multiply lead is a false positive.
• The liquidation payout d + d/10 equals d*110/100 for every d, so rounding always favours the position owner and cannot be farmed by splitting.
• The reentrancy leads from slither and aderyn do not reproduce. Effects precede interactions, the guard is present, and MockIMD and CompToken have no transfer hooks.
• The exported ABIs under docs/abi/ are byte-identical to the compiled ones. The full suite of 84 tests passes offline.

Findings

1. Low. CDPVault.setOracle validates its argument only by code length. Passing a wrong contract, for example the MockIMD address, succeeds, erases the initializer, and leaves mintCOMP reverting forever.
2. Low. CompToken.setVault has the same gap and never checks the reciprocal compToken() getter on the vault. A wrong address leaves mintCOMP permanently NotInitialized.
3. Info. Below 110% collateral ratio, repeated partial liquidations can strip collateral to zero while debt remains, producing unbacked COMP that can never be liquidated. This state is unreachable through the contract at the fixed 1:1 price and is already acknowledged in the review notes, so it is recorded for the production feed design only.

Each finding carries a concrete input sequence that I reproduced in a scratch Foundry test before reporting. None reach high severity, so no proof files were attached.

The findings file is in place and is intentionally excluded from git by the harness. The scratch tests are removed, the working tree has no other changes, and the review is complete.

Result: the vault economics hold under the approved fixed 1:1 price. I recorded one medium finding and one informational note in .imd-findings.json, with coverage rows for all 21 entry points plus four invariants.

What I checked in my area (Economic Security, Invariant, Flow Gap):

• Conservation laws: COMP supply equals total debt, vault IMD balance covers all recorded collateral, and every indebted position stays at or above 150%. All three writers of debt and supply are coupled. The invariant suite passed at 256 runs and 32,768 calls, and I retraced each path by hand.
• Health arithmetic: the overflow-free comparison in the vault is exactly equivalent to the spec's collateral times 100 versus debt times 150, and the ratio view floors consistently with it. Slither's divide-before-multiply lead is a false positive.
• Liquidation math: the payout equals the spec's 110% formula, only the target's collateral is seized, and the burn comes from the caller. Rounding favours the protocol and cannot be farmed.
• Periphery seams: the exact-delta deposit check, SafeERC20, the reentrancy guard and the atomic rights-consume-then-mint ordering all held against the adversarial doubles. The slither and aderyn reentrancy leads do not reproduce.
• Manifest: schema-consistent with the constructors, dependency order and the launch token.

Findings:

1. Medium. A factory launch per launch.json leaves borrowing disabled. Both one-time links can only be completed by the EOA hard-coded in src/DeploymentConfig.sol, not by the factory or a policy-derived owner. If that address is not the policy owner, the launch is permanently inert. This is the conflict the manifest notes already disclose, recorded as a blocking review item for services.
2. Info. Between 100% and 110% collateral ratio, full liquidation reverts and partial liquidation makes the ratio worse, leaving unbacked COMP. This state is unreachable at the fixed price and matters only once a real oracle replaces the mock.

Not reached: no proof tests were attached, since neither finding is high or critical. The test suite's only liquidation coverage relies on injected storage, which is unavoidable under the fixed-price design.

Saved .imd-findings.json.

One medium finding: constructor-only deployment leaves required initialization unfinished, disabling borrowing.

Covered all 21 entry points. All 84 existing tests/invariant checks passed. No source files changed.

Saved .imd-findings.json with three deduplicated findings and coverage of all 21 entry points:

• Medium: Constructor-only launch leaves borrowing uninitialized.
• Low: Irreversible oracle setup accepts incompatible contracts.
• Low: Irreversible vault setup accepts another token’s vault.

forge build passed; forge test passed all 84 tests. Slither’s two alerts were rejected after tracing. ABI and manifest checks passed. Aderyn was unavailable; the protected service harness was not executed.

Selected model is at capacity. Please try a different model.

All three findings reproduced and are fixed. The revision is verified and the responses file is in place.

What was wrong

• Medium, constructor-only launch. A factory that runs MockIMD, CompToken, CDPVault and MockWorkOracle constructors leaves the token's vault and the vault's oracle unset, so borrowing reverts NotInitialized until the pinned operator makes two calls that no launch path performs. A four-contract manifest cannot close that cycle with constructor arguments alone.
• Low, oracle setter. The vault accepted any contract with code, so a mistaken target such as MockIMD locked initialization forever.
• Low, vault setter. CompToken accepted a vault bound to a different COMP token and burned its initializer.

What changed

• CDPVault has a self-contained mode. Given zero token and oracle addresses, its constructor creates CompToken and MockWorkOracle bound to itself and locks both links before returning. Both setters revert AlreadyInitialized from genesis for everyone, including the operator, so nothing remains to initialize and no policy owner authority is needed. The workflow's literal four-deploy-plus-two-calls order still works unchanged.
• CompToken now takes a constructor vault argument. Zero keeps the deferred operator path. The creating vault is accepted while it has no code. Any other target must have code and report this token from compToken(), or the call reverts InvalidVault without consuming initialization authority.
• The vault's oracle validation requires a working mintingRights view and, when the target exposes a vault() view as the mock does, that it names this vault. A drop-in IWorkOracle without that view is still accepted, so the interface is unchanged.
• MockWorkOracle accepts its creator as the vault so it can be built from the vault's constructor.
• README, ABI notes and review notes describe both modes and tell the manifest node to list MockIMD and CDPVault with zero token and oracle arguments, reading the child addresses from the vault. Only the CompToken ABI export changed.

Verification

• 66 tests pass, up from 61. New coverage includes self-contained CREATE and CREATE2 factory deployment from an unrelated relayer and origin with a full borrow cycle and no initialization call, every rejected mismatched link, and the opcode and size scan over the self-contained vault and its two created contracts.
• forge build, forge fmt --check, and the ABI export check all pass.
• The responses file answers all three findings as fixed. It is excluded from git by the harness's own exclude list, which is expected.

One point for the manifest stage: the pinned operator constant remains for the mock faucets, as the workflow names that address explicitly. No constructor consumes a policy owner argument, and I documented that a different faucet operator would need a reviewed source change.

Updated three boundary-test setups for CompToken’s current constructor and vault-link validation. Only test/ files changed.

Validation passed: forge build, all 89 tests, and 32,768 invariant calls with no unexpected reverts.

The documented requirements conflict remains: the 150% withdrawal guard prevents withdrawal-induced liquidation. Existing tests verify that rejection and use synthetic collateral loss to check exact liquidation payouts.

Updated launch.json to deploy MockIMD → CDPVault, which creates and links COMP and its oracle during construction.

Schema/ABI validation, forge build, and forge test passed: 101 tests, zero failures.

Only launch.json changed outside permitted scratch space. Notes retain the unresolved hard-coded mock-authority policy conflict.

Confirmed all three earlier findings fixed:

• Constructors now complete both links; borrowing needs no initialization calls.
• Oracle setup rejects incompatible and foreign-bound targets.
• Vault registration rejects targets bound to another COMP token.

All 89 tests passed offline. Six ABI exports matched compiled contracts; all 21 entry points were covered. No new reproducible defects.

Results saved to .imd-findings.json.

Implemented the frontend and static export.

• Build, typecheck, 15 browser scenarios and 9 unit/protocol tests passed.
• Verified export: 583 KB, with deployment manifest and ABI hashes.
• No live transactions sent.
• Validation and design documentation include evidence and limitations.

Root DESIGN.md was placed under docs/ to respect the write scope. Repository commit was blocked because .git is read-only; deliverable files are ready.