Approved workflow

Boundary x precision seam in _checkValue. The allowed change is floor(_value * maxDeviationBps / 10_000). With the manifest value maxDeviationBps = 2000, any accepted _value in 1..4 yields an allowed change of 0, so while that value is fresh every report or attestation that differs from it reverts ExcessDeviation, and re-reporting the same value renews _updatedAt and keeps the freeze alive.

The NatSpec says the band re-anchors only after maxAge so an immutable feed is never permanently unable to follow a genuine move; at this boundary the feed cannot move at all until the reporter lets it go stale (86400 s in the manifest). For values 5..9 the band is 1 wei, so a quorum-one reporter needs roughly 200 chained same-block reports to climb back to 1e18 scale.

Reachability needs a mis-scaled reporter input (for example 4 instead of 4e18), so this is a trusted-input precondition; the unprivileged amplifier is that during the freeze every debt position reads CR ~0 against a 4-wei price and liquidate() pays floor(debtToRepay * 1.1e18 / 4) IMD per COMP burned, so liquidators can seize whole positions for wei of COMP once the NHI grace elapses, and the reporter has no way to correct the price for up to maxAge.

Same code path governs NhiFeed. Minimal fix that preserves the design: enforce a floor of at least 1 on the allowed change, or reject values below 10_000 / maxDeviationBps on both accept paths, since a scaled-1e18 figure that small is never meaningful.

Area: Economic Security / Invariant (supply <= backing). liquidate() pays floor(debtToRepay * 1.1e18 / price) IMD and reverts when that exceeds the owner's collateral. Once a position's collateral is worth less than 110% of its debt at the accepted price, only a partial liquidation of at most collateral*price/1.1e18 COMP can execute; it seizes essentially all collateral and leaves the remaining debt with zero collateral.

No function can ever retire that debt except the owner's own repayCOMP, and an owner with 1 wei of collateral has no economic reason to repay. The COMP that funded it stays in circulation with nothing behind it, so the protocol invariant 'COMP supply is backed by collateral (debt part) plus work' silently breaks and stays broken.

The state is reachable through the manifest's feed configuration without any malicious actor: the single reporter (quorum 1, maxDeviationBps 2000) can and must submit several rounds in one transaction to follow a genuine >20% move, and two rounds (x0.8, x0.8) take a 150%-collateralized position to 96% in one block, below the 110% payout.

README.md and docs/REVIEW_NOTES.md acknowledge 'no bad-debt insurance' and 'partial liquidation may leave bad debt', so this is reported as a documented economic gap rather than an unexpected defect; the requester should decide whether the accepted design needs a shortfall path (e.g. allow a liquidator to take all remaining collateral against the full remaining debt, or a socialization/insurance mechanism) before COMP is treated as a stablecoin.

Area: Flow Gap (execution x periphery x first principles). The stated guarantee is that an underwater position gets an NHI-derived grace window (up to 6 hours) before it can be liquidated. The mark is only removed by an explicit transaction (deposit/repay/mintCOMP/withdraw by the owner, clearRecoveredMark by anyone, or a liquidation that restores health).

A recovery caused purely by a feed update (the periphery) leaves the mark in place; markUnderwater returns early while the old mark is unexpired, and liquidate only checks that the position is underwater NOW and that markedAt+grace has passed.

So if the price recovers and then dips again at any time within markedAt + grace + liquidationWindow (grace + 86400 s with the manifest's maxAge), a liquidator can burn COMP and take 110% in the same block as the dip, with zero effective grace for that new episode.

The NatSpec on markUnderwater/clearRecoveredMark documents this tradeoff and tells borrowers to call clearRecoveredMark; it is reported here because the economic consequence (a 10% collateral penalty without the promised grace) falls on a borrower who was healthy for hours and never transacted, and a liquidator is incentivised never to clear marks.

A minimal preserving fix would be to store the feed round/updatedAt at mark time and require the position to have been underwater at every accepted update since, or to reset grace when liquidate observes a feed update newer than the mark; either changes accepted liquidation logic and is therefore a scope decision for the requester.

Asymmetry between the two constructor link checks. A nonzero oracle_ goes through validateOracle (line 247-255), which rejects an oracle whose vault() is not this vault. A nonzero compToken is only checked for code and for not equalling imdToken_; nothing checks that compToken_.vault() is zero (deferred mode) or this vault.

A vault constructed against a CompToken that is already bound to another vault deploys successfully, exposes depositCollateral/withdrawCollateral, and can never mint (mintCOMP reverts NotInitialized forever because CompToken has no second setVault). The launch manifest passes 0x0 for compToken_ so the launch path is unaffected; the gap only bites an assembled-mode or redeploy misconfiguration, and depositors can always withdraw debt-free collateral, so there is no fund loss.

The mirror check that the oracle path already performs (accept vault()==0 or vault()==address(this), otherwise revert InvalidToken) would close it. test_zeroArgumentsDoNotBypassCollateralOrDistinctFeedGuards covers no-code and imd==comp only, not a foreign-bound token.

Asymmetry between mark and liquidate: liquidate re-reads minCR() live from the NHI feed (via _healthy) but reuses the grace snapshotted at mark time (mark.grace), and markUnderwater refuses to refresh an active mark. When NHI is at or below 0.60 the grace is zero; if NHI then rises to 0.85 (minCR 150, gracePeriod() 6 hours) the position may be healthy again with no transaction observing it, so the zero-grace mark persists for markedAt + 0 + liquidationWindow() (86400 s).

Any later dip under 150% CR within that day is liquidatable in the same block by any liquidator, although the live NHI promises six hours of grace.

The NatSpec at lines 183-184 documents this and points borrowers to clearRecoveredMark while healthy, and the workflow accepts the liquidation logic, so this is reported as a documented guarantee gap for the judge rather than as a code change request: any fix (e.g. re-snapshotting grace when the live gracePeriod() exceeds the stored one, or voiding a mark whose position was observed healthy) changes accepted liquidation logic and needs a scope decision.

Authorization documentation conflict. launch.json passes $owner as relayer_ and reporter0_ to PriceFeed and NhiFeed with quorum 1, so the policy owner alone sets the collateral price and NHI that gate every mintCOMP, withdrawal, mark and liquidation.

README line 45 says 'No constructor consumes a $owner argument' and that the policy owner receives no authority; README line 29 and 33 still describe a fixed 1:1 price that 'never changes'; README lines 49, 67 and 71 describe a two-contract mode A and a CDPVault.setOracle function that no longer exists in src/CDPVault.sol or docs/abi/CDPVault.json. The workflow (line 9) asks that the NatSpec and README state the current consequence.

The services and frontend that read the README to enumerate privileged parties would omit the feed reporter, which is the most powerful role in this deployment (see finding 4). No code defect; the fix is documentation only and lies with the source-producing assignment.

Access x economics seam, documented for the judge, not a code defect: SwarmFeed NatSpec (lines 167-168) acknowledges a quorum-one reporter can complete multiple rounds per block, so the 2000 bps deviation bound is not a bound against the reporter (two 20% steps take NHI from 0.85 to 0.544; n steps take the price anywhere).

CDPVault derives minCR (150..200) and grace (6h..0) from NHI alone, so a reporter NHI update to <= 0.60 turns every position with CR below 200% into a zero-grace liquidation target for any unprivileged liquidator (the asymmetric-formula amplifier), and a price update does the same for CR. The workflow names the policy owner as sole reporter and relayer and accepts the feed design, and the reporter has no direct fund access, so this is the trust boundary the launch relies on.

Evidence gap for services: the workflow requires $owner to resolve to miyagod.eth 0x5167d014a056e43883e1bbea5530c3c0dc993281, which is also the hard-coded APPROVED_OPERATOR in src/DeploymentConfig.sol line 8 (faucets).

If the launch_policies row resolves $owner to any other address, the deployment has two distinct privileged parties (feed controller vs faucet operator) contrary to the approved workflow; admission should check the policy owner equals 0x5167d014a056e43883e1bbea5530c3c0dc993281 before deploying. This cannot be verified from the tree.

The workflow requires the self-contained mode's consequences to be stated in the README, but the README still documents the earlier increment. Line 54 (Mode A table) and lines 60-67 (Mode B table) list CDPVault with three constructor arguments, while the compiled constructor and docs/abi/CDPVault.json take five (imdToken, compToken, oracle, priceFeed, nhiFeed).

Line 45 states 'No constructor consumes a $owner argument', but launch.json lines 18 and 21 (PriceFeed) and 32 and 35 (NhiFeed) pass $owner as relayer and reporter0, so the policy owner does hold authority (sole feed reporter and relayer) that the README says nobody receives.

Line 29 says 'The price never changes' and liquidation tests 'inject hypothetical collateral loss with test-only storage writes', and line 33 says 'No price feed ... is implemented'; the vault is price-aware and test/Liquidation.t.sol drives every unhealthy position through feed values. docs/REVIEW_NOTES.md line 33 likewise tells the manifest node to list CDPVault($contract:MockIMD, 0x0, 0x0). docs/ABI.md and launch.json are correct; only the README and review notes are stale.

Impact: an operator, frontend author or manifest author following the README builds the wrong constructor call and misreads who can move the price and NHI. No on-chain defect.

The workflow states the sole relayer and reporter is the policy owner, which 'must resolve to miyagod.eth 0x5167d014a056e43883e1bbea5530c3c0dc993281', and the manifest notes repeat that '$owner ... must match the workflow-approved operator'. Nothing in source enforces it: src/DeploymentConfig.sol pins 0x5167... for MockIMD.mint and MockWorkOracle.grantRights, while PriceFeed/NhiFeed take relayer_ and reporter0_ from the manifest's $owner.

If the validated launch_policies row's owner differs, the launch still deploys (SwarmFeed's constructor only rejects a zero reporter set), but two keys must cooperate: one to seed price and NHI (without which every feed-dependent vault action reverts StaleFeed), the other to mint test IMD and grant work rights.

No funds are at risk and this is not a code defect; it is the configuration evidence the admission step needs: the launch_policies owner value for policyVersion, shown equal to 0x5167D014a056E43883e1BBEa5530c3c0dC993281. If it is not equal, the README's single-operator description and the manifest notes are wrong for this launch.

test/Liquidation.t.sol and test/Protocol.invariant.t.sol use TestSwarmFeed, whose setValue ignores the deviation bound and whose staleness is a manual flag.

The only test that liquidates through real SwarmFeed subclasses (test/SwarmFeed.t.sol:358, test_realFeedsExpireDuringGraceAndMustRefreshBeforeLiquidation) uses maxDeviationBps 10000, maxAge 1 hour and the assembled CompToken(0)+setVault path, not the manifest's self-contained constructor or its 2000 bps / 86400 s parameters. The self-contained invariant keeps price and NHI fixed.

Consequently the interaction that the launch actually relies on (a quorum-one reporter chaining <=20% moves to reach a liquidating price, a 6 h grace inside a 24 h feed lifetime, and a stale re-anchor after the mark window) is untested in the committed suite. I reproduced that path in a scratch test on this tree and it behaves as documented, so this is a coverage note rather than a defect.

Merged from audit_economics finding 1 and my own self-liquidation trace of the same root cause. liquidate() pays floor(debtToRepay * 1.1e18 / price) IMD and reverts when that payout exceeds the owner's collateral. Once collateral is worth less than 110% of debt at the accepted price, only a partial liquidation of at most collateral*price/1.1e18 COMP can run; it takes essentially all collateral and leaves the rest of the debt with zero collateral.

No function other than the owner's own repayCOMP can retire that debt, and the owner has no reason to repay. Because self-liquidation is allowed, the borrower is the natural first liquidator: with 150 IMD posted and 100 COMP borrowed, after price 1.0 -> 0.8 -> 0.64 the borrower burns 87.27 COMP, receives 149.999999999999999999 IMD (all but 1 wei of the collateral) and walks away holding 12.73 COMP against a 12.73 COMP debt backed by 1 wei.

The 'each debt is over-collateralised' invariant is broken permanently for that position. The path is reachable with the manifest's feed configuration (quorum 1, maxDeviationBps 2000, maxAge 86400): two 20% reports inside one grace window, or one report in the same block pair, are enough.

Reported low, not medium: COMP holders have no redemption claim on IMD, mintFromWork already creates COMP with no collateral by design, README line 39 and docs/REVIEW_NOTES.md line 47 state 'no bad-debt insurance or socialization' and 'partial liquidation may leave bad debt', and the approved workflow declares the vault's economics and liquidation math accepted and out of scope for this increment.

It is recorded so the requester can decide whether a shortfall path is wanted before COMP is presented as a stablecoin; any fix changes accepted liquidation logic and needs a scope decision.

Merged from audit_economics finding 2 (price recovers then dips) and audit_permissions finding 2 (grace snapshotted at zero while NHI <= 0.60 persists after NHI recovers to 0.85); both are the same root cause.

A mark is only removed by an explicit transaction (owner deposit/repay/mint/withdraw, anyone's clearRecoveredMark, or a liquidation that restores health). markUnderwater returns early at line 174 while the old mark is unexpired, and liquidate at line 203 compares block.timestamp against the stored markedAt and stored grace while reading health live.

A recovery caused only by a feed update therefore leaves the stale snapshot in place, and any new underwater episode within markedAt + grace + liquidationWindow() (grace + 86400 s with the manifest's maxAge) can be liquidated in the same block as the dip, taking the 10% bonus from a borrower who was healthy for hours and never transacted.

The NHI variant is worse in effect: a mark taken with grace 0 stays actionable for 24 h even after the live gracePeriod() returns to six hours.

The NatSpec on markUnderwater and clearRecoveredMark (lines 164-168, 180-184) documents exactly this tradeoff and tells borrowers to clear marks while healthy, and the workflow accepts the liquidation logic, so this is a documented guarantee gap for the requester rather than a code change request; keepers have no incentive to clear marks, so the burden falls on borrowers and the frontend, which the workflow says must show a grace countdown.

A fix (voiding a mark once an accepted feed update shows the position healthy, or re-snapshotting grace when the live gracePeriod() exceeds the stored one) changes accepted liquidation logic and needs a scope decision.

From audit_math, reproduced. The allowed change is floor(_value * maxDeviationBps / 10_000). With the manifest's maxDeviationBps = 2000 any accepted value in 1..4 yields an allowed change of 0, so while that value is fresh every report or attestation that differs reverts ExcessDeviation, and re-reporting the same value renews _updatedAt and keeps the freeze alive; values 5..9 allow a 1 wei step.

The contract NatSpec says the band re-anchors only after maxAge so the feed is 'never permanently unable to follow a genuine large move'; at this boundary the feed cannot move at all for up to 86400 s.

Reaching it needs a mis-scaled trusted input (4 instead of 4e18) from the quorum-one reporter or a mis-scaled attested figure, so it is a trusted-input precondition; the amplifier is that during the freeze every debt position reads CR ~0 against a wei-scale price and liquidate() pays floor(debt * 1.1e18 / 4) IMD per COMP burned, so once grace elapses any liquidator seizes whole positions for wei of COMP and the reporter cannot correct the price until the feed is stale.

Same code path governs NhiFeed and submitAttestation. The feed logic is accepted and out of scope for this increment; a minimal preserving fix would floor the allowed change at 1 or reject values below 10_000 / maxDeviationBps.

From audit_permissions finding 1, reproduced. A nonzero oracle_ goes through validateOracle (lines 247-255), which rejects an oracle whose vault() is another vault. A nonzero compToken is only checked for code and for differing from imdToken_ (line 80); nothing checks that compToken_.vault() is zero (deferred mode) or this vault.

A vault constructed against a CompToken that is already bound elsewhere deploys, accepts deposits, and can never mint: mintCOMP and mintFromWork revert NotInitialized forever because CompToken has no second setVault. The git history shows the previous constructor had the same gap, so this is not a regression of the increment, and launch.json passes 0x0 for compToken_, so the launch path is unaffected.

Depositors can always withdraw debt-free collateral, so there is no fund loss. The mirror of the oracle check (accept vault() == 0 or vault() == address(this), otherwise revert InvalidToken) closes it. test_zeroArgumentsDoNotBypassCollateralOrDistinctFeedGuards covers no-code and imd == comp only.

Merged from audit_permissions finding 3 and audit_flow finding 1 (same defect). The approved workflow (line 9) requires the self-contained mode's consequences to be stated in NatSpec and README; the NatSpec and docs/ABI.md were updated, the README and review notes were not.

Concretely: README line 45 says no constructor consumes $owner, while launch.json lines 18, 21, 32 and 35 pass $owner as relayer and reporter0 of both feeds with quorum 1, making the policy owner the sole party able to set the price and NHI that gate every mint, withdrawal-with-debt, mark and liquidation.

README lines 54 and 60-67 list a three-argument CDPVault and a vault.setOracle call; the compiled constructor and docs/abi/CDPVault.json take five addresses and grep 'setOracle' over src/ and docs/abi/ returns nothing. README lines 29 and 33 say the price never changes and no price feed is implemented; the vault is price-aware and test/Liquidation.t.sol drives every unhealthy position through feed values.

README line 3 and line 81 omit SwarmFeed/PriceFeed/NhiFeed and their ABI exports. docs/REVIEW_NOTES.md line 33 tells the manifest node to list CDPVault($contract:MockIMD, 0x0, 0x0). No on-chain defect; an operator, frontend author or admission reviewer following the README builds the wrong constructor call and omits the most powerful role in the deployment. The fix is documentation only and belongs to the source-producing assignment.

Merged from audit_permissions finding 4 and audit_flow finding 2. Not a code defect; documented for the judge and the admission step. (a) Trust boundary: SwarmFeed NatSpec lines 167-168 acknowledge a quorum-one reporter can complete multiple rounds per block, so the 2000 bps bound does not bound the reporter.

CDPVault derives minCR (150..200) and grace (6 h..0) from NHI alone, so two NHI reports (0.85 -> 0.68 -> 0.544) turn every position under 200% CR into a zero-grace liquidation target for any COMP holder in the same block, and chained price reports do the same for CR. The reporter has no direct fund access, and the workflow names the policy owner as sole reporter and relayer and accepts the feed design, so this is the trust the launch relies on.

(b) Evidence gap: the workflow requires $owner to resolve to miyagod.eth 0x5167d014a056e43883e1bbea5530c3c0dc993281, which is also the hard-coded faucet operator here. The feeds take relayer_ and reporter0_ from the manifest's $owner while MockIMD.mint and MockWorkOracle.grantRights use this constant; SwarmFeed's constructor only rejects a zero reporter set.

If the validated launch_policies row's owner is any other address the launch still deploys, but feed seeding and faucets are split between two keys and the manifest notes and README single-operator description are wrong for this launch; if it is zero, both feed constructors revert InvalidConfiguration and the protected suite fails in setUp.

Needed evidence before deployment: the launch_policies owner for the selected policyVersion shown equal to 0x5167D014a056E43883e1BBEa5530c3c0dC993281. This cannot be verified from the tree.

From audit_flow finding 3, confirmed by reading the suite. test/Liquidation.t.sol and test/Protocol.invariant.t.sol use TestSwarmFeed, whose setValue ignores the deviation bound and whose staleness is a manual flag. The only committed test that liquidates through real SwarmFeed subclasses (test_realFeedsExpireDuringGraceAndMustRefreshBeforeLiquidation, line 358) uses maxDeviationBps 10000, maxAge 1 hour and the assembled CompToken(0) + setVault path.

The self-contained tests (SelfContainedFactoryDeploymentTest, SelfContainedDeployment.invariant.t.sol) use real feeds with 2000 bps / 1 day but keep price at 1e18 and NHI at 0.85e18 and never mark or liquidate. The interaction the launch actually relies on, a quorum-one reporter chaining <= 20% moves to reach a liquidating price, a 6 h grace inside a 24 h feed lifetime, and a stale re-anchor after the mark window, is therefore untested.

The scratch reproductions for findings 1, 2 and 6 exercise that path and it behaves as documented, so this is a coverage note, not a defect.