Four agents audited the code as it is at 0a88bde, each in one area, and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the code was changed or deployed.

Download the report (Markdown)

1 medium2 low3 info

• 1.mediumhasPause is probed only at listing; an issuer upgrade that breaks oraclePaused() on a held asset halts all deposits and only Retire (which dilutes existing holders) can clear itsrc/BaskVault.sol:274

          a.hasPause = ok && paused <= 1;

  _newAsset probes oraclePaused() once and stores the result in Asset.hasPause; line 274 is the only assignment to that field. BaskOracle.price (src/libraries/BaskOracle.sol:93-97) then requires a valid false answer from oraclePaused() on every deposit price check for that asset, and _snapshot prices every unretired asset with managed > 0, not only the input tokens. The brief lists issuer upgrades of the Stock Tokens as a scenario.

  If an upgrade removes, renames, reverts or widens oraclePaused() on a held token, price() returns OraclePaused for it forever and every deposit, previewDeposit and depositStatus for any input token fails with DepositUnavailable(OraclePaused, token). No proposal re-runs the probe: Feed, Pool, Centre, Reopen and Resync all leave hasPause true (verified by execution of each).

  The accepted-risk list covers the analogous pool failure because a Pool proposal can clear it; here the only exit is Retire, which permanently drops the asset from NAV while its tokens stay in the vault, so every depositor after Retire shares them at existing holders' expense (reproduced: with 10e18 of token0 and token1 held, retiring token0 and depositing 10e18 of token1 yields a redemption of 5e18 token0 for the new depositor).

  If the retired asset was the only holding, NAV is zero and deposits stop with ZeroNAV. Redeem and claim are unaffected. The reverse direction also holds: a token listed before it exposed oraclePaused() keeps hasPause false, so a pause added by a later upgrade is ignored.

  Minimal fix preserving the design: re-run the two-line oraclePaused() probe from _newAsset when a Feed, Pool or Centre proposal executes for the asset (or add a dedicated timelocked action), giving the owner the same lever a Pool proposal gives for pool failures. Merged from audit_permissions (medium) and audit_economics (low).

  whole finding

  State: three assets listed at genesis with a token exposing oraclePaused()=false, so asset(token0).hasPause == true; alice deposits 10e18 of token0 (managed > 0).

  Input: the token's oraclePaused() starts reverting (proof: removeProbe(); also verified with vm.etch of code lacking the function).

  Then depositStatus([token1]) returns (OraclePaused, token0) and deposit([token1],[1e18],alice,0,now) reverts DepositUnavailable(OraclePaused, token0).

  Owner executes Feed(token0, same feed), Pool(token0, 0,0,0), Centre(token0), close+Reopen(token0) and Resync(token0) after their 2-day waits: asset(token0).hasPause is still true and depositStatus still returns OraclePaused.

  Expected: an owner proposal re-detects the probe so deposits resume, as a Pool proposal does for a broken pool.

  Actual: deposits are halted until Retire.

  Proof test/scratch/Proof_765fb70ae8b5.t.sol fails on this code with 'hasPause must be re-detected by an owner proposal'; test/scratch/Probe.t.sol::testHasPauseStickyAndRetireDilutes and testRetireDilution confirm Reopen/Resync and the post-retire dilution.

  whole reproduction
  proof · a Foundry test that fails on this code and passes once it is fixed

  // SPDX-License-Identifier: GPL-2.0-or-later
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {BaskVault} from "src/BaskVault.sol";
  import {BaskTypes as T} from "src/BaskTypes.sol";
  
  /// @dev Minimal Stock Token with an optional oraclePaused() probe that the issuer can remove by upgrade.
  contract StockToken {
      uint8 public constant decimals = 18;
      bool public probeRemoved;
      mapping(address => uint256) public balanceOf;
      mapping(address => mapping(address => uint256)) public allowance;
  
      function mint(address to, uint256 amount) external {
          balanceOf[to] += amount;
      }
  
      function removeProbe() external {
          probeRemoved = true;
      }
  
      function oraclePaused() external view returns (bool) {
          require(!probeRemoved, "function removed by upgrade");
          return false;
      }
  
      function approve(address spender, uint256 amount) external returns (bool) {
          allowance[msg.sender][spender] = amount;
          return true;
      }
  
      function transfer(address to, uint256 amount) external returns (bool) {
          balanceOf[msg.sender] -= amount;
          balanceOf[to] += amount;
          return true;
      }
  
      function transferFrom(address from, address to, uint256 amount) external returns (bool) {
          allowance[from][msg.sender] -= amount;
          balanceOf[from] -= amount;
          balanceOf[to] += amount;
          return true;
      }
  }
  
  contract Feed {
      uint8 public constant decimals = 8;
      int256 public answer;
      uint256 public updatedAt;
  
      constructor(int256 a) {
          answer = a;
          updatedAt = block.timestamp;
      }
  
      function set(int256 a, uint256 t) external {
          answer = a;
          updatedAt = t;
      }
  
      function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
          return (1, answer, updatedAt, updatedAt, 1);
      }
  }
  
  /// @notice Fails on the current code: once a held Stock Token's oraclePaused() probe stops answering,
  /// no owner proposal (Feed, Pool, Centre) re-detects the pause interface, so hasPause stays true and
  /// every deposit into the vault reverts with DepositUnavailable(OraclePaused). Passes once executing a
  /// Feed, Pool or Centre proposal re-probes oraclePaused() the way listing does.
  contract StickyPauseProof is Test {
      BaskVault private vault;
      StockToken[3] private tokens;
      Feed[3] private feeds;
      address private owner = makeAddr("owner");
      address private guardian = makeAddr("guardian");
      address private alice = makeAddr("alice");
  
      function setUp() public {
          vm.warp(1_800_000_000);
          vault = new BaskVault(owner, guardian);
          for (uint256 i; i < 3; ++i) {
              tokens[i] = new StockToken();
              feeds[i] = new Feed(100e8);
              vm.prank(owner);
              vault.genesisList(address(tokens[i]), address(feeds[i]), address(0), address(0), 0);
              tokens[i].mint(alice, 100e18);
              vm.prank(alice);
              tokens[i].approve(address(vault), type(uint256).max);
          }
          vm.prank(owner);
          vault.finalizeGenesis();
      }
  
      function _one(address t) private pure returns (address[] memory a) {
          a = new address[](1);
          a[0] = t;
      }
  
      function _amt(uint256 v) private pure returns (uint256[] memory a) {
          a = new uint256[](1);
          a[0] = v;
      }
  
      function _refresh() private {
          for (uint256 i; i < 3; ++i) {
              feeds[i].set(100e8, block.timestamp);
          }
      }
  
      function _run(T.Action action, address token, bytes memory data) private {
          vm.prank(owner);
          uint256 id = vault.propose(action, token, data);
          vm.warp(vault.proposal(id).readyAt);
          _refresh();
          vm.prank(owner);
          vault.execute(id);
      }
  
      function testOwnerCanRecoverDepositsAfterIssuerRemovesPauseProbe() public {
          address t0 = address(tokens[0]);
          vm.prank(alice);
          vault.deposit(_one(t0), _amt(10e18), alice, 0, block.timestamp);
          assertTrue(vault.asset(t0).hasPause);
  
          // Issuer upgrade: oraclePaused() no longer exists on the held token.
          tokens[0].removeProbe();
          (T.Reason reason, address fault) = vault.depositStatus(_one(address(tokens[1])));
          assertEq(uint256(reason), uint256(T.Reason.OraclePaused));
          assertEq(fault, t0);
  
          // Every configuration proposal the owner has for a live asset.
          _run(T.Action.Feed, t0, abi.encode(address(feeds[0])));
          _run(T.Action.Pool, t0, abi.encode(address(0), address(0), uint128(0)));
          _run(T.Action.Centre, t0, "");
          _refresh();
  
          // Expected: the probe is re-detected and deposits of other assets work again.
          // Actual on current code: hasPause is still true and the deposit reverts with OraclePaused.
          assertFalse(vault.asset(t0).hasPause, "hasPause must be re-detected by an owner proposal");
          (reason,) = vault.depositStatus(_one(address(tokens[1])));
          assertEq(uint256(reason), uint256(T.Reason.OK), "deposits must be recoverable without retiring the asset");
          vm.prank(alice);
          uint256 shares = vault.deposit(_one(address(tokens[1])), _amt(1e18), alice, 0, block.timestamp);
          assertGt(shares, 0);
      }
  }

  whole proof

• 2.lowRead-only reentrancy: previewRedeem, previewDeposit, depositStatus and allAssets report inconsistent values while redeem or deposit is in flightsrc/BaskVault.sol:794

      function previewRedeem(uint256 shares) external view returns (uint256[] memory amounts, uint256 fee) {

  Every state-changing entry point is nonReentrant, but the view functions do not check the entered flag. redeem() reduces totalSupply (line 652) before the per-asset loop reduces managed[] one asset at a time and makes an external token transfer through pay() for each held asset.

  A Stock Token whose transfer calls back into previewRedeem (an issuer upgrade can do this) sees the reduced supply against the still-unreduced managed[] of later assets and is quoted roughly twice the true per-share entitlement for a 50% redemption. Symmetrically, during deposit() the token pulls (line 565) increase managed[] for earlier input tokens before shares are minted, so previewDeposit/allAssets quoted from a transferFrom callback see an overstated NAV per share.

  Vault accounting is not corrupted and the brief's redeem/claim/deposit guarantees hold; the exposure is to any contract that prices BASK through these views (lending collateral, a quoter, a keeper) and can be invoked inside a hooked token transfer.

  Minimal fix: revert in the views when entered != 1, or apply supply and all managed reductions before any external call. From audit_flow.

  whole finding

  State: three listed assets; alice deposited 10e18 of asset A (a token whose transfer calls vault.previewRedeem(1e18)) and 10e18 of asset B (plain). previewRedeem(1e18) reports 5e15 of B per 1e18 shares. alice calls redeem(balance/2, alice, [], now).

  Inside pay() for asset A the hooked transfer calls previewRedeem(1e18): totalSupply is already halved but managed[B] is untouched, so the view returns 9999995000002499 (about 2x) for B.

  Expected: a view invoked mid-redemption reverts or returns the same 5e15 as before and after the transaction.

  Actual: about 1e16.

  Proof test/scratch/Proof_109e6b698e4c.t.sol fails on this code with 'previewRedeem must not report an inflated entitlement while a redemption is in flight'.

  whole reproduction
  proof · a Foundry test that fails on this code and passes once it is fixed

  // SPDX-License-Identifier: GPL-2.0-or-later
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {BaskVault} from "src/BaskVault.sol";
  import {BaskTypes as T} from "src/BaskTypes.sol";
  
  /// @dev A Stock Token whose transfer calls back into a vault view (an issuer upgrade can do this).
  contract HookedToken {
      uint8 public constant decimals = 18;
      mapping(address => uint256) public balanceOf;
      BaskVault public vault;
      uint256 public observedLeg1;
      bool public viewReverted;
      bool public armed;
  
      function setVault(BaskVault v) external {
          vault = v;
      }
  
      function arm() external {
          armed = true;
      }
  
      function mint(address to, uint256 amount) external {
          balanceOf[to] += amount;
      }
  
      function transferFrom(address from, address to, uint256 amount) external returns (bool) {
          balanceOf[from] -= amount;
          balanceOf[to] += amount;
          return true;
      }
  
      function transfer(address to, uint256 amount) external returns (bool) {
          if (armed) {
              armed = false;
              // Mid-redeem view read: supply already reduced, later assets' managed not yet reduced.
              try vault.previewRedeem(1e18) returns (uint256[] memory amounts, uint256) {
                  observedLeg1 = amounts[1];
              } catch {
                  viewReverted = true;
              }
          }
          balanceOf[msg.sender] -= amount;
          balanceOf[to] += amount;
          return true;
      }
  }
  
  contract PlainToken {
      uint8 public constant decimals = 18;
      mapping(address => uint256) public balanceOf;
  
      function mint(address to, uint256 amount) external {
          balanceOf[to] += amount;
      }
  
      function transferFrom(address from, address to, uint256 amount) external returns (bool) {
          balanceOf[from] -= amount;
          balanceOf[to] += amount;
          return true;
      }
  
      function transfer(address to, uint256 amount) external returns (bool) {
          balanceOf[msg.sender] -= amount;
          balanceOf[to] += amount;
          return true;
      }
  }
  
  contract Feed {
      uint8 public constant decimals = 8;
  
      function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
          return (1, 100e8, block.timestamp, block.timestamp, 1);
      }
  }
  
  contract ReadOnlyReentrancyTest is Test {
      BaskVault vault;
      HookedToken hooked;
      PlainToken plain;
      PlainToken third;
      address owner = makeAddr("owner");
      address guardian = makeAddr("guardian");
      address alice = makeAddr("alice");
  
      function setUp() public {
          vm.warp(1_800_000_000);
          vault = new BaskVault(owner, guardian);
          hooked = new HookedToken();
          plain = new PlainToken();
          third = new PlainToken();
          hooked.setVault(vault);
          vm.startPrank(owner);
          vault.genesisList(address(hooked), address(new Feed()), address(0), address(0), 0);
          vault.genesisList(address(plain), address(new Feed()), address(0), address(0), 0);
          vault.genesisList(address(third), address(new Feed()), address(0), address(0), 0);
          vault.finalizeGenesis();
          vm.stopPrank();
          hooked.mint(alice, 10e18);
          plain.mint(alice, 10e18);
          address[] memory ts = new address[](2);
          ts[0] = address(hooked);
          ts[1] = address(plain);
          uint256[] memory am = new uint256[](2);
          am[0] = 10e18;
          am[1] = 10e18;
          vm.prank(alice);
          vault.deposit(ts, am, alice, 0, block.timestamp);
      }
  
      /// Fails now: the view called from inside redeem returns ~2x the true entitlement for the
      /// not-yet-processed asset. Passes once views are guarded against reentrancy (revert) or
      /// kept consistent mid-flight.
      function testViewIsConsistentOrGuardedDuringRedeem() public {
          (uint256[] memory before,) = vault.previewRedeem(1e18);
          uint256 shares = vault.balanceOf(alice) / 2;
          hooked.arm();
          vm.prank(alice);
          vault.redeem(shares, alice, new uint256[](0), block.timestamp);
          emit log_named_uint("plain leg per 1e18 shares before redeem", before[1]);
          emit log_named_uint("plain leg per 1e18 shares seen mid-redeem", hooked.observedLeg1());
          assertTrue(
              hooked.viewReverted() || hooked.observedLeg1() == before[1],
              "previewRedeem must not report an inflated entitlement while a redemption is in flight"
          );
      }
  }

  whole proof

• 3.lowDeposits require a readable balance on idle, never-held, non-input assets, which the brief does not ask for and solvency does not needsrc/BaskVault.sol:498

              (bool readable, uint256 bal) = O.balance(token, config.balanceGas);

  The brief says a deposit checks 'every deposited and every held unretired token'. _snapshot additionally performs a bounded balanceOf read on every unretired asset, including assets with managed == 0 that are not in the deposit. For such an asset the only consumers of bal are (wanted[i] && bal < debt) (false, not wanted) and available < m (false, m == 0), so the read cannot change the solvency outcome; it only adds a failure mode.

  An issuer upgrade that makes balanceOf revert, return fewer than 32 bytes or cost more than balanceGas (50,000 by default) on a listed-but-never-deposited token blocks all deposits of every other asset until the owner retires it (close plus a 2-day Retire proposal) or raises balanceGas by proposal. The accepted list covers a held asset whose pool or balance fails, not an idle one.

  Existing tests testZeroManagedNonInputMustStillHaveReadableBalance and testDepositChecksIdleUnreadableButSkipsRetired assert the current behaviour, so this is a deliberate choice reported under item 6 (code does what the text does not say).

  Minimal fix: move the balance read inside if (m != 0 || wanted[i]) and compute available/debt only there, leaving the retired skip and the idle freshness branch unchanged. From audit_math.

  whole finding

  Three assets, genesis finalized; alice deposits 1e18 of tokens[0]. tokens[2] (managed == 0, not an input) is upgraded so balanceOf reverts (MockToken.setModes(1, 0)).

  Expected per the brief: depositStatus([tokens[0]]) == (OK, 0) and a further deposit of tokens[0] succeeds, because tokens[2] is neither deposited nor held.

  Actual: depositStatus returns (BalanceUnreadable (7), tokens[2]) and deposit([tokens[0]],[1e18],alice,0,now) reverts DepositUnavailable(BalanceUnreadable, tokens[2]); redeem is unaffected.

  Reproduced in test/scratch/Probe.t.sol::testIdleUnreadableBlocksDeposit.

  whole reproduction

• 4.infoGlobal proposals (Guardian, NavCap, FeeRecipient, Setting) accept any token address and are voided by that token's retire or removalsrc/BaskVault.sol:296

          proposals[id] = T.Proposal(action, token, data, block.timestamp + 2 days, epoch[token], version, false);

  README.md says the token argument of a global action is zero, but _validate only inspects token for actions up to Resync, and propose stores epoch[token] for whatever address was passed. proposalValid then requires p.epoch == epoch[p.token], so a global proposal created with a listed token's address is silently invalidated when that token is retired or removed; a guardian who cannot cancel its own replacement can still void a Guardian proposal mistakenly keyed to a token the guardian can close and the owner then retires.

  Owner-only input, no funds at risk, re-proposing fixes it.

  Minimal fix: in _validate require token == address(0) for actions above Resync (or store epoch 0 for them). Merged from audit_economics and audit_permissions.

  owner: propose(FeeRecipient, tokens[0], abi.encode(bob)) -> proposalValid(id) == true. guardian: close(tokens[0]); owner: propose(Retire, tokens[0]) and execute it after two days (increments epoch[tokens[0]]).

  Now proposalValid(id) == false and execute(id) at readyAt reverts InvalidProposal although nothing about the fee recipient changed.

  Expected: a global proposal is independent of any asset.

  Actual: bound to an arbitrary token's epoch.

  Reproduced in test/scratch/Probe.t.sol::testGlobalProposalBoundToTokenEpoch.

  whole reproduction

• 5.infoDeposit blockers and immediate owner/guardian actions present in code but absent from the brief: price band around a stored centre, 80-hour feed age on pooled assets, trading hours, freshness count, Nsrc/libraries/BaskOracle.sol:88

              answer < a.centre / s.band || (answer / s.band > a.centre)

  Item 6 asks for anything the code does that the text does not say.

  All of the following are documented in README.md and only ever block deposits (never redeem or claim), so none is a loss path, but the brief's deposit rules do not state them: (a) every priced asset's feed answer must lie within [centre/band, centre*band] (band 4, settable 2..100) where centre is the answer recorded at listing, Feed change or a Centre proposal, so a genuine move beyond 4x in either direction, including a 5:1 or 10:1 split, blocks every deposit of every token until a Centre proposal executes two days later and the brief's operating rules do not mention recentring before a split; (b) a pooled asset's feed must also be under maxAge (80 hours, src/libraries/BaskOracle.sol:84) independent of the 3% pool check, so a three-day market holiday weekend (about 89.5 hours between the Friday and Tuesday updates) blocks deposits until the feed updates even when the pool check would pass; (c) optional Hours (weekday window) and FreshCount settings can block deposits globally; (d) close(token), pauseDeposits() and lowerNavCap(cap) take effect immediately without the 2-day proposal path, lowerNavCap has no lower bound (0 is accepted and voids pending cap raises) and the guardian, not only the owner, can close any asset and pause deposits, while only the owner can unpause.

  These are trust assumptions on the owner and guardian rather than defects. Merged from audit_math, audit_economics and audit_permissions.

  whole finding

  Band: VaultFixture (centre 100e8, band 4); feeds[0].set(25e8 - 1, block.timestamp) or feeds[0].set(400e8 + 1, block.timestamp).

  Expected per the brief: a valid feed answer under 26 hours with no pool is accepted.

  Actual: depositStatus([tokens[0]]) returns (Band, tokens[0]) and deposit reverts DepositUnavailable(Band, tokens[0]) (boundary shown by test/Prices.t.sol::testBandBoundariesAndOraclePause).

  Age: with a healthy pool within 3%, feed updatedAt = now - 80 hours - 1 returns (Feed, token) (boundary shown by testPoolTickZeroPriceLiquidityAndMaxAge).

  Cap: owner calls lowerNavCap(0) in one transaction; the next deposit of any amount reverts CapExceeded with no delay (mechanism shown by testNavCapLoweringVoidsRaisesAndCapApplies).

  whole reproduction

• 6.infoRedemption gas headroom at the tightest in-bounds setting is about 100,000 gas (0.36%) on the booked pathsrc/BaskVault.sol:440

              s.maxAssets < assetTokens.length || s.maxAssets > 28_000_000 / (s.balanceGas + 60_000)

  The booked-path rule budgets 60,000 gas of vault overhead per asset. Measured overhead per held asset on the booked path is roughly 58,000 (two cold owed/totalOwed SSTOREs, managed SLOAD+SSTORE, assetTokens SLOAD, cold token account access, call stipend and the 512-bit mulDiv).

  At the tightest permitted configuration, maxAssets = 50 with balanceGas = 500,000, the suite's testGasMaximumBalance50Assets records 27,897,644 gas for the call with fee, maximal managed values and gas-burning balanceOf on every asset, which satisfies the requirement but leaves about 102,000 gas; a full 50-entry minAmountsOut array adds roughly 11,000 more.

  A real transaction also pays the 21,000 intrinsic cost plus calldata, so the end-to-end transaction is about 27,960,000: inside 28,000,000 on a Cancun-schedule EVM but with no margin for a gas-schedule difference on the target chain (for example an L1 data surcharge counted in gasUsed on an Orbit-style rollup).

  No code defect; recorded so the owner can decide whether to keep balanceGas below 500,000 operationally or widen the booked rule's per-asset allowance to 70,000 like the direct rule. Every direct-path boundary in the suite is lower (maximum 27,331,250 for 26 direct attempts with 500k allowances). From audit_math.

  whole finding

  Run forge test --match-test testGasMaximumBalance50Assets -vv: settings MaxAssets=50, BalanceGas=500000 (and PayGas=500000, DirectLimit=26 or 0 for the booked path), 50 pool-less tokens each held with near-uint256 managed via Resync, fee recipient set, every balanceOf consuming all forwarded gas, redeem(shares/2, receiver, [], now) called with exactly 28,000,000 gas.

  Expected: success under 28,000,000.

  Actual: success at 27,897,644 gas (observed on this tree), headroom 102,356.

1. Posted22 minto the first attempt
2. Audit mathAgent #330found 1 low, 2 info

   The review is complete. The findings file is at .imd-findings.json in the repository root with three entries, none above low severity. No source file was modified; only test/scratch/ and the findings file were created.

   What I checked

   • Redeem and claim cannot be blocked. I traced every revert path in redeem, claim, and pay: fee transfer, net burn, bitmap loop, the bounded balance read, the self-call with payGas, and owed/totalOwed booking. Managed never reaches zero through redemption (dead shares guarantee net < supply), so no zero-crossing bitmap writes occur on that path. Reentrancy from tokens hits the guard on every entry point, and pay rejects any caller but the vault.
   • Gas. All twelve suite measurements reproduce. I added the one cost source the suite omits at the tightest legal setting (50 assets, 500k balance gas, fee on, max managed, full minima, gas-burning tokens) and measured 27,908,869 for the call. That satisfies the requirement with 91k to spare, recorded as an info note.
   • Pool check. Orientation, 6-decimal and 18-decimal quotes, the harmonic-mean liquidity formula, tick rounding toward negative infinity, and the wrapped cumulatives match Uniswap's OracleLibrary. Extreme ticks with USDG and WETH quotes return Reason.Pool and allAssets does not revert; overflow needs an absurd quote feed, which the owner has accepted. The pool never enters share math.
   • Asset and share conservation. Only pay moves tokens, only _mint in deposit creates BASK, fee is exactly ceil(x/200) when the recipient is set and zero before. Resync cannot count owed tokens, and the invariant balance >= managed + totalOwed holds for honest tokens across every operation.
   • Proposals. Timelock, expiry, epoch and version invalidation (retire, removal, relisting, reclose, cap lowering), re-validation at execution, bounds and both gas inequalities, and every guardian-to-owner sequence are enforced.
   • Deposit math. Rounding is in the vault's favour, the first-deposit lock works, donations and issuer credits stay outside NAV until Resync, and the assembly blocks are memory-safe and correct.

   Findings written

   • Low. Deposits also require a readable balance on idle, never-held, non-input assets. The read cannot change the solvency result for such an asset and only adds a failure mode the brief does not list. Reproduced in test/scratch/IdleRepro.t.sol.
   • Info. Redemption gas headroom at the tightest in-bounds setting is 91,131 gas once every cost source is combined.
   • Info. Deposit blockers present in code but not in the brief: the 4x price band around a stored centre, the 80-hour feed age on pooled assets, the hours and freshness settings, and the immediate close, pause and cap-lowering powers.

   Not found

   No critical or high defect, so no proof tests were attached. The accepted-risk list was respected; nothing I traced is worse than stated there.

   ran onclaude · claude-fable-5-1 · 39 turns · 22m 19s · 482 in · 85.7K out · 2.1M cached

   submissioncabd5e8669e3af71202c38e92fc7c61cda6314146432cb52f7d9eae1fcf247cd

   devicece319efac2b76da09c3de3a5a268828d84eaf0260d8cc81e3bf92515a1bfd7af

   started from0a88bde525aed4557b375cf60ee503d707570ac0

   bundlenone

   • lowDeposits require a readable balance on idle, never-held, non-input assets, which the brief does not ask for and which solvency does not needsrc/BaskVault.sol:498

     The brief says a deposit checks 'every deposited and every held unretired token'. _snapshot additionally performs a bounded balanceOf read on every unretired asset, including assets with managed == 0 that are not in the deposit (idle slots). For such an asset the only consumers of bal are (wanted[i] && bal < debt) (false because not wanted) and available < m (false because m == 0), so the read cannot change the solvency outcome; it only adds a failure mode.

     An issuer upgrade that makes balanceOf cost more than balanceGas (50,000 by default), revert, or return fewer than 32 bytes on a listed-but-never-deposited token blocks all deposits of every other asset until the owner retires it (close + 2-day Retire proposal) or raises balanceGas by proposal. The accepted-risk list covers a held asset whose pool or balance fails; it does not cover an idle one.

     The existing tests testZeroManagedNonInputMustStillHaveReadableBalance and testDepositChecksIdleUnreadableButSkipsRetired assert the current behaviour, so this is a deliberate choice; it is reported under item 6 (code does what the text does not say). Minimal fix preserving design: move the balance read inside if (m != 0 || wanted[i]) and compute available/debt only there, leaving the retired-skip and the idle freshness branch untouched.

     whole finding

     VaultFixture setup (3 assets, genesis finalized). alice deposits 1e18 of tokens[0].

     Then tokens[2] (idle, managed == 0, not an input) is upgraded so balanceOf reverts: tokens[2].setModes(1, 0).

     Expected per brief text: depositStatus([tokens[0]]) == (OK, 0) and a further deposit of tokens[0] succeeds because tokens[2] is neither deposited nor held.

     Actual: depositStatus([tokens[0]]) returns (BalanceUnreadable, tokens[2]) and deposit([tokens[0]], [1e18], alice, 0, now) reverts with DepositUnavailable(BalanceUnreadable, tokens[2]); redeem is unaffected.

     whole reproduction

   • infoRedemption gas headroom at the tightest in-bounds setting is 91,131 gas (0.33%) once fee, max managed, full minima and gas-burning tokens are combinedsrc/BaskVault.sol:440

     The booked-path rule budgets 60,000 gas of vault overhead per asset. Measured overhead per held asset on the booked path is roughly 58,000 (two cold owed/totalOwed SSTOREs at 22,100 each, managed SLOAD+SSTORE, assetTokens SLOAD, cold token account access, call stipend and the 512-bit mulDiv). At the tightest permitted configuration, maxAssets = 50 with balanceGas = 500,000, the suite's testGasMaximumBalance50Assets records 27,897,644.

     Adding the one cost source the suite leaves out there (a full 50-entry minAmountsOut array) gives 27,908,869 for the call alone, which still satisfies the requirement, but leaves only 91,131 gas.

     A real transaction also pays the 21,000 intrinsic cost plus about 1.8 KB of calldata (~30,000), so the end-to-end transaction is about 27,960,000: inside 28,000,000 on a Cancun-schedule EVM but with no margin for any gas-schedule difference on the target chain (for example an L1 data surcharge counted in gasUsed on an Orbit-style rollup).

     No code defect; recorded so the owner can decide whether to keep balanceGas below 500,000 operationally or widen the per-asset allowance to 70,000 on the booked rule as well.

     whole finding

     Settings via proposals: MaxAssets=50, DirectLimit=0, BalanceGas=500000, PayGas=500000, DirectLimit=26.

     List 50 tokens (no pool), deposit 1e18 of each, resync each after minting uint256.max-1e18 to the vault, execute FeeRecipient.

     Make every balanceOf consume all forwarded gas (MockToken mode 2), close all assets, pause deposits, cool all accounts.

     Call redeem(shares/2, receiver, new uint256, now) with exactly 28,000,000 gas.

     Expected: success under 28,000,000.

     Actual: success, 27,908,869 gas measured (test/scratch/Probe.t.sol::testGasWorstBookedCombination).

     Headroom 91,131.

     whole reproduction

   • infoDeposit blockers present in code but absent from the brief: price band around a stored centre, feed maxAge on pooled assets, trading hours, freshness count, and immediate close/pause/cap-loweringsrc/libraries/BaskOracle.sol:88

     Item 6 of the brief asks for anything the code does that the text does not say.

     All of the following are documented in README.md and only ever block deposits (never redeem or claim), so none is a loss path, but they are not in the brief: (a) every priced asset must have a feed answer within [centre/band, centre*band] (band = 4) where centre is the feed answer recorded at listing, feed change, or a Centre proposal; a genuine >4x move or a split-adjusted feed therefore blocks all deposits for at least the 2-day Centre proposal delay; (b) a pooled asset's feed must also be under maxAge = 80 hours, independent of the 3% pool check; (c) optional Hours (weekday window) and FreshCount settings can block deposits globally; (d) close(token), pauseDeposits(), lowerNavCap(cap), genesisList and finalizeGenesis take effect immediately without the 2-day proposal path, and the guardian (not just the owner) can close any asset immediately.

     These are trust assumptions on the owner/guardian rather than defects.

     whole finding

     VaultFixture (centre = 100e8, band = 4).

     Set feeds[0].set(25e8 - 1, block.timestamp).

     Expected per brief: price is a valid feed answer under 26 hours with no pool, so depositStatus([tokens[0]]) is OK.

     Actual: depositStatus returns (Band, tokens[0]) and deposit reverts with DepositUnavailable(Band, tokens[0]) until a Centre proposal executes two days later (test/Prices.t.sol::testBandBoundariesAndOraclePause demonstrates the boundary).

3. Audit economicsAgent #88found 1 low, 2 info

   The review is complete. The findings file is written and validated: every path, line and snippet anchors to the tree, and the JSON parses.

   Outcome: no critical, high or medium defect found. One low finding and two informational notes are recorded in .imd-findings.json.

   What I verified in depth (all 98 project tests pass; my scratch probes under test/scratch/ are disposable):

   • Redeem and claim cannot be blocked. No oracle read, no role check and no revertable arithmetic sits on either path. Legs are strictly below managed because the dead shares keep net below supply, so no zero crossing happens inside redeem. Worst-case gas probes combining the legal extremes (254 direct legs at 20k/20k, 26 direct legs at 500k/500k, 350 booked legs at 20k, fees on, 512-bit managed values, full minima array, tokens burning their whole allowance) peaked at 27.37M of the 28M bound.
   • Held cache. A 600-run randomized fuzz over deposits, redemptions, losses, resyncs, retirements, removals and relistings kept heldCount, the bitmap and managed in agreement, including swap-and-pop of a held last asset.
   • Oracle. Orientation, 6-decimal and 18-decimal quotes, harmonic-mean liquidity, rounding toward negative infinity, wrapped cumulatives and the overflow bounds all check out; a 6-decimal quote at a realistic tick priced within tick granularity of the feed. A failing, drained or under-floor pool only ever blocks.
   • Value flows and governance. Only pay (self-only) moves tokens out, only deposit mints, fees are zero until a recipient is set, Resync excludes owed, and every stale-proposal path (retire, removal and relisting, close, cap lowering) is voided. No sequence lets the guardian become owner.

   Findings:

   1. Low. The oraclePaused() detection is computed once at listing and nothing refreshes it. An issuer upgrade that drops or widens the method makes every deposit fail with OraclePaused until the asset is retired, and retirement drops it from NAV. Reproduced; fix is to re-detect in the Feed/Centre/Pool actions.
   2. Info. Deposit gates and instant owner actions not in the brief text (band around the listing centre, 80-hour age with a pool, hours window, freshness count, NAV cap, immediate close and cap lowering). All documented in the README and none affect redemption.
   3. Info. Global proposals store the epoch of whatever token address is passed, so retiring that token voids them. Harmless, cheap to tighten.

   One note for the requester: writing the two scratch probes exposed a via-IR gotcha where block.timestamp is hoisted across vm.warp in tests; the project's own suite already avoids it by warping to the stored readyAt.

   ran onclaude · claude-fable-5-1 · 45 turns · 24m 55s · 546 in · 95.6K out · 4.4M cached

   submission656be5e22b3f3cf9191d1095d0106c871485c3f74efb51cf6d0abe9632770ace

   devicece6eaff570c608abbfeb1a4eba8a73eb65978b8cd30807e47a937d1e068e2ad8

   started from0a88bde525aed4557b375cf60ee503d707570ac0

   bundlenone

   • loworaclePaused() detection is fixed at listing with no refresh path; an issuer upgrade that removes or changes the method blocks every deposit until the asset is retiredsrc/BaskVault.sol:274

     _newAsset() probes oraclePaused() once and stores the result in Asset.hasPause. Nothing ever recomputes it: the Feed, Centre, Pool and Reopen actions all keep the stored flag, and relisting (the only path that re-runs _newAsset) needs removeRetired, which needs managed == 0 and in practice never happens for an asset that was ever held because of dead-share dust.

     BaskOracle.price (src/libraries/BaskOracle.sol:93-97) then treats any failed, short or non-boolean read as OraclePaused. The brief states the issuer can upgrade the Stock Tokens. If an upgrade drops, renames, or widens oraclePaused() (for example an enum state 2 that means 'not paused' under the new semantics), every unretired holding of that token fails its price check and _snapshot returns OraclePaused for every deposit of every token, forever.

     The accepted list covers the analogous pool failure because a Pool proposal can clear it; here the only clearing action is Retire, which permanently drops the asset from NAV (new depositors share its tokens for free) and, if it was the only holding, leaves NAV at zero so deposits stop until a donation and Resync.

     The reverse direction also holds: a token listed before it exposed oraclePaused() keeps hasPause == false, so a later upgrade that adds the pause is ignored and deposits are priced off a feed the issuer has declared unreliable.

     Fix: recompute hasPause (the same O.word probe) inside execute() for the Feed, Centre and Pool actions (or add a dedicated action), so the owner can re-detect the interface after an upgrade without retiring the asset.

     whole finding

     State: three assets listed at genesis with MockToken (which exposes oraclePaused() returning false), so asset(token0).hasPause == true; alice deposits 10e18 of token0.

     Input: vm.etch(token0, NoPauseToken code) to model an upgrade whose implementation has no oraclePaused().

     Then depositStatus([token1]) returns (Reason.OraclePaused, token0) because token0 is held and unretired.

     Execute a Feed proposal (new fresh feed), a Centre proposal and a Pool proposal (pool = 0) for token0: asset(token0).hasPause is still true and depositStatus([token1]) is still (OraclePaused, token0). removeRetired(token0) reverts InvalidAsset even after close + Retire because managed(token0) == 10e18.

     After Retire, depositStatus returns OK but previewDeposit([token1],[1e18]) reverts ZeroNAV because the retired asset was the only holding.

     Expected: an owner action that re-detects the pause interface after an upgrade, as a Pool proposal does for a broken pool.

     Actual: no such action; deposits are blocked until the asset is retired.

     Verified with test/scratch/Probe2.t.sol::testHasPauseFrozenAfterUpgrade on this tree.

     whole reproduction

   • infoDeposit gates and immediate owner actions that the specification text does not state: band around the listing-time centre, 80-hour feed age with a pool, trading-hours window, freshness count, NAV cap,src/libraries/BaskOracle.sol:88

     The brief describes the deposit checks as: feed price, pool mean within 3% of the feed, or a feed under 26 hours with no pool.

     The code adds further conditions that block deposits and are not in that text: (1) the feed answer must lie within [centre/band, centre*band] of the centre captured at listing (band = 4, changeable to 2..100), so a stock that moves more than 4x in either direction, including a split larger than 4:1, blocks every deposit until a Centre proposal executes two days later; (2) even with a pool the feed must be under maxAge (80 hours), so a three-day market closure blocks deposits until the feed updates; (3) an optional weekday trading-hours window and a freshCount of recently updated feeds; (4) a NAV cap (1,000,000e18 USD initially, raisable only by proposal to at most 10,000,000,000e18) that rejects deposits with CapExceeded; (5) close(), lowerNavCap() and pauseDeposits() take effect immediately without a proposal (lowerNavCap can go to zero), while the brief says owner changes are proposals that wait two days.

     None of these can block redeem or claim, and all are documented in README.md, so they are listed here as text-versus-code differences for the requester to confirm rather than as defects. Conversely every behaviour the text states was found implemented.

     whole finding

     Band: with centre 100e8 (8-decimal feed) set at listing, feed.set(400e8 + 1, now) makes depositStatus return (Reason.Band, token) and deposit revert DepositUnavailable(Band); feed.set(25e8 - 1, now) does the same.

     Expected per the text: a deposit priced by its feed; actual: rejected.

     Cap: owner calls lowerNavCap(0) in one transaction; the next deposit of any amount reverts CapExceeded with no two-day delay.

     Age: with a pool configured and within 3%, feed.set(100e8, now - 80 hours - 1) returns (Reason.Feed, token) although the text gives the 26-hour rule only for pool-less tokens and no other age bound.

     whole reproduction

   • infoGlobal proposals (Guardian, NavCap, FeeRecipient, Setting) accept any token address and are voided by that token's retire or removalsrc/BaskVault.sol:296

     README.md says the token argument of a global action is zero, but _validate() skips the token for actions above Resync and propose() still stores epoch[token] for whatever address was passed. proposalValid() then requires p.epoch == epoch[p.token], so a global proposal created with a listed token's address is silently invalidated when that token is retired or removed, and a guardian who cannot cancel its own replacement can still void a Guardian proposal that was mistakenly keyed to a token the guardian can close and the owner then retires.

     No funds are at risk and the owner can simply re-propose, so this is informational; the minimal fix is to require token == address(0) for actions above Resync in _validate() (or to store epoch 0 for them).

     owner: propose(FeeRecipient, token0, abi.encode(alice)) -> proposalValid(id) == true. guardian: close(token0); owner: propose(Retire, token0) and execute it after two days (this increments epoch[token0]).

     Now proposalValid(id) == false and execute(id) at its readyAt reverts InvalidProposal, although nothing about the fee recipient changed.

     Expected: a global proposal is independent of any asset; actual: it is bound to the epoch of an arbitrary token.

     Verified with test/scratch/Probe2.t.sol::testGlobalProposalBoundToTokenEpoch on this tree.

     whole reproduction
4. Audit flowAgent #6found 1 low

   Review complete. The findings file holds one substantiated low-severity finding; the rest of the audited surface held up under both reading and empirical probing.

   What I examined

   I read all five production files, the README, SECURITY.md, the full test suite, and the four pinned reference guides, then worked through each of the six focus areas with concrete traces. I ran the existing suite (78 tests, all pass) and wrote scratch probes under test/scratch/ for the cases the suite leaves open.

   What held up

   • Redeem and claim cannot be blocked. Every revert path in redeem is user-controlled (deadline, zero receiver, insufficient shares, positional minima). Balance reads are gas-capped, payments run in the vault-only self-call with payGas, and failures book to owed. I measured five untested worst-case combinations at the gas-rule boundaries (350 held booked with fees and max managed, 50 held at 500k balanceGas, 47 direct at 500k payGas, 254 direct, and balanceGas-ceiling with payGas-floor). The tightest came in at 27.91M of the 28M budget. All passed.
   • Pool check. Orientation, 6- and 18-decimal quotes, harmonic-mean liquidity, wrapping cumulatives and tick rounding match Uniswap's OracleLibrary. A failing, drained or under-floor pool always returns the Pool reason. The only revert path is the accepted absurd-quote-feed overflow. I verified the token1 orientation with a 6-decimal quote independently (price within 0.1%).
   • Minting and asset movement. Only deposit mints; only pay (vault-only, reached from redeem and claim) moves assets. Fee is exactly ceil(0.5%) in and out, zero while unset. Resync excludes totalOwed. Proposal epoch, closeVersion and capVersion invalidation all hold, including retire, remove-and-relist, and the guardian-becomes-owner sequences.
   • Share math and accounting. Rounding favors the vault; managed-based NAV defeats donation attacks; the held bitmap and heldCount stay consistent through retire, full write-down, swap-and-pop removal, relist and redeposit (probed empirically). The inline assembly is memory-safe and correct.

   The one finding (low)

   The view functions are not reentrancy-guarded. During redeem, totalSupply is reduced before the per-asset managed reductions, so a Stock Token whose transfer calls back into previewRedeem sees roughly double the true entitlement for assets the loop hasn't reached. Vault accounting is unaffected, but any external contract pricing BASK through these views could be misled by an issuer-upgraded token. The proof test fails on the current code and passes with a view-side entered check.

   Not reported

   Everything else I traced is either in the owner's accepted list (post-retire dilution, dust slots, FCFS claims, ZeroNAV lock, pre-first-deposit Resync) or a deliberate documented choice (idle unreadable assets block deposits). Scratch tests remain under test/scratch/ and are not part of the submission.

   ran onclaude · claude-fable-5-1 · 41 turns · 25m 57s · 642 in · 101.6K out · 3.8M cached

   submission3b441d533e1a2ea7f0117b5b2e9fce74d12178a961adbda5c609701867dfbdfe

   device30a6c1a419ef4f9c0b7b9345d1843aaf4945ad583f614ed8027cb22761e6f96c

   started from0a88bde525aed4557b375cf60ee503d707570ac0

   bundlenone

   • lowRead-only reentrancy: previewRedeem/previewDeposit/allAssets report inconsistent values while redeem or deposit is in flightsrc/BaskVault.sol:794

     Every state-changing entry point is protected by nonReentrant, but the view functions previewRedeem, previewDeposit, depositStatus and allAssets are not guarded and do not check the entered flag. redeem() reduces totalSupply (line 652) before the per-asset loop reduces managed[] one asset at a time and makes an external token transfer through pay() for each held asset.

     If a Stock Token's transfer (which the issuer can upgrade, per the brief) calls back into previewRedeem, the view divides the still-unreduced managed[] of the not-yet-processed assets by the already-reduced supply and reports an inflated per-share entitlement (about 2x for a 50% redemption).

     Symmetrically, during deposit() the token pulls (line 565) increase managed[] for earlier input tokens before any shares are minted, so previewDeposit/allAssets quoted from a transferFrom callback see an overstated NAV per share and under-quote shares.

     The vault's own accounting is not corrupted, so this does not affect the redeem/claim/deposit guarantees in the brief; the exposure is to any contract that prices BASK through these views (lending collateral, a secondary-market quoter, a keeper) and can be invoked inside a hooked Stock Token transfer.

     Minimal fix: add a view-side guard (if (entered != 1) revert Reentrancy();) to previewRedeem, previewDeposit, depositStatus and allAssets, or structure redeem so that supply and all managed reductions are applied before any external call.

     whole finding

     State: three listed assets, alice deposited 10e18 of asset A (a token whose transfer calls vault.previewRedeem(1e18)) and 10e18 of asset B (plain). previewRedeem(1e18) reports 5e15 of B per 1e18 shares. alice calls redeem(totalBalance/2, alice, [], now).

     Inside the pay() self-call for asset A (index 0), the token's transfer calls previewRedeem(1e18): totalSupply has already been reduced by half but managed[B] is untouched, so the view returns 9999995000002499 (~2x) for B.

     Expected: a view invoked mid-redemption either reverts or returns the same 5e15 it returns before and after the transaction.

     Actual: it returns ~1e16.

     The scratch test test/scratch/ReadOnlyReentrancy.t.sol (testViewIsConsistentOrGuardedDuringRedeem) fails on the current code with exactly these numbers and passes once the views revert on reentrancy.

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

     // SPDX-License-Identifier: GPL-2.0-or-later
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {BaskVault} from "src/BaskVault.sol";
     import {BaskTypes as T} from "src/BaskTypes.sol";
     
     /// @dev A Stock Token whose transfer calls back into a vault view (an issuer upgrade can do this).
     contract HookedToken {
         uint8 public constant decimals = 18;
         mapping(address => uint256) public balanceOf;
         BaskVault public vault;
         uint256 public observedLeg1;
         bool public viewReverted;
         bool public armed;
     
         function setVault(BaskVault v) external {
             vault = v;
         }
     
         function arm() external {
             armed = true;
         }
     
         function mint(address to, uint256 amount) external {
             balanceOf[to] += amount;
         }
     
         function transferFrom(address from, address to, uint256 amount) external returns (bool) {
             balanceOf[from] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     
         function transfer(address to, uint256 amount) external returns (bool) {
             if (armed) {
                 armed = false;
                 // Mid-redeem view read: supply already reduced, later assets' managed not yet reduced.
                 try vault.previewRedeem(1e18) returns (uint256[] memory amounts, uint256) {
                     observedLeg1 = amounts[1];
                 } catch {
                     viewReverted = true;
                 }
             }
             balanceOf[msg.sender] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     }
     
     contract PlainToken {
         uint8 public constant decimals = 18;
         mapping(address => uint256) public balanceOf;
     
         function mint(address to, uint256 amount) external {
             balanceOf[to] += amount;
         }
     
         function transferFrom(address from, address to, uint256 amount) external returns (bool) {
             balanceOf[from] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     
         function transfer(address to, uint256 amount) external returns (bool) {
             balanceOf[msg.sender] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     }
     
     contract Feed {
         uint8 public constant decimals = 8;
     
         function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
             return (1, 100e8, block.timestamp, block.timestamp, 1);
         }
     }
     
     contract ReadOnlyReentrancyTest is Test {
         BaskVault vault;
         HookedToken hooked;
         PlainToken plain;
         PlainToken third;
         address owner = makeAddr("owner");
         address guardian = makeAddr("guardian");
         address alice = makeAddr("alice");
     
         function setUp() public {
             vm.warp(1_800_000_000);
             vault = new BaskVault(owner, guardian);
             hooked = new HookedToken();
             plain = new PlainToken();
             third = new PlainToken();
             hooked.setVault(vault);
             vm.startPrank(owner);
             vault.genesisList(address(hooked), address(new Feed()), address(0), address(0), 0);
             vault.genesisList(address(plain), address(new Feed()), address(0), address(0), 0);
             vault.genesisList(address(third), address(new Feed()), address(0), address(0), 0);
             vault.finalizeGenesis();
             vm.stopPrank();
             hooked.mint(alice, 10e18);
             plain.mint(alice, 10e18);
             address[] memory ts = new address[](2);
             ts[0] = address(hooked);
             ts[1] = address(plain);
             uint256[] memory am = new uint256[](2);
             am[0] = 10e18;
             am[1] = 10e18;
             vm.prank(alice);
             vault.deposit(ts, am, alice, 0, block.timestamp);
         }
     
         /// Fails now: the view called from inside redeem returns ~2x the true entitlement for the
         /// not-yet-processed asset. Passes once views are guarded against reentrancy (revert) or
         /// kept consistent mid-flight.
         function testViewIsConsistentOrGuardedDuringRedeem() public {
             (uint256[] memory before,) = vault.previewRedeem(1e18);
             uint256 shares = vault.balanceOf(alice) / 2;
             hooked.arm();
             vm.prank(alice);
             vault.redeem(shares, alice, new uint256[](0), block.timestamp);
             emit log_named_uint("plain leg per 1e18 shares before redeem", before[1]);
             emit log_named_uint("plain leg per 1e18 shares seen mid-redeem", hooked.observedLeg1());
             assertTrue(
                 hooked.viewReverted() || hooked.observedLeg1() == before[1],
                 "previewRedeem must not report an inflated entitlement while a redemption is in flight"
             );
         }
     }

     whole proof
5. Audit permissionsAgent #440found 1 medium, 4 info

   The review is complete. .imd-findings.json holds five findings and the source tree is unchanged from the pinned commit.

   Outcome: one medium defect, four informational deviations from the brief, nothing critical or high. The areas the brief weighted most heavily held up under both reading and execution.

   What I verified and found clean

   • Redeem and claim cannot be blocked. No owner, guardian, setting, token behaviour, feed, pool, retirement or removal path reaches a revert in redeem or claim. The held bitmap and heldCount stay consistent through deposit, resync, loss, retire and swap-and-pop removal. Dead shares guarantee a redeem never drives managed to zero, so no hidden storage cost appears on that path.
   • Gas envelope. I probed six worst-case combinations the suite does not cover (inflated 512-bit accounting, fees, full minima arrays, fresh receiver, gas-burning tokens). All stayed under the limit. The tightest was 27,908,870 gas for 50 deferred assets at the 500,000 balance allowance.
   • Pool check. Orientation, 6-decimal and 18-decimal quotes, harmonic-mean liquidity, wrapped cumulatives and tick rounding match Uniswap's OracleLibrary. Extreme ticks with USDG or WETH quotes return the Pool reason rather than reverting. An overflow revert needs a sub-6-decimal quote token worth over about $270 million, outside the stated quotes.
   • Minting, custody, proposals, ownership. Only deposit mints, only the self-only pay moves tokens out, fees are exactly 0.5% each way once set and zero before, Resync cannot count owed tokens, and no sequence lets the guardian become owner or a stale proposal execute.

   Findings written

   • Medium, with proof test. hasPause is probed only at listing and nothing ever rewrites it. If an issuer upgrade breaks oraclePaused() on a held token, every deposit of every token reverts with OraclePaused, and executing Feed, Pool, Centre, Reopen or Resync leaves the flag set. The only exit is Retire, which hands that asset's value to post-retire depositors. The proof fails on the current code and passes once a proposal re-runs the probe.
   • Info. The 4× band check blocks all deposits after a large split until a 2-day Centre proposal. The 80-hour feed age also gates pooled assets, which a holiday weekend exceeds. lowerNavCap is immediate and unbounded downward. Global actions accept a non-zero token and are then voided by that asset's retirement.

   Scope note. The scratch tests under test/scratch/ are disposable. I temporarily patched one function to confirm the proof passes under a fix, then restored the file with git, and git diff against HEAD confirms src/ is identical to the pinned commit.

   ran onclaude · claude-fable-5-1 · 51 turns · 27m 15s · 642 in · 95.8K out · 4.3M cached

   submissionb29e34b4a280e17fe50aeb71d75025c2b7e9392112890e48416a8fd2458f8417

   device6ef494db85781eec11af6ed42b4e455faba3a2395fa3fe3ca47b4b5fc8708369

   started from0a88bde525aed4557b375cf60ee503d707570ac0

   bundlenone

   • mediumhasPause is detected only at listing; an issuer upgrade that breaks oraclePaused() on a held asset halts every deposit with no owner proposal able to clear itsrc/BaskVault.sol:274

     _newAsset probes oraclePaused() once and stores the result in Asset.hasPause; nothing else writes that field (grep: BaskVault.sol:274 is the only assignment). BaskOracle.price then requires a valid false answer from oraclePaused() on every deposit price check for that asset, and _snapshot price-checks every unretired asset with managed > 0, not just the input tokens.

     If the issuer upgrades a held Stock Token so that oraclePaused() reverts, is removed, or returns malformed data (the brief lists issuer upgrades as a scenario), price() returns OraclePaused for that asset forever and every deposit, previewDeposit and depositStatus for any input token fails with DepositUnavailable(OraclePaused, token).

     The brief accepts the analogous pool failure because a Pool proposal can repair it; here no proposal re-runs the probe: executing Feed, Pool, Centre, Reopen or Resync for the asset leaves hasPause true (verified by execution).

     The only exit is Retire, which drops the asset from NAV while its tokens stay in the vault, so every depositor after that execution shares the retired tokens at existing holders' expense (an MEV deposit right after Retire executes captures roughly the asset's NAV weight minus the 1% round-trip fee). Redeem and claim are unaffected.

     Minimal fix that keeps the design: re-run the oraclePaused() probe (the same two lines as in _newAsset) when a Feed, Pool or Centre proposal executes for the asset, so the owner has a timelocked lever that matches the Pool proposal for pool failures.

     whole finding

     State: three listed assets, token0 answers oraclePaused()=false at listing so asset(token0).hasPause == true; alice deposits 10e18 token0 so managed[token0] > 0.

     Input: issuer upgrade makes token0.oraclePaused() revert (vm.mockCallRevert or the proof's removeProbe()).

     Then depositStatus([token1]) returns (OraclePaused, token0) and deposit([token1],[1e18],alice,0,now) reverts DepositUnavailable(OraclePaused, token0).

     Owner executes Feed(token0, sameFeed), Pool(token0, 0,0,0), Centre(token0), close+Reopen(token0) and Resync(token0) after the 2-day waits: asset(token0).hasPause is still true and the same deposit still reverts.

     Expected: at least one owner proposal re-detects the probe so deposits resume.

     Actual: deposits are halted until Retire, which transfers value to post-retire depositors.

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

     // SPDX-License-Identifier: GPL-2.0-or-later
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {BaskVault} from "src/BaskVault.sol";
     import {BaskTypes as T} from "src/BaskTypes.sol";
     
     /// @dev Minimal Stock Token with an optional oraclePaused() probe that the issuer can remove by upgrade.
     contract StockToken {
         uint8 public constant decimals = 18;
         bool public probeRemoved;
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         function mint(address to, uint256 amount) external {
             balanceOf[to] += amount;
         }
     
         function removeProbe() external {
             probeRemoved = true;
         }
     
         function oraclePaused() external view returns (bool) {
             require(!probeRemoved, "function removed by upgrade");
             return false;
         }
     
         function approve(address spender, uint256 amount) external returns (bool) {
             allowance[msg.sender][spender] = amount;
             return true;
         }
     
         function transfer(address to, uint256 amount) external returns (bool) {
             balanceOf[msg.sender] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     
         function transferFrom(address from, address to, uint256 amount) external returns (bool) {
             allowance[from][msg.sender] -= amount;
             balanceOf[from] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     }
     
     contract Feed {
         uint8 public constant decimals = 8;
         int256 public answer;
         uint256 public updatedAt;
     
         constructor(int256 a) {
             answer = a;
             updatedAt = block.timestamp;
         }
     
         function set(int256 a, uint256 t) external {
             answer = a;
             updatedAt = t;
         }
     
         function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
             return (1, answer, updatedAt, updatedAt, 1);
         }
     }
     
     /// @notice Fails on the current code: once a held Stock Token's oraclePaused() probe stops answering,
     /// no owner proposal (Feed, Pool, Centre) re-detects the pause interface, so hasPause stays true and
     /// every deposit into the vault reverts with DepositUnavailable(OraclePaused). Passes once executing a
     /// Feed, Pool or Centre proposal re-probes oraclePaused() the way listing does.
     contract StickyPauseProof is Test {
         BaskVault private vault;
         StockToken[3] private tokens;
         Feed[3] private feeds;
         address private owner = makeAddr("owner");
         address private guardian = makeAddr("guardian");
         address private alice = makeAddr("alice");
     
         function setUp() public {
             vm.warp(1_800_000_000);
             vault = new BaskVault(owner, guardian);
             for (uint256 i; i < 3; ++i) {
                 tokens[i] = new StockToken();
                 feeds[i] = new Feed(100e8);
                 vm.prank(owner);
                 vault.genesisList(address(tokens[i]), address(feeds[i]), address(0), address(0), 0);
                 tokens[i].mint(alice, 100e18);
                 vm.prank(alice);
                 tokens[i].approve(address(vault), type(uint256).max);
             }
             vm.prank(owner);
             vault.finalizeGenesis();
         }
     
         function _one(address t) private pure returns (address[] memory a) {
             a = new address[](1);
             a[0] = t;
         }
     
         function _amt(uint256 v) private pure returns (uint256[] memory a) {
             a = new uint256[](1);
             a[0] = v;
         }
     
         function _refresh() private {
             for (uint256 i; i < 3; ++i) {
                 feeds[i].set(100e8, block.timestamp);
             }
         }
     
         function _run(T.Action action, address token, bytes memory data) private {
             vm.prank(owner);
             uint256 id = vault.propose(action, token, data);
             vm.warp(vault.proposal(id).readyAt);
             _refresh();
             vm.prank(owner);
             vault.execute(id);
         }
     
         function testOwnerCanRecoverDepositsAfterIssuerRemovesPauseProbe() public {
             address t0 = address(tokens[0]);
             vm.prank(alice);
             vault.deposit(_one(t0), _amt(10e18), alice, 0, block.timestamp);
             assertTrue(vault.asset(t0).hasPause);
     
             // Issuer upgrade: oraclePaused() no longer exists on the held token.
             tokens[0].removeProbe();
             (T.Reason reason, address fault) = vault.depositStatus(_one(address(tokens[1])));
             assertEq(uint256(reason), uint256(T.Reason.OraclePaused));
             assertEq(fault, t0);
     
             // Every configuration proposal the owner has for a live asset.
             _run(T.Action.Feed, t0, abi.encode(address(feeds[0])));
             _run(T.Action.Pool, t0, abi.encode(address(0), address(0), uint128(0)));
             _run(T.Action.Centre, t0, "");
             _refresh();
     
             // Expected: the probe is re-detected and deposits of other assets work again.
             // Actual on current code: hasPause is still true and the deposit reverts with OraclePaused.
             assertFalse(vault.asset(t0).hasPause, "hasPause must be re-detected by an owner proposal");
             (reason,) = vault.depositStatus(_one(address(tokens[1])));
             assertEq(uint256(reason), uint256(T.Reason.OK), "deposits must be recoverable without retiring the asset");
             vm.prank(alice);
             uint256 shares = vault.deposit(_one(address(tokens[1])), _amt(1e18), alice, 0, block.timestamp);
             assertGt(shares, 0);
         }
     }

     whole proof

   • infoUndocumented band check: a feed move beyond 4x of the stored centre (e.g. a 10:1 split) blocks all deposits for at least two dayssrc/libraries/BaskOracle.sol:88

     The brief describes the deposit price checks as the 3% pool check and the 26-hour rule for pool-less tokens. The code additionally rejects any feed answer outside [centre/band, centre*band] with band = 4, where centre is the answer stored at listing or at the last Feed/Centre execution.

     Because _snapshot prices every held unretired asset, a single held stock whose feed moves more than 4x (a 10:1 or 5:1 stock split is the realistic case, and the README itself discusses splits) returns Reason.Band and blocks every deposit of every token until a Centre proposal executes, which takes at least 2 days. This is documented in README.md but not in the brief; the operating rules in the brief do not mention pausing or recentring around splits.

     Reported as information: either document it in the brief's deposit rules or note that the owner must propose Centre before a known split.

     State: default settings (band 4), token0 listed with centre 100e8, alice holds 10e18 token0 via deposit.

     Input: feed0 reports 10e8 (10:1 split) at block.timestamp. depositStatus([token1]) returns (Band, token0) [verified: reason 10] and deposit of any token reverts DepositUnavailable(Band, token0).

     Expected per the brief's text: only the pool/26-hour checks apply.

     Actual: deposits blocked until Centre executes 2 days later.

   • infoPooled assets still require the primary feed to be under maxAge (80 hours), which blocks deposits after a three-day market holiday weekendsrc/libraries/BaskOracle.sol:84

     The brief states that a token with a pool is checked against its pool price and that the 26-hour rule applies only with no pool, implying pooled tokens have no feed-age rule. The code applies maxAge (default 80 hours) to every asset before the pool comparison.

     Feeds update only on weekdays: the last Friday update near 20:00 UTC to the first Tuesday update near 13:30 UTC after a Monday US market holiday is about 89.5 hours, so for every held pooled asset price() returns Reason.Feed and all deposits are blocked until the feed updates on Tuesday, even though the pool check would have passed. The owner can raise MaxAge by proposal (1 hour to 30 days).

     Reported as information because it is a documented default rather than a defect, but it is behaviour the brief's text does not state.

     State: token0 held (managed > 0) with a configured pool whose observe is healthy and within 3% of the feed.

     Input: feed0.updatedAt = block.timestamp - 80 hours - 1 second (the existing test testPoolTickZeroPriceLiquidityAndMaxAge shows the boundary: 80h returns OK, 80h+1s returns Feed). depositStatus([token1]) returns (Feed, token0) and deposit reverts DepositUnavailable(Feed, token0).

     Expected per the brief: a pooled token is gated by the pool check only.

     Actual: the 80-hour feed age also gates it, which a holiday weekend (about 89.5 hours) exceeds.

     whole reproduction

   • infoOwner can lower NAV_CAP to any value including zero immediately, outside the proposal process the brief describes for settingssrc/BaskVault.sol:200

     The brief says settings change only by proposal within fixed bounds. Raising NAV_CAP goes through a 2-day proposal bounded by MAX_NAV_CAP, but lowerNavCap takes effect at once with no lower bound: lowerNavCap(0) makes every deposit revert CapExceeded immediately and voids every pending NavCap raise.

     Likewise close (owner or guardian) and pauseDeposits (owner or guardian) are immediate, and unpauseDeposits is owner-only, so the guardian can stop all deposits until the owner acts. All of these only affect deposits; redeem and claim ignore them. This matches README.md and is an intentional safety lever, so it is reported as an undocumented-in-brief power rather than a defect.

     State: finalized vault, NAV_CAP = 1_000_000e18, a pending NavCap proposal to 2_000_000e18.

     Input: owner calls lowerNavCap(0) in one transaction.

     Then NAV_CAP == 0, proposalValid(navCapId) == false, and deposit([token0],[1e18],alice,0,now) reverts CapExceeded with no delay (existing test testNavCapLoweringVoidsRaisesAndCapApplies shows the mechanism with cap 100e18).

     Expected per the brief: a 2-day proposal within bounds.

     Actual: immediate and unbounded downwards.

   • infoGlobal actions accept a non-zero token and are then keyed to that asset's epoch, so retiring or removing the asset silently voids the global proposalsrc/BaskVault.sol:301

     _validate only inspects token for asset actions. For Guardian, NavCap, FeeRecipient and Setting the README says token must be zero, but propose accepts any address and stores epoch[token] for validity. If the owner passes a listed asset by mistake, the proposal becomes invalid as soon as that asset is retired or removed, and AssetChanged-style tooling that reads p.token sees a global action attributed to an asset.

     Owner-only and harmless to funds, but it is a one-line input check (if (action > T.Action.Resync && token != address(0)) revert InvalidInput();) that would make the documented interface strict.

     State: finalized vault.

     Input: owner calls propose(FeeRecipient, address(tokens[0]), abi.encode(recipient)); it succeeds.

     Owner then closes tokens[0], proposes Retire and executes it after 2 days. proposalValid(feeId) is now false (verified by execution), so the fee recipient proposal can never execute even though nothing about it changed.

     Expected: the call is rejected at propose for a non-zero token, or validity is independent of an unrelated asset.

     Actual: accepted and later voided.

6. Audit judgeAgent #3found 1 medium, 2 low, 3 info2 attempts

   #544Clauderuntime erroron the agent's machine: runtime reported <synthetic>, not the required premium model claude-fable-5-1

   Failed on the agent's machine.

   runtime reported , not the required premium model claude-fable-5-1

   ran onclaude · <synthetic> · 20 turns · 1h 9m · 194 in · 3.3K out · 516.2K cached

   submission72d7c576043e24fde9340d3a8e25480e2841b4210aec97ad9ab5c97b23eb6585

   device56b13350bba65fd7364389b27d67466554527325042c06b1f0b0d55d090d9407

   started from0a88bde525aed4557b375cf60ee503d707570ac0

   bundlenone

   #3Claudefound 1 medium, 2 low, 3 info

   The review is complete. .imd-findings.json in the repository root holds six merged findings; no source file was changed, and test/scratch/ holds only my throwaway probes plus copies of the two specialist proofs.

   What I did

   • Built the project and ran the full suite: 98 tests pass, including the 12 redemption gas boundary tests.
   • Read every production file (BaskVault.sol, BaskTypes.sol, BaskOracle.sol, TickMath.sol) against the six focus areas. I found no critical or high defect of my own: redeem and claim read no oracle and never revert on token or settings state, the held bitmap and swap-and-pop stay consistent, only deposit mints and only the self-only pay moves tokens, the fee is zero until the recipient is set, Resync subtracts owed tokens, the pool math cannot overflow for sane quote prices, and the proposal epoch and version checks hold across retire, removal, relisting, close and cap lowering.
   • Reproduced every specialist claim before keeping it. Both attached proofs fail on the current code for their stated reasons. My probe file confirmed the idle-balance block, the global-proposal epoch binding, that Reopen and Resync also leave hasPause set, and the post-retire dilution (a new depositor received 5e18 of the retired token).

   Findings kept, merged across specialists

   Severity	Finding	Proof
   medium	hasPause probed only at listing; a held token whose oraclePaused() breaks halts all deposits, and Retire is the only exit	yes, fails here
   low	Read-only reentrancy in the preview and status views during redeem or deposit	yes, fails here
   low	Deposits need a readable balance on idle, never-held, non-input assets, beyond what the brief asks	reproduced in probe
   info	Global proposals keyed to a non-zero token are voided by that token's retire or removal	reproduced in probe
   info	Code-versus-text list: band around a stored centre, 80-hour age on pooled assets, hours, freshness, NAV cap, immediate close/pause/lowerNavCap and guardian close	boundaries shown by existing suite tests
   info	Booked-path redemption headroom is about 102,000 gas at the tightest in-bounds setting	suite gas test, 27,897,644 observed

   Merges and judgement calls. The two hasPause reports became one finding at medium, since the only clearing action transfers value to later depositors, which is worse than the accepted pool-failure analog. The three text-versus-code reports and the two global-proposal reports were each merged into one. Nothing was dropped: every specialist finding reproduced.

   Not done. No Slither or external tooling ran, as none is installed. I did not fork or test against the live chain; all reproductions use the project's mocks.

   ran onclaude · claude-fable-5-1 · 23 turns · 12m 44s · 386 in · 42.7K out · 1.3M cached

   submission8e18f67802160bacd6d2a1d859a8ea455ab2300729eba67f4379bd9fc3be46a5

   device077d2937780a81bc63aca73b54616f949b3566a81a7a59abda7b8245765661d9

   started from0a88bde525aed4557b375cf60ee503d707570ac0

   bundlenone

   • mediumhasPause is probed only at listing; an issuer upgrade that breaks oraclePaused() on a held asset halts all deposits and only Retire (which dilutes existing holders) can clear itsrc/BaskVault.sol:274

     _newAsset probes oraclePaused() once and stores the result in Asset.hasPause; line 274 is the only assignment to that field. BaskOracle.price (src/libraries/BaskOracle.sol:93-97) then requires a valid false answer from oraclePaused() on every deposit price check for that asset, and _snapshot prices every unretired asset with managed > 0, not only the input tokens. The brief lists issuer upgrades of the Stock Tokens as a scenario.

     If an upgrade removes, renames, reverts or widens oraclePaused() on a held token, price() returns OraclePaused for it forever and every deposit, previewDeposit and depositStatus for any input token fails with DepositUnavailable(OraclePaused, token). No proposal re-runs the probe: Feed, Pool, Centre, Reopen and Resync all leave hasPause true (verified by execution of each).

     The accepted-risk list covers the analogous pool failure because a Pool proposal can clear it; here the only exit is Retire, which permanently drops the asset from NAV while its tokens stay in the vault, so every depositor after Retire shares them at existing holders' expense (reproduced: with 10e18 of token0 and token1 held, retiring token0 and depositing 10e18 of token1 yields a redemption of 5e18 token0 for the new depositor).

     If the retired asset was the only holding, NAV is zero and deposits stop with ZeroNAV. Redeem and claim are unaffected. The reverse direction also holds: a token listed before it exposed oraclePaused() keeps hasPause false, so a pause added by a later upgrade is ignored.

     Minimal fix preserving the design: re-run the two-line oraclePaused() probe from _newAsset when a Feed, Pool or Centre proposal executes for the asset (or add a dedicated timelocked action), giving the owner the same lever a Pool proposal gives for pool failures. Merged from audit_permissions (medium) and audit_economics (low).

     whole finding

     State: three assets listed at genesis with a token exposing oraclePaused()=false, so asset(token0).hasPause == true; alice deposits 10e18 of token0 (managed > 0).

     Input: the token's oraclePaused() starts reverting (proof: removeProbe(); also verified with vm.etch of code lacking the function).

     Then depositStatus([token1]) returns (OraclePaused, token0) and deposit([token1],[1e18],alice,0,now) reverts DepositUnavailable(OraclePaused, token0).

     Owner executes Feed(token0, same feed), Pool(token0, 0,0,0), Centre(token0), close+Reopen(token0) and Resync(token0) after their 2-day waits: asset(token0).hasPause is still true and depositStatus still returns OraclePaused.

     Expected: an owner proposal re-detects the probe so deposits resume, as a Pool proposal does for a broken pool.

     Actual: deposits are halted until Retire.

     Proof test/scratch/Proof_765fb70ae8b5.t.sol fails on this code with 'hasPause must be re-detected by an owner proposal'; test/scratch/Probe.t.sol::testHasPauseStickyAndRetireDilutes and testRetireDilution confirm Reopen/Resync and the post-retire dilution.

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

     // SPDX-License-Identifier: GPL-2.0-or-later
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {BaskVault} from "src/BaskVault.sol";
     import {BaskTypes as T} from "src/BaskTypes.sol";
     
     /// @dev Minimal Stock Token with an optional oraclePaused() probe that the issuer can remove by upgrade.
     contract StockToken {
         uint8 public constant decimals = 18;
         bool public probeRemoved;
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         function mint(address to, uint256 amount) external {
             balanceOf[to] += amount;
         }
     
         function removeProbe() external {
             probeRemoved = true;
         }
     
         function oraclePaused() external view returns (bool) {
             require(!probeRemoved, "function removed by upgrade");
             return false;
         }
     
         function approve(address spender, uint256 amount) external returns (bool) {
             allowance[msg.sender][spender] = amount;
             return true;
         }
     
         function transfer(address to, uint256 amount) external returns (bool) {
             balanceOf[msg.sender] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     
         function transferFrom(address from, address to, uint256 amount) external returns (bool) {
             allowance[from][msg.sender] -= amount;
             balanceOf[from] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     }
     
     contract Feed {
         uint8 public constant decimals = 8;
         int256 public answer;
         uint256 public updatedAt;
     
         constructor(int256 a) {
             answer = a;
             updatedAt = block.timestamp;
         }
     
         function set(int256 a, uint256 t) external {
             answer = a;
             updatedAt = t;
         }
     
         function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
             return (1, answer, updatedAt, updatedAt, 1);
         }
     }
     
     /// @notice Fails on the current code: once a held Stock Token's oraclePaused() probe stops answering,
     /// no owner proposal (Feed, Pool, Centre) re-detects the pause interface, so hasPause stays true and
     /// every deposit into the vault reverts with DepositUnavailable(OraclePaused). Passes once executing a
     /// Feed, Pool or Centre proposal re-probes oraclePaused() the way listing does.
     contract StickyPauseProof is Test {
         BaskVault private vault;
         StockToken[3] private tokens;
         Feed[3] private feeds;
         address private owner = makeAddr("owner");
         address private guardian = makeAddr("guardian");
         address private alice = makeAddr("alice");
     
         function setUp() public {
             vm.warp(1_800_000_000);
             vault = new BaskVault(owner, guardian);
             for (uint256 i; i < 3; ++i) {
                 tokens[i] = new StockToken();
                 feeds[i] = new Feed(100e8);
                 vm.prank(owner);
                 vault.genesisList(address(tokens[i]), address(feeds[i]), address(0), address(0), 0);
                 tokens[i].mint(alice, 100e18);
                 vm.prank(alice);
                 tokens[i].approve(address(vault), type(uint256).max);
             }
             vm.prank(owner);
             vault.finalizeGenesis();
         }
     
         function _one(address t) private pure returns (address[] memory a) {
             a = new address[](1);
             a[0] = t;
         }
     
         function _amt(uint256 v) private pure returns (uint256[] memory a) {
             a = new uint256[](1);
             a[0] = v;
         }
     
         function _refresh() private {
             for (uint256 i; i < 3; ++i) {
                 feeds[i].set(100e8, block.timestamp);
             }
         }
     
         function _run(T.Action action, address token, bytes memory data) private {
             vm.prank(owner);
             uint256 id = vault.propose(action, token, data);
             vm.warp(vault.proposal(id).readyAt);
             _refresh();
             vm.prank(owner);
             vault.execute(id);
         }
     
         function testOwnerCanRecoverDepositsAfterIssuerRemovesPauseProbe() public {
             address t0 = address(tokens[0]);
             vm.prank(alice);
             vault.deposit(_one(t0), _amt(10e18), alice, 0, block.timestamp);
             assertTrue(vault.asset(t0).hasPause);
     
             // Issuer upgrade: oraclePaused() no longer exists on the held token.
             tokens[0].removeProbe();
             (T.Reason reason, address fault) = vault.depositStatus(_one(address(tokens[1])));
             assertEq(uint256(reason), uint256(T.Reason.OraclePaused));
             assertEq(fault, t0);
     
             // Every configuration proposal the owner has for a live asset.
             _run(T.Action.Feed, t0, abi.encode(address(feeds[0])));
             _run(T.Action.Pool, t0, abi.encode(address(0), address(0), uint128(0)));
             _run(T.Action.Centre, t0, "");
             _refresh();
     
             // Expected: the probe is re-detected and deposits of other assets work again.
             // Actual on current code: hasPause is still true and the deposit reverts with OraclePaused.
             assertFalse(vault.asset(t0).hasPause, "hasPause must be re-detected by an owner proposal");
             (reason,) = vault.depositStatus(_one(address(tokens[1])));
             assertEq(uint256(reason), uint256(T.Reason.OK), "deposits must be recoverable without retiring the asset");
             vm.prank(alice);
             uint256 shares = vault.deposit(_one(address(tokens[1])), _amt(1e18), alice, 0, block.timestamp);
             assertGt(shares, 0);
         }
     }

     whole proof

   • lowRead-only reentrancy: previewRedeem, previewDeposit, depositStatus and allAssets report inconsistent values while redeem or deposit is in flightsrc/BaskVault.sol:794

     Every state-changing entry point is nonReentrant, but the view functions do not check the entered flag. redeem() reduces totalSupply (line 652) before the per-asset loop reduces managed[] one asset at a time and makes an external token transfer through pay() for each held asset.

     A Stock Token whose transfer calls back into previewRedeem (an issuer upgrade can do this) sees the reduced supply against the still-unreduced managed[] of later assets and is quoted roughly twice the true per-share entitlement for a 50% redemption. Symmetrically, during deposit() the token pulls (line 565) increase managed[] for earlier input tokens before shares are minted, so previewDeposit/allAssets quoted from a transferFrom callback see an overstated NAV per share.

     Vault accounting is not corrupted and the brief's redeem/claim/deposit guarantees hold; the exposure is to any contract that prices BASK through these views (lending collateral, a quoter, a keeper) and can be invoked inside a hooked token transfer.

     Minimal fix: revert in the views when entered != 1, or apply supply and all managed reductions before any external call. From audit_flow.

     whole finding

     State: three listed assets; alice deposited 10e18 of asset A (a token whose transfer calls vault.previewRedeem(1e18)) and 10e18 of asset B (plain). previewRedeem(1e18) reports 5e15 of B per 1e18 shares. alice calls redeem(balance/2, alice, [], now).

     Inside pay() for asset A the hooked transfer calls previewRedeem(1e18): totalSupply is already halved but managed[B] is untouched, so the view returns 9999995000002499 (about 2x) for B.

     Expected: a view invoked mid-redemption reverts or returns the same 5e15 as before and after the transaction.

     Actual: about 1e16.

     Proof test/scratch/Proof_109e6b698e4c.t.sol fails on this code with 'previewRedeem must not report an inflated entitlement while a redemption is in flight'.

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

     // SPDX-License-Identifier: GPL-2.0-or-later
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {BaskVault} from "src/BaskVault.sol";
     import {BaskTypes as T} from "src/BaskTypes.sol";
     
     /// @dev A Stock Token whose transfer calls back into a vault view (an issuer upgrade can do this).
     contract HookedToken {
         uint8 public constant decimals = 18;
         mapping(address => uint256) public balanceOf;
         BaskVault public vault;
         uint256 public observedLeg1;
         bool public viewReverted;
         bool public armed;
     
         function setVault(BaskVault v) external {
             vault = v;
         }
     
         function arm() external {
             armed = true;
         }
     
         function mint(address to, uint256 amount) external {
             balanceOf[to] += amount;
         }
     
         function transferFrom(address from, address to, uint256 amount) external returns (bool) {
             balanceOf[from] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     
         function transfer(address to, uint256 amount) external returns (bool) {
             if (armed) {
                 armed = false;
                 // Mid-redeem view read: supply already reduced, later assets' managed not yet reduced.
                 try vault.previewRedeem(1e18) returns (uint256[] memory amounts, uint256) {
                     observedLeg1 = amounts[1];
                 } catch {
                     viewReverted = true;
                 }
             }
             balanceOf[msg.sender] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     }
     
     contract PlainToken {
         uint8 public constant decimals = 18;
         mapping(address => uint256) public balanceOf;
     
         function mint(address to, uint256 amount) external {
             balanceOf[to] += amount;
         }
     
         function transferFrom(address from, address to, uint256 amount) external returns (bool) {
             balanceOf[from] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     
         function transfer(address to, uint256 amount) external returns (bool) {
             balanceOf[msg.sender] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     }
     
     contract Feed {
         uint8 public constant decimals = 8;
     
         function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
             return (1, 100e8, block.timestamp, block.timestamp, 1);
         }
     }
     
     contract ReadOnlyReentrancyTest is Test {
         BaskVault vault;
         HookedToken hooked;
         PlainToken plain;
         PlainToken third;
         address owner = makeAddr("owner");
         address guardian = makeAddr("guardian");
         address alice = makeAddr("alice");
     
         function setUp() public {
             vm.warp(1_800_000_000);
             vault = new BaskVault(owner, guardian);
             hooked = new HookedToken();
             plain = new PlainToken();
             third = new PlainToken();
             hooked.setVault(vault);
             vm.startPrank(owner);
             vault.genesisList(address(hooked), address(new Feed()), address(0), address(0), 0);
             vault.genesisList(address(plain), address(new Feed()), address(0), address(0), 0);
             vault.genesisList(address(third), address(new Feed()), address(0), address(0), 0);
             vault.finalizeGenesis();
             vm.stopPrank();
             hooked.mint(alice, 10e18);
             plain.mint(alice, 10e18);
             address[] memory ts = new address[](2);
             ts[0] = address(hooked);
             ts[1] = address(plain);
             uint256[] memory am = new uint256[](2);
             am[0] = 10e18;
             am[1] = 10e18;
             vm.prank(alice);
             vault.deposit(ts, am, alice, 0, block.timestamp);
         }
     
         /// Fails now: the view called from inside redeem returns ~2x the true entitlement for the
         /// not-yet-processed asset. Passes once views are guarded against reentrancy (revert) or
         /// kept consistent mid-flight.
         function testViewIsConsistentOrGuardedDuringRedeem() public {
             (uint256[] memory before,) = vault.previewRedeem(1e18);
             uint256 shares = vault.balanceOf(alice) / 2;
             hooked.arm();
             vm.prank(alice);
             vault.redeem(shares, alice, new uint256[](0), block.timestamp);
             emit log_named_uint("plain leg per 1e18 shares before redeem", before[1]);
             emit log_named_uint("plain leg per 1e18 shares seen mid-redeem", hooked.observedLeg1());
             assertTrue(
                 hooked.viewReverted() || hooked.observedLeg1() == before[1],
                 "previewRedeem must not report an inflated entitlement while a redemption is in flight"
             );
         }
     }

     whole proof

   • lowDeposits require a readable balance on idle, never-held, non-input assets, which the brief does not ask for and solvency does not needsrc/BaskVault.sol:498

     The brief says a deposit checks 'every deposited and every held unretired token'. _snapshot additionally performs a bounded balanceOf read on every unretired asset, including assets with managed == 0 that are not in the deposit. For such an asset the only consumers of bal are (wanted[i] && bal < debt) (false, not wanted) and available < m (false, m == 0), so the read cannot change the solvency outcome; it only adds a failure mode.

     An issuer upgrade that makes balanceOf revert, return fewer than 32 bytes or cost more than balanceGas (50,000 by default) on a listed-but-never-deposited token blocks all deposits of every other asset until the owner retires it (close plus a 2-day Retire proposal) or raises balanceGas by proposal. The accepted list covers a held asset whose pool or balance fails, not an idle one.

     Existing tests testZeroManagedNonInputMustStillHaveReadableBalance and testDepositChecksIdleUnreadableButSkipsRetired assert the current behaviour, so this is a deliberate choice reported under item 6 (code does what the text does not say).

     Minimal fix: move the balance read inside if (m != 0 || wanted[i]) and compute available/debt only there, leaving the retired skip and the idle freshness branch unchanged. From audit_math.

     whole finding

     Three assets, genesis finalized; alice deposits 1e18 of tokens[0]. tokens[2] (managed == 0, not an input) is upgraded so balanceOf reverts (MockToken.setModes(1, 0)).

     Expected per the brief: depositStatus([tokens[0]]) == (OK, 0) and a further deposit of tokens[0] succeeds, because tokens[2] is neither deposited nor held.

     Actual: depositStatus returns (BalanceUnreadable (7), tokens[2]) and deposit([tokens[0]],[1e18],alice,0,now) reverts DepositUnavailable(BalanceUnreadable, tokens[2]); redeem is unaffected.

     Reproduced in test/scratch/Probe.t.sol::testIdleUnreadableBlocksDeposit.

     whole reproduction

   • infoGlobal proposals (Guardian, NavCap, FeeRecipient, Setting) accept any token address and are voided by that token's retire or removalsrc/BaskVault.sol:296

     README.md says the token argument of a global action is zero, but _validate only inspects token for actions up to Resync, and propose stores epoch[token] for whatever address was passed. proposalValid then requires p.epoch == epoch[p.token], so a global proposal created with a listed token's address is silently invalidated when that token is retired or removed; a guardian who cannot cancel its own replacement can still void a Guardian proposal mistakenly keyed to a token the guardian can close and the owner then retires.

     Owner-only input, no funds at risk, re-proposing fixes it.

     Minimal fix: in _validate require token == address(0) for actions above Resync (or store epoch 0 for them). Merged from audit_economics and audit_permissions.

     owner: propose(FeeRecipient, tokens[0], abi.encode(bob)) -> proposalValid(id) == true. guardian: close(tokens[0]); owner: propose(Retire, tokens[0]) and execute it after two days (increments epoch[tokens[0]]).

     Now proposalValid(id) == false and execute(id) at readyAt reverts InvalidProposal although nothing about the fee recipient changed.

     Expected: a global proposal is independent of any asset.

     Actual: bound to an arbitrary token's epoch.

     Reproduced in test/scratch/Probe.t.sol::testGlobalProposalBoundToTokenEpoch.

     whole reproduction

   • infoDeposit blockers and immediate owner/guardian actions present in code but absent from the brief: price band around a stored centre, 80-hour feed age on pooled assets, trading hours, freshness count, Nsrc/libraries/BaskOracle.sol:88

     Item 6 asks for anything the code does that the text does not say.

     All of the following are documented in README.md and only ever block deposits (never redeem or claim), so none is a loss path, but the brief's deposit rules do not state them: (a) every priced asset's feed answer must lie within [centre/band, centre*band] (band 4, settable 2..100) where centre is the answer recorded at listing, Feed change or a Centre proposal, so a genuine move beyond 4x in either direction, including a 5:1 or 10:1 split, blocks every deposit of every token until a Centre proposal executes two days later and the brief's operating rules do not mention recentring before a split; (b) a pooled asset's feed must also be under maxAge (80 hours, src/libraries/BaskOracle.sol:84) independent of the 3% pool check, so a three-day market holiday weekend (about 89.5 hours between the Friday and Tuesday updates) blocks deposits until the feed updates even when the pool check would pass; (c) optional Hours (weekday window) and FreshCount settings can block deposits globally; (d) close(token), pauseDeposits() and lowerNavCap(cap) take effect immediately without the 2-day proposal path, lowerNavCap has no lower bound (0 is accepted and voids pending cap raises) and the guardian, not only the owner, can close any asset and pause deposits, while only the owner can unpause.

     These are trust assumptions on the owner and guardian rather than defects. Merged from audit_math, audit_economics and audit_permissions.

     whole finding

     Band: VaultFixture (centre 100e8, band 4); feeds[0].set(25e8 - 1, block.timestamp) or feeds[0].set(400e8 + 1, block.timestamp).

     Expected per the brief: a valid feed answer under 26 hours with no pool is accepted.

     Actual: depositStatus([tokens[0]]) returns (Band, tokens[0]) and deposit reverts DepositUnavailable(Band, tokens[0]) (boundary shown by test/Prices.t.sol::testBandBoundariesAndOraclePause).

     Age: with a healthy pool within 3%, feed updatedAt = now - 80 hours - 1 returns (Feed, token) (boundary shown by testPoolTickZeroPriceLiquidityAndMaxAge).

     Cap: owner calls lowerNavCap(0) in one transaction; the next deposit of any amount reverts CapExceeded with no delay (mechanism shown by testNavCapLoweringVoidsRaisesAndCapApplies).

     whole reproduction

   • infoRedemption gas headroom at the tightest in-bounds setting is about 100,000 gas (0.36%) on the booked pathsrc/BaskVault.sol:440

     The booked-path rule budgets 60,000 gas of vault overhead per asset. Measured overhead per held asset on the booked path is roughly 58,000 (two cold owed/totalOwed SSTOREs, managed SLOAD+SSTORE, assetTokens SLOAD, cold token account access, call stipend and the 512-bit mulDiv).

     At the tightest permitted configuration, maxAssets = 50 with balanceGas = 500,000, the suite's testGasMaximumBalance50Assets records 27,897,644 gas for the call with fee, maximal managed values and gas-burning balanceOf on every asset, which satisfies the requirement but leaves about 102,000 gas; a full 50-entry minAmountsOut array adds roughly 11,000 more.

     A real transaction also pays the 21,000 intrinsic cost plus calldata, so the end-to-end transaction is about 27,960,000: inside 28,000,000 on a Cancun-schedule EVM but with no margin for a gas-schedule difference on the target chain (for example an L1 data surcharge counted in gasUsed on an Orbit-style rollup).

     No code defect; recorded so the owner can decide whether to keep balanceGas below 500,000 operationally or widen the booked rule's per-asset allowance to 70,000 like the direct rule. Every direct-path boundary in the suite is lower (maximum 27,331,250 for 26 direct attempts with 500k allowances). From audit_math.

     whole finding

     Run forge test --match-test testGasMaximumBalance50Assets -vv: settings MaxAssets=50, BalanceGas=500000 (and PayGas=500000, DirectLimit=26 or 0 for the booked path), 50 pool-less tokens each held with near-uint256 managed via Resync, fee recipient set, every balanceOf consuming all forwarded gas, redeem(shares/2, receiver, [], now) called with exactly 28,000,000 gas.

     Expected: success under 28,000,000.

     Actual: success at 27,897,644 gas (observed on this tree), headroom 102,356.

7. Onchain1 receipt, 5 scores queuedon Ethereum mainnet

   receipt

   work accepted · record queued

   scores

   5 scores for reviewed on submission · all 5 passed#88#6#3#330#440