Failed on the agent's machine.

• mediumFeeHook charges the quote-specified fee on the requested amount, not on what the pool filledsrc/FeeHook.sol:140

  When the quote currency is the specified side of a swap (buy exact-input, sell exact-output), beforeSwap computes fee = specified * hookFeePips / PIPS from params.amountSpecified and takes it from the PoolManager before the pool runs. The pool may fill only part of the request: the swap reaches sqrtPriceLimitX96, or the active liquidity range is exhausted (the default limits of every v4 router). In v4 the trader's delta is swapDelta - hookDelta (lib/v4-core/src/libraries/Hooks.sol:316), so the full-request fee stays charged no matter how little traded. afterSwap does this correctly for the unspecified side (it reads swapDelta), so the two halves of the hook disagree.

  Economics (real PoolManager, 1e24 liquidity in ticks -6000..6000, 1% total fee, 25% to LPs):

  • Sell IMDEX for exactly 1,000 quote with a price limit 1e-6 above spot: the pool pays out 0.99999 quote, the hook takes 7.5 quote. The trader ends the swap with -6.5 quote AND -1.0025 IMDEX: they paid both currencies and received nothing. Effective fee 750%.
  • Buy IMDEX with 1,000,000 quote exact-input and the default price limit: the range absorbs 350,715 quote, the hook takes 7,500 (2.14% of what traded, 4,870 more than the 0.75% owed on the filled part). The overcharge is paid to the waterfall and split into the buckets, i.e. funds paid to the wrong party.

  Routers that enforce a strict min-output on the quote leg will revert such swaps; routers or direct unlock callers with a loose minimum, and every exact-input quote swap whose min-out is met, pay the overcharge. The brief asks the hook to 'collect the project-token swap fee'; a fee on volume that never traded is not that.

  Fix (keeps the design): charge the quote-specified fee on the filled amount. Either (a) in afterSwap, compare |swapDelta.specified| with the amount the pool was asked for (amountSpecified ± fee) and revert on a partial fill (PartialFillNotSupported), so a swapper never pays for an unfilled request; or (b) take only a provisional fee in beforeSwap and refund the difference on the unspecified side in afterSwap (negative hookDeltaUnspecified), documenting that the refund arrives in the other currency.

  whole finding

  State: hooked pool initialised at price 1:1 with liquidity 1e24 between ticks -6000 and 6000; swapFee 1% (lp 25%, hook 0.75%). Trader holds 100,000 IMDEX and 100,000 quote.

  Call: PoolManager.swap(key, {zeroForOne: false, amountSpecified: +1000e18 (exact-output quote), sqrtPriceLimitX96: SQRT_PRICE_1_1 * 1.000001}) through any unlock router.

  Expected: fee = 0.75% of the quote actually delivered (~0.0075 quote) or the swap refused.

  Actual: waterfall receives 7.5 quote; trader's quote balance changes by -6.5 quote and IMDEX by -1.0025; totalFeesCollected += 7.5e18.

  Second shape: swap(key, {zeroForOne: true, amountSpecified: -1_000_000e18, limit MIN_SQRT_PRICE+1}): pool consumes 350,715 quote, fee taken 7,500 instead of <= 2,650.

  Run: forge test --match-path test/scratch/HookPartialFill.t.sol -vv (both tests fail on the current code).

  whole reproduction

• mediumA keeper can quarantine every member with its own failing swaps and liquidate the whole basket in one block at the slippage floorsrc/RebalanceExecutor.sol:244

  The executor's three limits on a keeper (delta only, drift threshold, rebalance window) all hang on exit = target == 0, and _target returns 0 for any quarantined token. The executor itself quarantines a token after FailureThreshold (3) consecutive failed swaps (src/RebalanceExecutor.sol:124-127), and a failure is anything the keeper's own router calldata makes revert. Failures are counted per call with no time or block spacing, so a keeper submits three router.fail() calls per member in one block, every member becomes quarantined, and exit then allows sellAmount <= balance for each of them with no window, no drift check and no active-basket requirement (lines 254-259). Each sale only has to clear the oracle floor less MaxSlippageBps (1%), and the keeper chooses the venue.

  The only precondition for the failing trades is that a buy of each member is authorised at that moment (material deficit inside the window). The keeper manufactures that too: depositing 15% of NAV into the vault lifts every target by 2.94% of NAV, above the 2.5% drift threshold. A new epoch or any sizeable deposit gives the same opening.

  Economics (1,000,000 USDC vault, five members at 19.6% each, keeper deposits 150,000):

  • 15 failing calls, then 5 exit sales filled at 99% of oracle through the keeper's venue.
  • NAV 1,150,000 -> 1,140,200 USDC: 9,800 USDC (1% of the 980,000 invested) goes to the venue, i.e. the keeper's counterparty; the vault is 100% reserve, zero held tokens, and every member is quarantined, so nothing can be bought back until the timelock releases each one (>= 1 day each) and a window opens.

  SECURITY.md bounds the keeper to 'up to MaxSlippageBps of each allowed trade' and README says a keeper cannot 'exceed the delta'; here the keeper enlarges 'allowed' to the entire basket and converts the index to cash. The guardian can revoke the keeper afterwards, but the sequence completes in one block.

  Fix (keeps the design): a quarantine set by the executor should not by itself grant exit rights. For example, keep an autoQuarantined[token] flag in the executor and treat such tokens as not buyable but with their basket target intact (sells stay bounded by the excess over target and by the window) until the guardian or timelock confirms the quarantine; or count a failure only once per block/interval and require the failures to be spread over FailureThreshold distinct windows.

  whole finding

  State: Alice deposits 1,000,000 USDC; epoch 1 activates five tokens at 2000 bps; keeper buys each to target at oracle price (window open). Keeper then deposits 150,000 USDC so each member's deficit (29,400) exceeds the 2.5% drift threshold (28,750).

  Calls (all by KEEPER, same block): for each member, 3x executeTrade(usdc, member, 1000e6, 0, venue, abi.encodeCall(venue.fail, ())) -> each returns (false, 0); after the third, registry.isQuarantined(member) == true. Then for each member executeTrade(member, usdc, vault balance, 0, venue, swap filled at 99% of oracle) -> (true, ...).

  Expected: a position at its target cannot be sold at all, and never outside the delta.

  Actual: vault.heldTokens().length == 0, usdc.balanceOf(vault) == 1,140,200e6, NAV fell 9,800 USDC.

  Run: forge test --match-path test/scratch/KeeperLiquidation.t.sol -vv (fails on the current code).

  whole reproduction

• mediumSame-block deposit at feed NAV and in-kind redemption lets anyone take the feeds' lag from existing holderssrc/IndexVault.sol:134

  Deposits mint shares at navBefore, the sum of held balances valued at each Chainlink feed's last answer; redemptions pay a pro-rata slice in kind and need no price. Nothing links the two in time: deposit and redeem are separate nonReentrant calls and can run back to back in one transaction, there is no cooldown, and DepositFeeBps defaults to 0. A feed is 'fresh' for the registry as long as it is inside its heartbeat, but Chainlink only pushes a new answer when the price moves by the feed's deviation threshold (0.5%-2% for the ETH-ecosystem USD feeds this index would use). Whenever the market is up by less than that threshold, NAV is stale-low and the round trip deposit -> redeem -> sell is a riskless, flash-loanable transfer from existing holders (including the treasury's shares) to the caller.

  Economics (1,000,000 USDC vault fully invested, five members up 1.9% on the market, feeds unchanged):

  • Attacker deposits 1,000,000 USDC at the stale NAV and immediately redeems: receives 510,000 USDC plus half of every position.
  • At the true price the attacker holds 1,009,310 USDC of value for 1,000,000 deposited (+0.93%). Alice's slice falls from 1,018,620 to 1,009,310: she loses the same 9,310 USDC.
  • Profit scales with deposit size up to NAV (deposit = NAV captures half the lag); the deposit cap bounds it per vault, not per attacker, and the cap is the beta size. The maximum DepositFeeBps (100) does not cover a 2% threshold feed, and the default (0) covers nothing.

  README names feed latency as a known limitation with the cap and the optional fee as mitigations; the defect reported here is that the arbitrage is atomic and needs no capital or risk, which those two mitigations do not address.

  Fix (keeps the design): record lastDepositBlock[receiver] (or timestamp) in deposit and refuse redeem/transfer of shares minted in the same block, or impose a short minimum holding period; optionally set a non-zero default DepositFeeBps at or above the largest configured feed deviation.

  whole finding

  State: Alice deposited 1,000,000 USDC; basket of five tokens bought at $100 each (feeds at 100e8, fresh). Market price of each token is now $101.90 but no feed has crossed its 2% deviation, so every feed still answers 100e8 with updatedAt == block.timestamp.

  Calls (ATTACKER, one transaction): usdc.approve(vault, 1e12); shares = vault.deposit(1e12, ATTACKER, 0); vault.redeem(shares, ATTACKER, true).

  Expected: a deposit immediately redeemed returns at most what was deposited (the vault's own fuzz test asserts this at an unchanged price).

  Actual: attacker holds 510,000 USDC + 980.96 of each token; valued at $101.90 that is 1,009,310 USDC (> 1,000,000). previewRedeem(Alice) at the true price drops from 1,018,620 to 1,009,310 USDC.

  Run: forge test --match-path test/scratch/OracleLagRoundTrip.t.sol -vv (fails on the current code).

  whole reproduction

• lowA held token that becomes untransferable and loses its feed closes deposits and the basket-reserve push with no on-chain way outsrc/IndexVault.sol:320

  IndexVault._nav treats every held token with a non-zero balance and no fresh price as unpriced, and deposit reverts with PriceUnavailable for it (line 125), even when the token is quarantined. The executor's _nav deliberately counts a quarantined unpriced token as zero so the rest of the basket can trade, but the vault does not, so the two disagree. A token is only dropped from _held by endTrade when its balance reads zero, and the only ways to empty it are a keeper sale (needs a price) or the timelock's disposeQuarantined (needs the transfer to succeed). A token that both blocks transfers from the vault (honeypot, blacklist) and whose feed is deprecated therefore stays in _held forever, and with it: deposit reverts for everyone, and FeeWaterfall.pushBasketReserve reverts, so the 40% basket share of every swap fee accumulates in the waterfall and never reaches the vault. Redemptions keep working (strict = false). The timelock's only workaround is to re-approve the token with a stand-in feed contract that returns a tiny positive price, which the methodology does not foresee.

  Fix: in IndexVault._nav, treat a token that registry.isQuarantined and has no fresh price as zero value (mirroring RebalanceExecutor._nav), and/or let the timelock drop a quarantined, untransferable position from _held explicitly (writeOff(token)), with the holders' in-kind slice of it preserved.

  whole finding

  State: vault with Alice's 1,000,000 USDC invested in five members. Member T1 starts reverting transfers out of the vault (blockedFrom = vault) and its feed reverts; anyone calls registry.quarantineIfStale(T1).

  Calls: vault.deposit(100e6, Alice, 0) -> reverts PriceUnavailable(T1). usdc.mint(waterfall, 10_000e6); waterfall.pushBasketReserve(0) -> reverts PriceUnavailable(T1). Keeper executeTrade(T1, usdc, balance, ...) -> reverts PriceUnavailable. Timelock executor.disposeQuarantined(T1, balance, 1, venue, data) -> reverts 'transfers blocked'. vault.isHeld(T1) stays true; vault.nav() reports complete == false.

  Expected: a quarantined, failed asset is isolated and the rest of the system keeps working (brief: 'quarantine failed assets rather than bricking the basket').

  Actual: deposits and the fee-to-basket flow are closed until governance installs a fake feed.

  Run: forge test --match-path test/scratch/LowLeads.t.sol --match-test honeypot -vv (reproduces the state).

  whole reproduction

• lowA position worth less than one reserve unit can never be sold through the keeper path and keeps its held slotsrc/RebalanceExecutor.sol:264

  _authorize refuses any sale whose fair output rounds to zero (fair == 0 -> NothingToTrade). An exit that leaves even 1 wei of an 18-decimal token behind (a venue that fills the exact amount minus dust, or a keeper choosing balance - 1) therefore leaves a position the keeper can never clear: 1 wei of a $100 token is 1e-16 USDC, so every later sell attempt reverts, and endTrade only drops a token whose balance is exactly zero. The slot stays occupied in _held (MAX_HELD = 10), the token stays in every NAV, redemption and holdings loop, and its feed must stay fresh or deposits close (see finding 4). Five such leftovers block the purchase of any further new member (HeldListFull). Only the timelock can clean up, by quarantining and disposing with minOut = 1 through a venue willing to pay 1 unit for dust.

  Fix: in _authorize, when exit is true and the whole balance is being sold, allow fair == 0 with oracleMinOut = 0 (there is nothing of value to protect), or let endTrade drop a held token whose registry.convert(balance) is zero.

  whole finding

  State: basket bought; guardian quarantines T0 (balance 1,960e18 in the vault).

  Calls: keeper executeTrade(T0, usdc, balance - 1, 0, venue, fair fill) -> (true, ...). tokens[0].balanceOf(vault) == 1; vault.isHeld(T0) == true; heldTokens().length == 5. Then executeTrade(T0, usdc, 1, 0, venue, swap(T0, usdc, 1, 1)) -> reverts NothingToTrade.

  Expected: an exited position is fully cleared or at least clearable.

  Actual: the dust position is permanent on the keeper path and occupies a held slot.

  Run: forge test --match-path test/scratch/LowLeads.t.sol --match-test dustPosition -vv.

  whole reproduction

• lowStrict redemption silently forfeits the slice of a token whose balanceOf revertssrc/IndexVault.sol:163

  redeem(shares, receiver, strict = true) promises (NatSpec, README) that any token whose transfer fails reverts the redemption, so a holder can choose to wait rather than forfeit. But the payout amount comes from _balanceOf, which returns (0, false) when balanceOf reverts or returns short data, and the loop then hits if (amount == 0) continue; before any transfer is attempted. A strict redeemer burns all their shares and receives nothing of that token, with only a RedemptionPayout missing and no RedemptionSkipped event. The condition is temporary for tokens that pause balanceOf or revert while upgrading, so the holder had a real reason to wait. The forfeited slice stays with remaining holders.

  Fix: in redeem, when strict is true and _balanceOf(token) reports readable == false, revert with TransferFailed(token) (or a dedicated BalanceUnreadable(token)), and emit RedemptionSkipped when strict is false.

  whole finding

  State: basket bought; T3's balanceOf starts reverting. Alice holds all shares.

  Call: vault.redeem(allShares, Alice, true).

  Expected: revert TransferFailed(T3) (strict mode).

  Actual: succeeds; totalSupply == 0; Alice's T3 balance == 0; the vault still holds all of T3 and no RedemptionSkipped event was emitted.

  Run: forge test --match-path test/scratch/LowLeads.t.sol --match-test strictRedeem -vv.

• lowAnyone chooses when the treasury buys vault shares with the basket reserve, with minShares 0src/FeeWaterfall.sol:129

  pushBasketReserve(minShares) is permissionless and deposits the whole accrued basket bucket at the vault's feed NAV for shares owned by the timelock. The caller, not the treasury, picks the moment and the floor (minShares can be 0). The mirror image of finding 3: whenever the feeds are stale-high (market down by less than the deviation threshold, or a feed lagging right before an update that lowers its answer), a share holder calls pushBasketReserve(0) and the treasury overpays for its shares; the difference accrues to existing holders, including the caller. With a 10,000 USDC bucket and feeds 1.9% above market on a fully invested vault, the treasury receives shares worth about 9,814 USDC, a 186 USDC transfer per push, repeatable on every accumulation. It is bounded by the deviation threshold and the bucket size, which is why this is low.

  Fix: restrict pushBasketReserve to a role (keeper or timelock) or compute minShares on-chain from previewDeposit with a tolerance set by the timelock, so a caller cannot choose a floor of zero.

  whole finding

  State: fully invested vault, 10,000 USDC accrued in the basket bucket; every member feed answers $100 while the market is $98.10 (inside a 2% deviation threshold, feeds fresh).

  Call (any address): waterfall.pushBasketReserve(0).

  Expected: the treasury's deposit is priced by the treasury's own floor, or by an on-chain tolerance.

  Actual: vault.deposit(10_000e6, timelock, 0) mints shares at the stale NAV; after the feeds update, previewRedeem(timelock shares) is worth about 9,814 USDC; the 186 USDC went to the other holders.

  whole reproduction

• lowThe rebalance window opens at the keeper's first trade, not at epoch activation, so the keeper picks when the two-day window runssrc/RebalanceExecutor.sol:271

  README and METHODOLOGY say trading happens in a window 'that opens with a new epoch or once per RebalanceInterval'. _requireWindow instead sets windowStart = block.timestamp the first time a non-exit trade is attempted in a new epoch, whenever that is. A keeper can leave an activated basket untraded for days or weeks and then open a fresh two-day window at a time of its choosing (for example when its counterparty is positioned, or in a volatile hour), and the same applies to the periodic re-opening: block.timestamp >= windowStart + RebalanceInterval is measured from the keeper's previous window, not from a schedule. The published rule ('weekly execution') is therefore not what the contract enforces; it is a keeper-timed window of two days every seven-or-more days. Impact is timing freedom for a semi-trusted role rather than direct loss, so low.

  Fix: have EpochManager.activate (or the executor on first sight of a new epoch) anchor windowStart to activatedAt, and re-open windows on a fixed schedule derived from it.

  whole finding

  State: epoch 1 activated at time T with material deficits for every member. No keeper trade for 30 days.

  Call at T + 30 days: keeper executeTrade(usdc, member, deficit, 0, venue, data).

  Expected (per README): the epoch's window closed at T + 2 days; the next window is on the interval schedule.

  Actual: current != windowEpoch -> windowStart = T + 30 days; the trade and any trade in the following two days succeed (see test_tradesOutsideTheWindowWaitForTheNextInterval, which measures the window from the first trade, not from activation).

  whole reproduction

• lowRebalanceExecutor._nav gives every held token's balanceOf all remaining gas, so one hostile member makes every keeper trade cost a full blocksrc/RebalanceExecutor.sol:310

  IndexVault._balanceOf caps a held token's balanceOf at 500,000 gas 'so one token cannot burn it all', and SECURITY.md lists 'burn gas' as a basket-token risk mitigated by gas-capped calls. RebalanceExecutor._nav makes the same call with no cap, and before consulting isQuarantined, so a member that starts burning gas (an upgradeable token after an upgrade or exploit) is called with 63/64 of the transaction's gas on every executeTrade and every position() read, quarantined or not. At a 30M gas limit the call burns 29,482,372 gas and the trade only completes because the last 1/64 (about 470k) happens to be enough; at lower limits every keeper trade reverts with out-of-gas. Every rebalance of every other member then costs the keeper about a full mainnet block of gas (at 20 gwei roughly 0.6 ETH per trade) until the timelock disposes of the token, and forever if the token also refuses transfers (finding 4). The vault side already handles this case correctly; the executor does not, so the stated 'one token cannot stop the basket' guarantee does not hold for rebalancing.

  Fix: in _nav, skip quarantined tokens before calling them and cap the staticcall (held[i].staticcall{gas: 500_000}(...)) as the vault does; treat a failed read on a non-quarantined token as UnpricedHolding exactly as now.

  whole finding

  State: five-member basket bought; guardian quarantines T4 (so selling it is an exit) and T0. T0's balanceOf then loops until out of gas.

  Call: keeper executeTrade{gas: 30_000_000}(T4, reserve, balance, 0, venue, fair fill).

  Expected: a quarantined, unrelated token is skipped cheaply (as the vault does with a 500k cap).

  Actual: the trace shows Token::balanceOf(IndexVault) consuming 29,482,372 gas (MemoryOOG) inside _nav before the quarantine check; the trade completes only on the remaining ~470k gas, and reverts at any gas limit where 1/64 is not enough for the swap. executor.position(any) behaves the same.

  Run: forge test --match-path test/scratch/GasBomb.t.sol -vvvv and read the balanceOf gas in the trace.

  whole reproduction

Failed on the agent's machine.

Failed on the agent's machine.

• mediumActive-basket purchases bypass subsequently tightened age and weight limitssrc/RebalanceExecutor.sol:233

  The buy branch checks membership, approval and quarantine, but never registry.isEligible or the current maxWeightBps. _target uses the active proposal weight without applying the current cap. After a legitimate timelocked tightening, a keeper can continue buying a now-ineligible token or build exposure above its new cap using an older active basket.

  This is not an unauthorized configuration change: the proof uses the real admin delay to tighten protections, then an ordinary keeper bypasses those protections. Enforce current eligibility on new purchases and apply current weight caps (or invalidate execution of baskets signed under superseded rules).

  Run the supplied proof as test/ExecutorRulesProof.t.sol with forge test --match-path test/ExecutorRulesProof.t.sol.

  Deposit 100,000 USDC and activate a one-token basket at 2,000 bps, with a fresh $1 oracle and a token initially over 30 days old.

  Case 1: schedule and execute MinTokenAge=90 days through the real one-day timelock; registry.isEligible(token) is now false.

  Case 2 (fresh setup): reduce maxWeightBps from 2,000 to 100 through the same timelock.

  In either case, within the open two-day rebalance window, the keeper sells 10,000 USDC for 10,000 tokens at the oracle price.

  Expected: the purchase is rejected and reserve remains 100,000 USDC.

  Actual: executeTrade returns (true, 10,000e18), reserve falls to 90,000 USDC and the vault holds 10,000 tokens.

  In case 2 that is 10% of NAV, above both the 1% gross-NAV cap and the 980-USDC buffered target.

  Both tests fail with purchase bypassed the live risk rule.

  whole reproduction
  proof · a Foundry test the fix has to pass

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {TimelockedAdmin} from "src/TimelockedAdmin.sol";
  import {AssetRegistry} from "src/AssetRegistry.sol";
  import {EpochManager} from "src/EpochManager.sol";
  import {IndexVault} from "src/IndexVault.sol";
  import {RebalanceExecutor} from "src/RebalanceExecutor.sol";
  import {Param} from "src/interfaces/IIndex.sol";
  
  contract RiskProofToken {
      uint8 public immutable decimals;
      mapping(address => uint256) public balanceOf;
      mapping(address => mapping(address => uint256)) public allowance;
      constructor(uint8 d) { decimals = d; }
      function mint(address to, uint256 n) external { balanceOf[to] += n; }
      function approve(address to, uint256 n) external returns (bool) { allowance[msg.sender][to] = n; return true; }
      function transfer(address to, uint256 n) external returns (bool) {
          balanceOf[msg.sender] -= n; balanceOf[to] += n; return true;
      }
      function transferFrom(address from, address to, uint256 n) external returns (bool) {
          allowance[from][msg.sender] -= n; balanceOf[from] -= n; balanceOf[to] += n; return true;
      }
  }
  
  contract RiskProofFeed {
      function decimals() external pure returns (uint8) { return 8; }
      function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
          return (1, 1e8, block.timestamp, block.timestamp, 1);
      }
  }
  
  contract RiskProofRouter {
      function swap(RiskProofToken reserve, RiskProofToken asset, uint256 amount) external {
          reserve.transferFrom(msg.sender, address(this), amount);
          asset.transfer(msg.sender, amount * 1e12);
      }
  }
  
  abstract contract LiveRiskProofBase is Test {
      address constant OWNER = address(0x1001);
      address constant GUARDIAN = address(0x1002);
      address constant KEEPER = address(0x1003);
      uint256 constant SIGNER_KEY = 0xCAFE;
      TimelockedAdmin admin;
      AssetRegistry registry;
      EpochManager epochs;
      IndexVault vault;
      RebalanceExecutor executor;
      RiskProofToken reserve;
      RiskProofToken token;
      RiskProofFeed feed;
      RiskProofRouter router;
      uint256 nonce;
  
      function setUp() public {
          vm.warp(1_800_000_000);
          admin = new TimelockedAdmin(OWNER, 1 days);
          reserve = new RiskProofToken(6);
          token = new RiskProofToken(18);
          feed = new RiskProofFeed();
          registry = new AssetRegistry(address(admin), address(reserve), 6);
          epochs = new EpochManager(address(admin), address(registry));
          vault = new IndexVault(address(admin), address(registry), address(reserve), 6, 1_000_000e6);
          executor = new RebalanceExecutor(address(admin), address(registry), address(epochs), address(vault));
          router = new RiskProofRouter();
          address[] memory targets = new address[](8);
          bytes[] memory calls = new bytes[](8);
          for (uint256 i; i < 5; ++i) targets[i] = address(admin);
          for (uint256 i = 5; i < 8; ++i) targets[i] = address(registry);
          calls[0] = abi.encodeCall(admin.setGuardian, (GUARDIAN));
          calls[1] = abi.encodeCall(admin.setExecutor, (address(executor)));
          calls[2] = abi.encodeCall(admin.setKeeper, (KEEPER, true));
          calls[3] = abi.encodeCall(admin.setSigner, (vm.addr(SIGNER_KEY), true));
          calls[4] = abi.encodeCall(admin.setQuorum, (1));
          calls[5] = abi.encodeCall(registry.setReserveFeed, (address(feed), 1 days));
          calls[6] = abi.encodeCall(registry.setRouter, (address(router), true));
          calls[7] = abi.encodeCall(registry.approveToken,
              (address(token), address(feed), 1 days, 2000, uint40(block.timestamp - 31 days), keccak256("review")));
          for (uint256 i; i < 8; ++i) {
              vm.prank(OWNER);
              admin.schedule(targets[i], 0, calls[i], bytes32(i), 1 days);
          }
          vm.warp(block.timestamp + 1 days);
          for (uint256 i; i < 8; ++i) {
              vm.prank(OWNER);
              admin.execute(targets[i], 0, calls[i], bytes32(i));
          }
          reserve.mint(address(this), 100_000e6);
          reserve.approve(address(vault), 100_000e6);
          vault.deposit(100_000e6, address(this), 0);
          vm.roll(block.number + 1);
          token.mint(address(router), 100_000e18);
      }
  
      function _proposal() internal view returns (EpochManager.Proposal memory p) {
          p.epoch = 1;
          p.snapshotTime = uint64(block.timestamp);
          p.expiry = uint64(block.timestamp + 23 hours);
          p.methodologyVersion = registry.methodologyVersion();
          p.signerSetVersion = admin.signerSetVersion();
          p.dataHash = keccak256("daily report");
          p.tokens = new address[](1); p.tokens[0] = address(token);
          p.weightsBps = new uint16[](1); p.weightsBps[0] = 2000;
          p.marketCapsUsd = new uint256[](1); p.marketCapsUsd[0] = 1_000_000_000;
          p.liquidityUsd = new uint256[](1); p.liquidityUsd[0] = 50_000_000;
          p.volumesUsd = new uint256[](1); p.volumesUsd[0] = 50_000_000;
      }
  
      function _publish() internal {
          EpochManager.Proposal memory p = _proposal();
          (uint8 v, bytes32 r, bytes32 s) = vm.sign(SIGNER_KEY, epochs.hashProposal(p));
          bytes[] memory sigs = new bytes[](1); sigs[0] = abi.encodePacked(r, s, v);
          epochs.publish(p, sigs);
      }
  
      function _activate() internal {
          _publish();
          vm.warp(block.timestamp + 6 hours);
          epochs.activate();
      }
  
      function _govern(bytes memory data) internal {
          bytes32 salt = bytes32(++nonce + 100);
          vm.prank(OWNER);
          admin.schedule(address(registry), 0, data, salt, 1 days);
          vm.warp(block.timestamp + 1 days);
          vm.prank(OWNER);
          admin.execute(address(registry), 0, data, salt);
      }
  
      function _assertBuyRejected() internal {
          vm.prank(KEEPER);
          (bool callOk, bytes memory ret) = address(executor).call(abi.encodeCall(executor.executeTrade,
              (address(reserve), address(token), 10_000e6, 0, address(router),
               abi.encodeCall(router.swap, (reserve, token, 10_000e6)))));
          bool traded;
          if (callOk) (traded,) = abi.decode(ret, (bool, uint256));
          assertFalse(traded, "purchase bypassed the live risk rule");
          assertEq(reserve.balanceOf(address(vault)), 100_000e6);
          assertEq(token.balanceOf(address(vault)), 0);
      }
  
  }
  
  contract ExecutorRulesProof is LiveRiskProofBase {
      function test_liveAgeRuleMustStopAnExistingBasketPurchase() public {
          _activate();
          _govern(abi.encodeCall(registry.setParam, (Param.MinTokenAge, 90 days)));
          assertFalse(registry.isEligible(address(token)), "precondition: age rule must actually exclude token");
          _assertBuyRejected();
      }
  
      function test_liveWeightCapMustStopAnExistingBasketPurchase() public {
          _activate();
          AssetRegistry.Asset memory a = registry.asset(address(token));
          _govern(abi.encodeCall(registry.approveToken,
              (address(token), a.feed, a.heartbeat, 100, a.listedAt, a.reviewHash)));
          assertEq(registry.maxWeightBps(address(token)), 100);
          // 10,000 USDC is 10% of NAV and exceeds the new 1% cap.
          _assertBuyRejected();
      }
  
  }

  whole proof

• mediumActivation ignores market-data minimums raised during the proposal delaysrc/EpochManager.sol:194

  publish checks signed market cap, liquidity and volume against current minimums, but Pending does not retain these values or a risk-configuration version. activate rechecks token eligibility and weight caps only. A proposal published while a timelocked increase is pending can therefore become the active basket after that increase executes even though its signed data violate the current hard rules. Changing numeric minimums does not change methodologyVersion.

  Persist and revalidate the attested data, or invalidate pending proposals when relevant risk rules change.

  Run the supplied proof as test/EpochRulesProof.t.sol with forge test --match-path test/EpochRulesProof.t.sol.

  Schedule MinMarketCapUsd=2,000,000,000 with a one-day timelock.

  After 20 hours, publish a valid quorum-signed proposal attesting a $1,000,000,000 market cap, above the original $250,000,000 minimum.

  After another six hours, execute the matured configuration change, then call activate.

  Prices are fresh, the snapshot is six hours old, and expiry is still 17 hours away.

  Expected: activation fails because the signed $1bn market cap is below the now-effective $2bn minimum and epoch stays 0.

  Actual: activation succeeds and epoch becomes 1.

  The proof fails with activated $1bn asset under the current $2bn minimum.

  whole reproduction
  proof · a Foundry test the fix has to pass

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {TimelockedAdmin} from "src/TimelockedAdmin.sol";
  import {AssetRegistry} from "src/AssetRegistry.sol";
  import {EpochManager} from "src/EpochManager.sol";
  import {IndexVault} from "src/IndexVault.sol";
  import {RebalanceExecutor} from "src/RebalanceExecutor.sol";
  import {Param} from "src/interfaces/IIndex.sol";
  
  contract RiskProofToken {
      uint8 public immutable decimals;
      mapping(address => uint256) public balanceOf;
      mapping(address => mapping(address => uint256)) public allowance;
      constructor(uint8 d) { decimals = d; }
      function mint(address to, uint256 n) external { balanceOf[to] += n; }
      function approve(address to, uint256 n) external returns (bool) { allowance[msg.sender][to] = n; return true; }
      function transfer(address to, uint256 n) external returns (bool) {
          balanceOf[msg.sender] -= n; balanceOf[to] += n; return true;
      }
      function transferFrom(address from, address to, uint256 n) external returns (bool) {
          allowance[from][msg.sender] -= n; balanceOf[from] -= n; balanceOf[to] += n; return true;
      }
  }
  
  contract RiskProofFeed {
      function decimals() external pure returns (uint8) { return 8; }
      function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
          return (1, 1e8, block.timestamp, block.timestamp, 1);
      }
  }
  
  contract RiskProofRouter {
      function swap(RiskProofToken reserve, RiskProofToken asset, uint256 amount) external {
          reserve.transferFrom(msg.sender, address(this), amount);
          asset.transfer(msg.sender, amount * 1e12);
      }
  }
  
  abstract contract LiveRiskProofBase is Test {
      address constant OWNER = address(0x1001);
      address constant GUARDIAN = address(0x1002);
      address constant KEEPER = address(0x1003);
      uint256 constant SIGNER_KEY = 0xCAFE;
      TimelockedAdmin admin;
      AssetRegistry registry;
      EpochManager epochs;
      IndexVault vault;
      RebalanceExecutor executor;
      RiskProofToken reserve;
      RiskProofToken token;
      RiskProofFeed feed;
      RiskProofRouter router;
      uint256 nonce;
  
      function setUp() public {
          vm.warp(1_800_000_000);
          admin = new TimelockedAdmin(OWNER, 1 days);
          reserve = new RiskProofToken(6);
          token = new RiskProofToken(18);
          feed = new RiskProofFeed();
          registry = new AssetRegistry(address(admin), address(reserve), 6);
          epochs = new EpochManager(address(admin), address(registry));
          vault = new IndexVault(address(admin), address(registry), address(reserve), 6, 1_000_000e6);
          executor = new RebalanceExecutor(address(admin), address(registry), address(epochs), address(vault));
          router = new RiskProofRouter();
          address[] memory targets = new address[](8);
          bytes[] memory calls = new bytes[](8);
          for (uint256 i; i < 5; ++i) targets[i] = address(admin);
          for (uint256 i = 5; i < 8; ++i) targets[i] = address(registry);
          calls[0] = abi.encodeCall(admin.setGuardian, (GUARDIAN));
          calls[1] = abi.encodeCall(admin.setExecutor, (address(executor)));
          calls[2] = abi.encodeCall(admin.setKeeper, (KEEPER, true));
          calls[3] = abi.encodeCall(admin.setSigner, (vm.addr(SIGNER_KEY), true));
          calls[4] = abi.encodeCall(admin.setQuorum, (1));
          calls[5] = abi.encodeCall(registry.setReserveFeed, (address(feed), 1 days));
          calls[6] = abi.encodeCall(registry.setRouter, (address(router), true));
          calls[7] = abi.encodeCall(registry.approveToken,
              (address(token), address(feed), 1 days, 2000, uint40(block.timestamp - 31 days), keccak256("review")));
          for (uint256 i; i < 8; ++i) {
              vm.prank(OWNER);
              admin.schedule(targets[i], 0, calls[i], bytes32(i), 1 days);
          }
          vm.warp(block.timestamp + 1 days);
          for (uint256 i; i < 8; ++i) {
              vm.prank(OWNER);
              admin.execute(targets[i], 0, calls[i], bytes32(i));
          }
          reserve.mint(address(this), 100_000e6);
          reserve.approve(address(vault), 100_000e6);
          vault.deposit(100_000e6, address(this), 0);
          vm.roll(block.number + 1);
          token.mint(address(router), 100_000e18);
      }
  
      function _proposal() internal view returns (EpochManager.Proposal memory p) {
          p.epoch = 1;
          p.snapshotTime = uint64(block.timestamp);
          p.expiry = uint64(block.timestamp + 23 hours);
          p.methodologyVersion = registry.methodologyVersion();
          p.signerSetVersion = admin.signerSetVersion();
          p.dataHash = keccak256("daily report");
          p.tokens = new address[](1); p.tokens[0] = address(token);
          p.weightsBps = new uint16[](1); p.weightsBps[0] = 2000;
          p.marketCapsUsd = new uint256[](1); p.marketCapsUsd[0] = 1_000_000_000;
          p.liquidityUsd = new uint256[](1); p.liquidityUsd[0] = 50_000_000;
          p.volumesUsd = new uint256[](1); p.volumesUsd[0] = 50_000_000;
      }
  
      function _publish() internal {
          EpochManager.Proposal memory p = _proposal();
          (uint8 v, bytes32 r, bytes32 s) = vm.sign(SIGNER_KEY, epochs.hashProposal(p));
          bytes[] memory sigs = new bytes[](1); sigs[0] = abi.encodePacked(r, s, v);
          epochs.publish(p, sigs);
      }
  
      function _activate() internal {
          _publish();
          vm.warp(block.timestamp + 6 hours);
          epochs.activate();
      }
  
      function _govern(bytes memory data) internal {
          bytes32 salt = bytes32(++nonce + 100);
          vm.prank(OWNER);
          admin.schedule(address(registry), 0, data, salt, 1 days);
          vm.warp(block.timestamp + 1 days);
          vm.prank(OWNER);
          admin.execute(address(registry), 0, data, salt);
      }
  
      function _assertBuyRejected() internal {
          vm.prank(KEEPER);
          (bool callOk, bytes memory ret) = address(executor).call(abi.encodeCall(executor.executeTrade,
              (address(reserve), address(token), 10_000e6, 0, address(router),
               abi.encodeCall(router.swap, (reserve, token, 10_000e6)))));
          bool traded;
          if (callOk) (traded,) = abi.decode(ret, (bool, uint256));
          assertFalse(traded, "purchase bypassed the live risk rule");
          assertEq(reserve.balanceOf(address(vault)), 100_000e6);
          assertEq(token.balanceOf(address(vault)), 0);
      }
  
  }
  
  contract EpochRulesProof is LiveRiskProofBase {
      function test_activationMustRecheckATightenedMarketCapFloor() public {
          bytes memory data = abi.encodeCall(registry.setParam, (Param.MinMarketCapUsd, 2_000_000_000));
          vm.prank(OWNER);
          admin.schedule(address(registry), 0, data, bytes32("tighten"), 1 days);
          vm.warp(block.timestamp + 20 hours);
          _publish(); // Signed market cap = $1bn, valid under the original $250m minimum.
          vm.warp(block.timestamp + 6 hours);
          vm.prank(OWNER);
          admin.execute(address(registry), 0, data, bytes32("tighten"));
          assertEq(registry.param(Param.MinMarketCapUsd), 2_000_000_000);
          (bool activated,) = address(epochs).call(abi.encodeCall(epochs.activate, ()));
          assertFalse(activated, "activated $1bn asset under the current $2bn minimum");
          assertEq(epochs.epoch(), 0);
      }
  }

  whole proof