Four agents audited the code as it is at 3b1fe81, 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 medium3 low4 info

• 1.mediumIssuer-credited tokens (stock split, stock dividend, rebase-up) never enter managed: NAV is understated and the extra tokens are stranded in the vault foreversrc/BaskVault.sol:647

          managed[token] += amount;

  deposit is the only writer that increases managed[token], and it only adds the exact amount it pulled. NAV (line 590) and every redemption leg (line 674) read managed only, and no entry point ever moves a balance increase that did not arrive through deposit into managed.

  For an index of Stock Tokens this is not just the documented donation rule: a forward stock split, a stock dividend or a rebasing token upgrade credits the vault with new tokens while the Chainlink per-share feed drops proportionally.

  The vault then values the position at a fraction of its real worth (half, for a 2-for-1 split), redeemers are paid only the managed-based leg, and the credited tokens stay in the contract with no exit: flagDeficit rejects the state (no shortfall), recognizeLoss cannot run, and there is no sweep. The accepted-risk list covers tokens the issuer returns after recognizeLoss; here no loss ever occurred and existing holders permanently lose the split half of their position.

  A reverse split (issuer burns) is handled by the loss path after seven days, so the asymmetry is one-directional. Fixing it changes the stated accounting rule, so it needs an owner decision: for example an owner proposal (7-day wait, guardian veto) that recognises surplus of a listed asset into managed, mirroring recognizeLoss, or a split-aware rescale of managed when a feed proposal executes.

  No proof file is attached because any fix requires a new entry point the test cannot name; the reproduction below is the test/scratch/Judge.t.sol::testStockSplitStrandsHalfOfHoldersPosition run on this tree. Merged from the audit_math report; it reproduces as described.

  whole finding

  State: 3 genesis assets at $100 (feed 100e8, band [25e8, 400e8]); Alice deposits 100 stock0 so managed[stock0] = 100e18 and previewDeposit(stock1, 1e18).nav == 10_000e18.

  Issuer performs a 2-for-1 split: vault balance of stock0 becomes 200e18 (stock0.mint(vault, 100e18)) and the feed reports 50e8 (inside the band).

  Expected: holders still own $10,000 of stock0 and a full redemption pays about 200 stock0.

  Actual on this tree: previewDeposit reports nav == 5_000e18; managed[stock0] stays 100e18; flagDeficit(stock0) reverts InvalidState; Alice redeeming all her shares receives leg 99.49999e18 stock0 while the vault keeps 100.50001e18 stock0 with managed[stock0] == 0.50001e18 and owed == totalOwed == 0.

  No entry point can ever release the ~100e18 surplus or count it in NAV.

  whole reproduction

• 2.lowRetiring an asset never releases its Chainlink feed binding, so a successor token for the same stock can never be listed with its true feedsrc/BaskVault.sol:428

              a.retired = true;

  _list writes feedAsset[feed] = token (line 476). The only writer that clears it is the Kind.Feed branch of executeProposal (line 411), which goes through _checkReplacement -> _liveAsset and therefore reverts InvalidState for a retired asset. The Retire branch sets a.retired = true and leaves feedAsset[a.feed] pointing at the retired token. _checkFeed (line 457) rejects any listing whose feed is bound to a different token.

  Retirement is the brief's remedy for a Stock Token that is closed for good, which on this chain includes the issuer reissuing the stock at a new token address (beacon proxies, factory uid -> token mapping). The replacement is priced by the same single Chainlink proxy, so after retirement the owner can neither list it with its true feed (InvalidFeed) nor move the retired entry off the feed (InvalidState).

  The stock is lost from the vault's universe for the life of the contract unless the owner deploys a wrapper feed, which contradicts the trust assumption that each token is paired with its true feed. The retired asset reads no price anywhere (every deposit check skips it, redeem reads no feed), so the binding is dead state. Minimal fix that preserves the design: delete feedAsset[a.feed] in the Retire branch; the attached proof passes with that one line.

  Merged from three specialist reports (audit_flow, audit_economics, audit_permissions); all three reproduce identically.

  whole finding

  State: genesis with stocks[0..2] and feeds[0..2], genesis finalized, 72 hours elapsed.

  1. owner: closeAsset(stocks[0]); id = proposeRetire(stocks[0]).

  2. warp +7 days; executeProposal(id) -> assets(0).retired == true and feedAsset(feeds[0]) == stocks[0].

  3. Deploy successor MockStock (decimals 18, new uid registered at STOCK_FACTORY). owner: proposeAsset(successor, feeds[0]).

  Expected: a listing proposal for the migrated stock priced by its true feed.

  Actual: revert InvalidFeed(feeds[0]) from _checkFeed.

  4. owner: proposeFeed(stocks[0], otherFeed) to free the slot.

  Expected: some path releases the binding.

  Actual: revert InvalidState from _liveAsset; feedAsset(feeds[0]) == stocks[0] forever.

  Reproduced in test/scratch/Judge.t.sol::testRetiredAssetLocksFeedForever; the attached proof fails on this tree with InvalidFeed and passes with delete feedAsset[a.feed] added to the Retire branch (verified on a patched copy).

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

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {BaskVault} from "src/BaskVault.sol";
  
  contract PFactory {
      mapping(bytes32 => address) public tokenAddress;
  
      function register(bytes32 id, address token) external {
          tokenAddress[id] = token;
      }
  }
  
  contract PFeed {
      uint8 public decimals = 8;
      address public aggregator = address(1);
      int256 public answer = 100e8;
      uint256 public updatedAt;
  
      constructor() {
          updatedAt = block.timestamp;
      }
  
      function set(int256 answer_, uint256 time_) external {
          answer = answer_;
          updatedAt = time_;
      }
  
      function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
          return (1, answer, updatedAt, updatedAt, 1);
      }
  }
  
  contract PStock {
      bytes32 public uid;
      uint8 public decimals = 18;
      bool public oraclePaused;
      mapping(address => uint256) public balanceOf;
      mapping(address => mapping(address => uint256)) public allowance;
  
      constructor(bytes32 id) {
          uid = id;
      }
  
      function mint(address to, uint256 amount) external {
          balanceOf[to] += amount;
      }
  
      function approve(address spender, uint256 amount) external returns (bool) {
          allowance[msg.sender][spender] = 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;
      }
  
      function transfer(address to, uint256 amount) external returns (bool) {
          balanceOf[msg.sender] -= amount;
          balanceOf[to] += amount;
          return true;
      }
  }
  
  /// Fails on the current code: after an asset is retired its Chainlink feed stays bound to the retired
  /// token forever, so a successor token for the same stock can never be listed with its true feed.
  /// Passes once retirement releases the feed binding (for example `delete feedAsset[a.feed]` in the
  /// Retire branch of executeProposal).
  contract ProofRetireLocksFeed is Test {
      address internal constant OWNER = 0x30B57ECf51D19ABcED7F6f70974e6fBb6f3b9Da3;
      address internal constant GUARDIAN = 0x5ed39AF86f2C00ad99913B5d727bD68f2A904B68;
      uint256 internal constant MONDAY = 1_728_259_200;
      BaskVault internal vault;
      PFactory internal factory;
      PStock[] internal stocks;
      PFeed[] internal feeds;
  
      function setUp() public {
          vm.chainId(4663);
          vm.warp(MONDAY + 55800);
          vault = new BaskVault(OWNER, GUARDIAN);
          PFactory template = new PFactory();
          vm.etch(vault.STOCK_FACTORY(), address(template).code);
          factory = PFactory(vault.STOCK_FACTORY());
          for (uint256 i; i < 3; ++i) {
              PStock stock = new PStock(bytes32(i + 1));
              PFeed feed = new PFeed();
              factory.register(stock.uid(), address(stock));
              stocks.push(stock);
              feeds.push(feed);
              vm.prank(OWNER);
              vault.proposeAsset(address(stock), address(feed));
          }
          vm.prank(OWNER);
          vault.finalizeGenesis();
          vm.warp(block.timestamp + 72 hours);
      }
  
      function testSuccessorTokenCanBeListedWithTheRetiredAssetsFeed() public {
          vm.startPrank(OWNER);
          vault.closeAsset(address(stocks[0]));
          uint256 id = vault.proposeRetire(address(stocks[0]));
          vm.stopPrank();
          vm.warp(block.timestamp + 7 days);
          vault.executeProposal(id);
          (,,, bool retired,,,,) = vault.assets(0);
          assertTrue(retired, "asset 0 retired");
  
          // the issuer re-issues the same stock at a new token address; its true feed is feeds[0]
          PStock successor = new PStock(bytes32(uint256(0x5e)));
          factory.register(successor.uid(), address(successor));
          feeds[0].set(100e8, block.timestamp);
  
          vm.prank(OWNER);
          uint256 listing = vault.proposeAsset(address(successor), address(feeds[0]));
          assertGt(listing, 0, "listing proposal created with the stock's true feed");
          vm.warp(block.timestamp + 7 days);
          vault.executeProposal(listing);
          assertEq(vault.assetIndex(address(successor)), 4, "successor listed");
          assertEq(vault.feedAsset(address(feeds[0])), address(successor), "feed now bound to successor");
      }
  }

  whole proof

• 3.lowA Stock Token upgraded to debit more than the transfer amount makes every claim for that asset revert forever, stranding the owed tokens with no recovery pathsrc/BaskVault.sol:722

          if (!afterOK || beforeBalance < afterBalance || beforeBalance - afterBalance != amount) {

  payLeg requires the vault balance to fall by exactly amount. On the redeem path that strictness is correct: the 250,000-gas self-call reverts, the token movement rolls back and the leg becomes owed. claim, however, reuses the same payLeg with the same exact-equality postcondition and has no alternative.

  If the issuer upgrades the token so that an outgoing transfer debits the sender amount plus a fee or burn (even 1 wei), while still crediting the receiver amount, reporting balances truthfully and returning true, then every redeem leg for that asset is booked as owed and every subsequent claim(token, to) reverts TransferFailed, from any caller, to any receiver, forever.

  The owed balance and the remaining holders' managed share of that token can never leave the vault; there is no sweep, rescue or retirement path that pays it. The README accepts that claims depend on the token moving funds and that a token lying about balances is out of scope; this token is not lying, it is charging a fee, and the vault could deliver amount to the user by tolerating a decrease of at least amount on the claim path.

  The fix is a design decision because the README states the exact-decrease rule: accept beforeBalance - afterBalance >= amount only in the claim path (the attached proof uses a separate self-only payLegClaim helper), keeping exactness on the redeem path. A hostile token gains nothing new from the looser check since the issuer can already burn vault balances directly. Merged from audit_flow and audit_math; both reproduce identically.

  whole finding

  State: 3 genesis assets; Alice deposits 10e18 stock0.

  Set stock0 to MockStock.Mode.ExtraDebit (transfer debits msg.sender amount + 1 wei, credits the receiver amount, returns true).

  Alice redeems all her shares: stock0 leg is booked as owed (owed[ALICE][stock0] = 9.95e18 - dust, managed reduced by the same, vault still holds 10e18).

  Alice calls claim(stock0, ALICE), then after warp +365 days claim(stock0, BOB).

  Expected per the brief: claim is not permanently blocked by a truthful token.

  Actual: both calls revert TransferFailed(stock0) from line 722-723 because beforeBalance - afterBalance == amount + 1; owed is unchanged and the vault still holds all 10e18.

  Reproduced in test/scratch/Judge.t.sol::testExtraDebitTokenStrandsClaimsForever; the attached proof fails on this tree with TransferFailed and passes once the claim path tolerates a decrease >= amount (verified on a patched copy).

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

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {BaskVault} from "src/BaskVault.sol";
  
  contract PFactory {
      mapping(bytes32 => address) public tokenAddress;
  
      function register(bytes32 id, address token) external {
          tokenAddress[id] = token;
      }
  }
  
  contract PFeed {
      uint8 public decimals = 8;
      address public aggregator = address(1);
      int256 public answer = 100e8;
      uint256 public updatedAt;
  
      constructor() {
          updatedAt = block.timestamp;
      }
  
      function set(int256 answer_, uint256 time_) external {
          answer = answer_;
          updatedAt = time_;
      }
  
      function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
          return (1, answer, updatedAt, updatedAt, 1);
      }
  }
  
  /// Stock Token whose issuer upgrade debits the sender one extra wei per outgoing transfer. It reports
  /// balances truthfully, credits the receiver the full amount and returns true.
  contract PStock {
      bytes32 public uid;
      uint8 public decimals = 18;
      bool public oraclePaused;
      bool public extraDebit;
      mapping(address => uint256) public balanceOf;
      mapping(address => mapping(address => uint256)) public allowance;
  
      constructor(bytes32 id) {
          uid = id;
      }
  
      function mint(address to, uint256 amount) external {
          balanceOf[to] += amount;
      }
  
      function setExtraDebit(bool on) external {
          extraDebit = on;
      }
  
      function approve(address spender, uint256 amount) external returns (bool) {
          allowance[msg.sender][spender] = 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;
      }
  
      function transfer(address to, uint256 amount) external returns (bool) {
          balanceOf[msg.sender] -= amount + (extraDebit ? 1 : 0);
          balanceOf[to] += amount;
          return true;
      }
  }
  
  /// Fails on the current code: once a Stock Token debits the vault by more than `amount`, redeem
  /// correctly isolates the leg as owed, but every later claim for that token reverts TransferFailed
  /// because claim reuses the exact-decrease postcondition, so the owed tokens can never leave the vault.
  /// Passes once the claim path accepts a vault balance decrease of at least `amount` (the user still
  /// receives exactly `amount`; the overage is the token's own fee), while redeem keeps the exact rule.
  contract ProofExtraDebitClaim is Test {
      address internal constant OWNER = 0x30B57ECf51D19ABcED7F6f70974e6fBb6f3b9Da3;
      address internal constant GUARDIAN = 0x5ed39AF86f2C00ad99913B5d727bD68f2A904B68;
      address internal constant ALICE = address(0xA11CE);
      uint256 internal constant MONDAY = 1_728_259_200;
      BaskVault internal vault;
      PFactory internal factory;
      PStock[] internal stocks;
      PFeed[] internal feeds;
  
      function setUp() public {
          vm.chainId(4663);
          vm.warp(MONDAY + 55800);
          vault = new BaskVault(OWNER, GUARDIAN);
          PFactory template = new PFactory();
          vm.etch(vault.STOCK_FACTORY(), address(template).code);
          factory = PFactory(vault.STOCK_FACTORY());
          for (uint256 i; i < 3; ++i) {
              PStock stock = new PStock(bytes32(i + 1));
              PFeed feed = new PFeed();
              factory.register(stock.uid(), address(stock));
              stocks.push(stock);
              feeds.push(feed);
              stock.mint(ALICE, 1_000e18);
              vm.prank(ALICE);
              stock.approve(address(vault), type(uint256).max);
              vm.prank(OWNER);
              vault.proposeAsset(address(stock), address(feed));
          }
          vm.prank(OWNER);
          vault.finalizeGenesis();
          vm.warp(block.timestamp + 72 hours);
          for (uint256 i; i < 3; ++i) {
              feeds[i].set(100e8, block.timestamp);
          }
      }
  
      function testOwedLegCanEventuallyBeClaimedFromAnExtraDebitToken() public {
          vm.prank(ALICE);
          vault.deposit(address(stocks[0]), 10e18, ALICE, 0, block.timestamp);
          stocks[0].setExtraDebit(true);
  
          uint256 shares = vault.balanceOf(ALICE);
          vm.prank(ALICE);
          vault.redeem(shares, new uint256[](0), block.timestamp);
          uint256 owed = vault.owed(ALICE, address(stocks[0]));
          assertGt(owed, 0, "leg isolated as owed");
  
          uint256 before = stocks[0].balanceOf(ALICE);
          vm.prank(ALICE);
          uint256 paid = vault.claim(address(stocks[0]), ALICE);
          assertEq(paid, owed, "claim pays the owed amount");
          assertEq(stocks[0].balanceOf(ALICE) - before, owed, "user received the owed tokens");
          assertEq(vault.owed(ALICE, address(stocks[0])), 0, "debt cleared");
          assertEq(vault.totalOwed(address(stocks[0])), 0, "total debt cleared");
      }
  }

  whole proof

• 4.lowThe guardian veto is a 7-day delay, not a block: the owner can replace the guardian with a proposal the guardian cannot cancel and then re-propose the vetoed retirementsrc/BaskVault.sol:391

          if (msg.sender != owner && (msg.sender != guardian || p.kind == Kind.Guardian)) revert Unauthorized();

  The brief states that owner changes wait 7 days and the guardian can veto, and asks whether retirement can skip the guardian veto. cancelProposal excludes Kind.Guardian from the guardian's cancel right. The owner can therefore propose a retirement and a guardian replacement in the same block; the guardian can cancel the retirement but not its own replacement.

  After 7 days the replacement executes, the owner re-proposes the retirement and the new guardian does not veto, so the retirement executes on day 14 with the README-documented dilution of existing holders. The same holds for every proposal kind, and for the immediate powers (closeAsset, pauseDeposits) the guardian's only recourse is the same race.

  The README documents that the guardian cannot cancel guardian replacement, so this is reported as a precise statement of the veto's strength (a delay of at most 14 days from first proposal) rather than an undocumented bypass, and as a trust assumption on the owner key. If a real veto is wanted, the sitting guardian should be able to cancel its own replacement, or the replacement should carry a longer delay than the proposals it can neutralise.

  No proof attached because the fix changes the documented governance rule.

  whole finding

  State: Alice deposits 100 stock0.

  Owner: closeAsset(stock0); id1 = proposeRetire(stock0); id2 = proposeGuardian(0x6A6A).

  Guardian: cancelProposal(id1) succeeds; cancelProposal(id2) reverts Unauthorized.

  Warp +7 days: executeProposal(id2) sets guardian == 0x6A6A.

  Owner: id3 = proposeRetire(stock0); the old guardian's cancelProposal(id3) reverts Unauthorized.

  Warp +7 days: executeProposal(id3) succeeds and assets(0).retired == true.

  Expected from the brief: the guardian's veto prevents the retirement.

  Actual: it postpones it by 7 days.

  Reproduced in test/scratch/Judge.t.sol::testGuardianVetoOfRetirementIsOnlyADelay.

  whole reproduction

• 5.infoThe 25,000 USD per-asset floor hard-bounds NAV at 25,000 USD times the asset count until more than 20 assets are listed; the 1,000,000 USD initial NAV_CAP is unreachable with 3 genesis assetssrc/BaskVault.sol:621

          uint256 cap = probation ? M.max(nav2 / 100, 5_000e18) : M.max(M.mulDiv(nav2, 5, 100), 25_000e18);

  The ordinary per-asset cap is max(5% of post-deposit NAV, 25,000e18). The 5% term only exceeds the floor once NAV2 > 500,000e18, but with N non-probation assets each stuck at the floor NAV cannot exceed 25,000e18 * N, and for N <= 20 the inequality value + delta <= max(0.05 * (NAV + delta), 25,000e18) fails for every delta > 0 once each asset holds 25,000e18. Probation assets add at most 5,000e18 of capacity for 30 days.

  So the 3-asset genesis basket has a hard ceiling of 75,000e18 regardless of NAV_CAP, and retiring one floor-level asset immediately blocks deposits into every remaining held asset until others are listed. This follows from the stated formula and is not a bypass; it is reported so the owner sizes the genesis basket and the NAV_CAP expectation accordingly. From audit_math; reproduces.

  State: 3 genesis assets at $100; Alice deposits 250 tokens (25,000e18 USD) into each; NAV = 75,000e18, NAV_CAP = 1,000,000e18.

  Expected by an operator reading the 5% rule with a 1M cap: further deposits possible.

  Actual: deposit(stock_i, 1 wei, ...) reverts DepositUnavailable(AssetCap, stock_i) for i in 0..2.

  Reproduced in test/scratch/Judge.t.sol::testPerAssetFloorBoundsNAVWithThreeAssets.

• 6.infoRetired assets permanently consume listing slots, so a vault that retires 62 tokens can never regain the three-fresh-feed deposit quorumsrc/BaskVault.sol:444

          if (assets.length >= MAX_ASSETS) revert AssetLimit();

  Assets are append-only and retirement does not free the slot. _checkListing rejects any listing once assets.length reaches 64, including when most entries are retired. Deposits need at least three unretired assets with a feed updated within 4 hours.

  Over the life of an immutable vault whose Stock Tokens can be paused, upgraded or migrated by the issuer, each broken token costs one slot forever; after 62 retirements deposits are permanently impossible while redeem and claim keep working. Not a bypass; an operational ceiling the README does not state.

  Related to, but mechanically distinct from, the feed-binding finding (different storage, different fix: allow a listing to reuse a retired slot, which changes the stated append-only rule). From audit_math; reproduces.

  State: 64 genesis assets; Alice deposits 1e18 of stocks[63].

  Owner: closeAsset + proposeRetire for stocks[0..61]; warp +7 days; executeProposal for all 62. assetCount() == 64.

  Owner: proposeAsset(newToken, newFeed) -> revert AssetLimit(). depositStatus(stocks[63]) == MarketNotFresh (fresh can never reach 3 with 2 unretired assets).

  Alice can still redeem all her shares.

  Reproduced in test/scratch/Judge.t.sol::testRetiredSlotsAreNeverFreedAndQuorumIsLost.

• 7.infoclaim accepts address(0) as the receiving address while deposit rejects it, so a mistaken claim burns the user's owed tokenssrc/BaskVault.sol:741

      function claim(address token, address to) external nonReentrant returns (uint256 amount) {

  deposit rejects receiver == address(0) and == address(this); claim validates nothing about to. A Stock Token that allows transfers to the zero address (the local mock does; many ERC-20s do) sends the owed tokens to 0x0, the exact-decrease check passes, and the owed record is cleared. Self-harm only, no effect on other users (claim to the vault's own address already reverts cleanly because the balance does not decrease).

  Reported as an input-validation asymmetry between the two user-facing receiver parameters; the fix is a one-line InvalidAddress check. From audit_math; reproduces.

  State: Alice deposits 100 stock0; the token blocks Alice; she redeems all shares so owed[ALICE][stock0] = 99.5e18.

  Alice calls claim(stock0, address(0)).

  Expected: revert InvalidAddress like deposit.

  Actual: returns 99.5e18, owed is zero and stock0.balanceOf(address(0)) == 99.5e18.

  Reproduced in test/scratch/Judge.t.sol::testClaimToZeroAddressBurnsOwedTokens; the attached proof fails on this tree (the call does not revert) and passes with the zero check added to claim (verified on a patched copy).

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

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {BaskVault} from "src/BaskVault.sol";
  
  contract PFactory {
      mapping(bytes32 => address) public tokenAddress;
  
      function register(bytes32 id, address token) external {
          tokenAddress[id] = token;
      }
  }
  
  contract PFeed {
      uint8 public decimals = 8;
      address public aggregator = address(1);
      int256 public answer = 100e8;
      uint256 public updatedAt;
  
      constructor() {
          updatedAt = block.timestamp;
      }
  
      function set(int256 answer_, uint256 time_) external {
          answer = answer_;
          updatedAt = time_;
      }
  
      function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
          return (1, answer, updatedAt, updatedAt, 1);
      }
  }
  
  /// Stock Token with an issuer blocklist; transfers to address(0) are allowed, as in many ERC-20s.
  contract PStock {
      bytes32 public uid;
      uint8 public decimals = 18;
      bool public oraclePaused;
      mapping(address => bool) public blocked;
      mapping(address => uint256) public balanceOf;
      mapping(address => mapping(address => uint256)) public allowance;
  
      constructor(bytes32 id) {
          uid = id;
      }
  
      function mint(address to, uint256 amount) external {
          balanceOf[to] += amount;
      }
  
      function blockAddress(address who, bool on) external {
          blocked[who] = on;
      }
  
      function approve(address spender, uint256 amount) external returns (bool) {
          allowance[msg.sender][spender] = amount;
          return true;
      }
  
      function transferFrom(address from, address to, uint256 amount) external returns (bool) {
          require(!blocked[from] && !blocked[to], "blocked");
          allowance[from][msg.sender] -= amount;
          balanceOf[from] -= amount;
          balanceOf[to] += amount;
          return true;
      }
  
      function transfer(address to, uint256 amount) external returns (bool) {
          require(!blocked[msg.sender] && !blocked[to], "blocked");
          balanceOf[msg.sender] -= amount;
          balanceOf[to] += amount;
          return true;
      }
  }
  
  /// Fails on the current code: claim(token, address(0)) sends the owed tokens to the zero address and
  /// clears the debt, while deposit rejects a zero receiver. Passes once claim rejects to == address(0)
  /// with InvalidAddress like deposit does.
  contract ProofClaimZeroAddress is Test {
      address internal constant OWNER = 0x30B57ECf51D19ABcED7F6f70974e6fBb6f3b9Da3;
      address internal constant GUARDIAN = 0x5ed39AF86f2C00ad99913B5d727bD68f2A904B68;
      address internal constant ALICE = address(0xA11CE);
      uint256 internal constant MONDAY = 1_728_259_200;
      BaskVault internal vault;
      PFactory internal factory;
      PStock[] internal stocks;
      PFeed[] internal feeds;
  
      function setUp() public {
          vm.chainId(4663);
          vm.warp(MONDAY + 55800);
          vault = new BaskVault(OWNER, GUARDIAN);
          PFactory template = new PFactory();
          vm.etch(vault.STOCK_FACTORY(), address(template).code);
          factory = PFactory(vault.STOCK_FACTORY());
          for (uint256 i; i < 3; ++i) {
              PStock stock = new PStock(bytes32(i + 1));
              PFeed feed = new PFeed();
              factory.register(stock.uid(), address(stock));
              stocks.push(stock);
              feeds.push(feed);
              stock.mint(ALICE, 1_000e18);
              vm.prank(ALICE);
              stock.approve(address(vault), type(uint256).max);
              vm.prank(OWNER);
              vault.proposeAsset(address(stock), address(feed));
          }
          vm.prank(OWNER);
          vault.finalizeGenesis();
          vm.warp(block.timestamp + 72 hours);
          for (uint256 i; i < 3; ++i) {
              feeds[i].set(100e8, block.timestamp);
          }
      }
  
      function testClaimRejectsZeroReceiverLikeDeposit() public {
          vm.prank(ALICE);
          vault.deposit(address(stocks[0]), 100e18, ALICE, 0, block.timestamp);
          stocks[0].blockAddress(ALICE, true);
          uint256 shares = vault.balanceOf(ALICE);
          vm.prank(ALICE);
          vault.redeem(shares, new uint256[](0), block.timestamp);
          uint256 owed = vault.owed(ALICE, address(stocks[0]));
          assertGt(owed, 0, "leg owed to the blocked redeemer");
  
          vm.prank(ALICE);
          vm.expectRevert(BaskVault.InvalidAddress.selector);
          vault.claim(address(stocks[0]), address(0));
          assertEq(vault.owed(ALICE, address(stocks[0])), owed, "debt preserved");
          assertEq(stocks[0].balanceOf(address(0)), 0, "nothing burned");
      }
  }

  whole proof

• 8.infoproposalState reports Pending for Reopen, Band and Feed proposals whose asset has since been retired, although they can never executesrc/BaskVault.sol:382

              (p.kind == Kind.Reopen && p.version != closeVersion[p.token])

  proposalState is documented as the effective lifecycle state and pendingProposals relies on it.

  It implements implicit cancellation for a Reopen whose closeVersion moved and a NAV-cap raise whose capVersion moved, but retirement is a third terminal event it does not reflect: after executeProposal(Retire), pending Reopen, Band and Feed proposals on that token still return State.Pending and are listed by pendingProposals, while executeProposal reverts InvalidState from _liveAsset on every attempt until they expire at 14 days.

  Monitoring that trusts the view (for example a guardian deciding what still needs a veto) sees live-looking proposals that are dead. No funds affected.

  Fix: in proposalState return State.Cancelled when p.token is a listed asset whose retired flag is set (same pattern as the existing version checks). From audit_permissions; reproduces.

  State: stocks[0] listed and open.

  Owner: closeAsset(stocks[0]); r = proposeReopen(stocks[0]); b = proposeBand(stocks[0]); f = proposeFeed(stocks[0], otherFeed); t = proposeRetire(stocks[0]).

  Warp +7 days; executeProposal(t).

  Expected: proposalState(r), (b), (f) are non-pending and pendingProposals(1, 10) omits them.

  Actual: all three return State.Pending (1), pendingProposals lists 3 ids, and executeProposal on each reverts InvalidState.

  Reproduced in test/scratch/Judge.t.sol::testProposalStateStaysPendingForDeadProposalsAfterRetire; the attached proof fails on this tree and passes with the retired-asset check added to proposalState (verified on a patched copy).

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

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  import {Test} from "forge-std/Test.sol";
  import {BaskVault} from "src/BaskVault.sol";
  
  contract PFactory {
      mapping(bytes32 => address) public tokenAddress;
  
      function register(bytes32 id, address token) external {
          tokenAddress[id] = token;
      }
  }
  
  contract PFeed {
      uint8 public decimals = 8;
      address public aggregator = address(1);
      int256 public answer = 100e8;
      uint256 public updatedAt;
  
      constructor() {
          updatedAt = block.timestamp;
      }
  
      function set(int256 answer_, uint256 time_) external {
          answer = answer_;
          updatedAt = time_;
      }
  
      function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
          return (1, answer, updatedAt, updatedAt, 1);
      }
  }
  
  contract PStock {
      bytes32 public uid;
      uint8 public decimals = 18;
      bool public oraclePaused;
      mapping(address => uint256) public balanceOf;
      mapping(address => mapping(address => uint256)) public allowance;
  
      constructor(bytes32 id) {
          uid = id;
      }
  
      function approve(address spender, uint256 amount) external returns (bool) {
          allowance[msg.sender][spender] = 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;
      }
  
      function transfer(address to, uint256 amount) external returns (bool) {
          balanceOf[msg.sender] -= amount;
          balanceOf[to] += amount;
          return true;
      }
  }
  
  /// Fails on the current code: after an asset is retired, pending Reopen, Band and Feed proposals on it
  /// still report State.Pending from proposalState and are listed by pendingProposals, although
  /// executeProposal reverts InvalidState on every one of them. Passes once proposalState reports a
  /// non-pending state (Cancelled) for asset-scoped proposals whose asset is retired.
  contract ProofProposalStateAfterRetire is Test {
      address internal constant OWNER = 0x30B57ECf51D19ABcED7F6f70974e6fBb6f3b9Da3;
      address internal constant GUARDIAN = 0x5ed39AF86f2C00ad99913B5d727bD68f2A904B68;
      uint256 internal constant MONDAY = 1_728_259_200;
      BaskVault internal vault;
      PFactory internal factory;
      PStock[] internal stocks;
      PFeed[] internal feeds;
  
      function setUp() public {
          vm.chainId(4663);
          vm.warp(MONDAY + 55800);
          vault = new BaskVault(OWNER, GUARDIAN);
          PFactory template = new PFactory();
          vm.etch(vault.STOCK_FACTORY(), address(template).code);
          factory = PFactory(vault.STOCK_FACTORY());
          for (uint256 i; i < 3; ++i) {
              PStock stock = new PStock(bytes32(i + 1));
              PFeed feed = new PFeed();
              factory.register(stock.uid(), address(stock));
              stocks.push(stock);
              feeds.push(feed);
              vm.prank(OWNER);
              vault.proposeAsset(address(stock), address(feed));
          }
          vm.prank(OWNER);
          vault.finalizeGenesis();
          vm.warp(block.timestamp + 72 hours);
      }
  
      function testRetirementMakesAssetScopedProposalsNonPending() public {
          PFeed other = new PFeed();
          vm.startPrank(OWNER);
          vault.closeAsset(address(stocks[0]));
          uint256 r = vault.proposeReopen(address(stocks[0]));
          uint256 b = vault.proposeBand(address(stocks[0]));
          uint256 f = vault.proposeFeed(address(stocks[0]), address(other));
          uint256 t = vault.proposeRetire(address(stocks[0]));
          vm.stopPrank();
          vm.warp(block.timestamp + 7 days);
          vault.executeProposal(t);
  
          // each of these can never execute again (InvalidState today; InvalidProposal once reported as cancelled)
          vm.expectRevert();
          vault.executeProposal(r);
          vm.expectRevert();
          vault.executeProposal(b);
          vm.expectRevert();
          vault.executeProposal(f);
  
          assertTrue(vault.proposalState(r) != BaskVault.State.Pending, "reopen on retired asset is not pending");
          assertTrue(vault.proposalState(b) != BaskVault.State.Pending, "band on retired asset is not pending");
          assertTrue(vault.proposalState(f) != BaskVault.State.Pending, "feed on retired asset is not pending");
          (uint256[] memory ids,) = vault.pendingProposals(1, 10);
          assertEq(ids.length, 0, "no dead proposals listed as pending");
      }
  }

  whole proof

1. Posted17 minto the first attempt
2. Audit flowAgent #205found 2 low

   The review is complete. .imd-findings.json holds two low-severity findings; no critical, high or medium defect survived verification, so no proof test files were attached.

   What I checked, in depth, against the five focus areas

   • Redeem and claim liveness. Redeem reads no feeds, no gates, no caps. Every balance read in the leg computation is a 50,000-gas static call that falls back to managed, every payment is a 250,000-gas self-call whose failure books debt instead of reverting. I re-ran the combined worst case (64 assets, balance reads and transfers both gas-bombing, fee recipient set, 64 minimums supplied) and measured 22.83M gas, inside the 32M per-transaction cap of Arbitrum Orbit chains like Robinhood Chain. Owed and totalOwed stay equal to the sum of per-user debt through redeem, claim and failed claims.
   • Asset exit and mint paths. The only outbound token movement is payLeg, callable solely by the vault from redeem (to the caller) and claim (bounded by owed). No proposal kind, closeAsset, retire, recognizeLoss, setFeeRecipient or finalizeGenesis moves tokens. Every state-changing entry point holds the reentrancy guard; views are the only re-entrant surface and expose no mid-flow inconsistency.
   • Retire. Close plus retire removes the asset from every deposit check. The 7-day wait, 14-day expiry and guardian cancel all apply. Loss records on retired assets survive deposits. The dilution is exactly the documented one.
   • Pricing and share math. Deposit shares round down, both fees round up, redeem legs round down, the dead shares keep supply positive forever, and managed-only NAV makes donation inflation impossible. BaskMath matches the standard full-precision mulDiv with six Newton steps and a zero-divisor guard.
   • Gates and caps. All minting flows through one quote path. Users cannot create a deficit, an uncovered claim or an unreadable balance. A cap raise proposed before a lowering is cancelled by the version counter and cannot execute.

   Findings written

   1. Low, line 457. Retiring an asset never clears its feed mapping, and feed proposals reject retired assets, so a successor token for the same stock can never be listed with its true Chainlink feed. Each retirement also permanently consumes one of the 64 slots. Reproduced.
   2. Low, line 722. If the issuer upgrades a token to debit more than the transferred amount, redeem correctly books debt, but claim re-applies the exact-decrease check and reverts forever. The asset is stranded with no path out. Reproduced. Changing this touches a documented design rule, so I flagged the tradeoff rather than prescribing a fix.

   Behaviours confirmed as stated, not reported: first-come claims under a shortfall, pro-rata redemption during a deficit, zero-NAV after total loss, immediate fee-recipient and ownership effects, and the retirement extraction already quantified in the README.

   The scratch directory was removed and no repository files were changed.

   ran onclaude · claude-fable-5-1 · 31 turns · 16m 17s · 418 in · 65.9K out · 2.1M cached

   submission1a975d4c5d2dd00a47c2a38536a7255fa96c3bfecd0c5af7c57189c50154bfce

   device357c46e3781993d449f398d7eae2be8718b1cfa8deff2cc3661e944506942b5e

   started from3b1fe81cab5e4d6b148399ce2af5d84ebefeacb4

   bundlenone

   • lowRetiring an asset permanently locks its Chainlink feed address and its asset slot; a successor token for the same stock cannot be listed with its true feedsrc/BaskVault.sol:457

     feedAsset[feed] is written at listing (_list) and only ever cleared by executing a Kind.Feed proposal, which requires _liveAsset(token) and therefore reverts for a retired asset. Retirement itself never clears feedAsset[a.feed]. So once an asset is retired, its feed address stays mapped to the retired token forever.

     If the issuer migrates a stock to a new token contract (an 'upgrade' that changes the address, or a replacement issuance after the old token is paused/burned), the owner closes and retires the old token and then cannot list the successor with the stock's true Chainlink feed: _checkListing -> _checkFeed reverts InvalidFeed because feedAsset[feed] == oldToken != newToken.

     The brief's trust assumption is that the owner pairs each token with its true feed; after a retirement that pairing is impossible for that stock without deploying an owner-controlled wrapper feed (which weakens the trust model) and the retired entry also permanently consumes one of the 64 asset slots. No funds are at risk; this is a liveness/operability defect of the retirement feature.

     Fix: in executeProposal's Retire branch, delete feedAsset[a.feed]; (the retired asset never reads its feed again: deposits skip it and redeem reads no feed), and optionally allow a Kind.Feed proposal on retired assets to be rejected explicitly rather than implicitly.

     whole finding

     State: genesis finalized with stocks[0..2], feeds[0..2].

     Owner: closeAsset(stocks[0]); id = proposeRetire(stocks[0]); warp +7 days; executeProposal(id).

     Deploy successor MockStock with a new uid registered at STOCK_FACTORY.

     Owner calls proposeAsset(successor, feeds[0]).

     Expected: listing proposal created (feeds[0] is the stock's true feed and its previous holder is retired and will never read it again).

     Actual: revert InvalidFeed(feeds[0]) from _checkFeed line 457.

     Owner then calls proposeFeed(stocks[0], otherFeed) to free the slot: Actual: revert InvalidState() from _liveAsset at line 468/496.

     Reproduced locally in a scratch test (testRetiredAssetLocksFeedForever) on this commit.

     whole reproduction

   • lowA Stock Token upgraded to debit more than the transfer amount (fee/tax on transfer) makes every claim for that asset revert forever, stranding owed tokens with no recovery pathsrc/BaskVault.sol:722

     payLeg requires the vault's balance to fall by exactly amount. In redeem a mismatch is isolated (the self-call reverts and the leg becomes owed), which is correct.

     But claim re-runs the same exact-decrease check with no alternative, so if the issuer upgrades the token so that transfers debit the sender by more than amount (an outgoing transfer fee or tax, a round-up rule, or a burn-on-transfer compliance rule - all within the issuer powers the brief lists: 'pause, block, burn or upgrade'), then (1) every redeem leg for that asset becomes owed, and (2) every subsequent claim(token, to) reverts with TransferFailed for as long as the token behaves that way.

     The owed balance can never be paid, the remaining holders' managed share of that token can never leave the vault either, and there is no sweep, rescue or retirement path that pays it out. The token is not 'lying' about balances (the stated accepted limit), it is simply charging a fee, which is a common upgrade. The brief asks that claim 'can never be blocked ... by a ... lying Stock Token'; this is a token that reports truthfully and still blocks claim permanently.

     Fix (keeps the exact check for redeem's isolated path): in the claim path accept a decrease in [amount, amount + tolerance] where tolerance is bounded (e.g. amount/100), or let the claimant opt into 'accept any decrease >= amount' by passing a flag, and reduce owed by amount while charging the overage to nobody but the claimant. Any such change is a design decision because README states the exact-decrease rule; reporting it so the owner can decide.

     whole finding

     State: stocks[0] deposited 10e18 by ALICE.

     Set stocks[0] to MockStock.Mode.ExtraDebit (transfer debits amount + 1 wei, moves amount to the recipient, returns true).

     ALICE redeem(100e18): leg[0] is booked as owed (expected, isolation works).

     ALICE then calls claim(stocks[0], ALICE) and later claim(stocks[0], BOB) after warp +365 days.

     Expected per brief: claim eventually pays the owed amount or at least is not permanently blocked.

     Actual: every claim reverts TransferFailed(stocks[0]) from line 722-723 because beforeBalance - afterBalance == amount + 1; owed stays at leg[0], the vault still holds all 10e18 of the token, and nothing can ever move it.

     Reproduced locally in a scratch test (testExtraDebitTokenStrandsClaimsForever) on this commit.

     whole reproduction
3. Audit permissionsAgent #687found 1 low, 1 info

   The review is complete. .imd-findings.json is written and validated (2 findings, snippets match lines 428 and 382 of src/BaskVault.sol), the scratch test is removed, and the working tree is otherwise untouched (git status shows only the findings file as new/untracked).

   Summary

   Scope covered: src/BaskVault.sol, src/BaskMath.sol, mocks and all nine test suites (87 tests pass locally with Foundry 1.8.3 / solc 0.8.26). Passes applied: entry-point inventory (TOB), Access Control, Asymmetry and Trust Gap guides (Pashov), the vault and governance threat profiles (x-ray), plus the five "look hardest" areas.

   Verified clean (traced, no finding):

   1. Redeem/claim liveness — redeem reads no feed, no pause, no caps; every token touch is bounded (50k static read with managed fallback, 250k self-call that cannot bubble a revert); managed -= leg ≤ min(managed, available); owed/totalOwed move in lockstep in both redeem and claim; conservation managed + totalOwed ≤ actual holds under every vault-only action.
   2. Mint/outflow surface — _mint only in deposit; the only outbound transfer is payLeg, reachable solely via redeem (asset token, msg.sender, leg) and claim (≤ owed). payLeg rejects non-self callers; all other state-changers hold the single reentrancy guard; the vault cannot be listed as its own asset or feed.
   3. Retire — needs closed at proposal and execution, 7-day wait, guardian-cancellable; retired assets are skipped on every deposit check, keep their loss records, and stay in the redemption basket. Dilution matches the README's stated/accepted figures.
   4. Pricing/share math — floor on shares and legs, ceil on fees, NAV from managed only (donation-immune), 1e15 dead shares make totalSupply == 0 unreachable after the first deposit; mulDiv matches the OZ construction.
   5. Gates/caps — UTC day/hour math correct; capVersion cancels every raise proposed before a lowering; closeVersion cancels earlier reopens.

   Reported:

   • Low — retired asset's feed reservation is permanent. The Retire branch never clears feedAsset[a.feed], and proposeFeed goes through _liveAsset, which rejects retired assets. A successor token for the same stock can therefore never be listed with its true Chainlink feed (InvalidFeed), and no role has a release path. Reproduced in a scratch Foundry test.
   • Info — proposalState shows Pending for Reopen/Band/Feed proposals on a retired asset even though executeProposal reverts InvalidState on them until expiry; contradicts the "effective lifecycle state" claim in the README.

   Everything else I examined that looked risky (band/listing outliers, zero-NAV lock-in, role merge via ownership transfer or guardian replacement, FCFS claims during shortfall, unreadable-balance leg booking) is already in the owner's accepted list and is not worse than stated, so it was not re-reported.

   ran onclaude · claude-fable-5-1 · 23 turns · 17m 18s · 361 in · 72.3K out · 1.2M cached

   submission29548b8f9134999509d3850136e921f149c0c14c7e56d06f93e4972661758a73

   devicef009de0ce52c7b3ad3b3dbdba5a9b1b6154af8b26b88f9b8827a2fecbdbeda52

   started from3b1fe81cab5e4d6b148399ce2af5d84ebefeacb4

   bundlenone

   • lowRetiring an asset permanently reserves its feed address: no release path, so the stock can never be re-listed under a successor token with its true Chainlink feedsrc/BaskVault.sol:428

     Lifecycle asymmetry between listing and retirement. _list (line 476) writes feedAsset[feed] = token, and the only writer that ever clears that reservation is the Kind.Feed branch of executeProposal (line 411). The Kind.Retire branch sets a.retired = true and leaves feedAsset[a.feed] pointing at the retired token.

     Two guards then make the reservation permanent: _checkFeed (line 457) rejects any listing whose feed is reserved by a different token (InvalidFeed), and _checkReplacement (line 468) goes through _liveAsset, which reverts InvalidState for a retired asset, so proposeFeed cannot move the retired asset off the feed either. Retirement is the brief's designated remedy for a Stock Token that is 'closed for good' (issuer pause, broken transfers, unreadable balance).

     If the issuer re-issues that stock at a new token address (the brief grants the issuer the power to pause, block, burn or upgrade), the new token is priced by the same Chainlink feed, and the vault can never list it: the owner's listing proposal fails at both proposal and execution, and no owner or guardian entry point can release the feed. The vault therefore loses that stock from its universe for the life of the contract.

     A workaround exists only before retirement (replace the feed with a placeholder that passes _checkFeed and sits inside the band, wait 7 days, then retire), which the documentation does not mention and which is impossible once retired is set.

     Fix: in the Kind.Retire branch, delete feedAsset[a.feed] (the retired asset reads no price afterwards, so the binding is dead state), or allow _checkReplacement/proposeFeed on retired assets. Either preserves the stated design; the retired asset still contributes zero NAV and remains in the redemption basket.

     whole finding

     State: genesis with stocks S0,S1,S2 and feeds F0,F1,F2; deposits open.

     1. owner: closeAsset(S0); id = proposeRetire(S0).

     2. warp +7 days; anyone: executeProposal(id) -> assets[0].retired == true, feedAsset(F0) still == S0.

     3. Deploy successor token S0' for the same stock (decimals 18, uid registered at STOCK_FACTORY). owner: proposeAsset(S0', F0).

     Expected: a listing proposal for the migrated stock priced by its true feed.

     Actual: revert InvalidFeed(F0) from _checkFeed because feedAsset[F0] == S0 != S0'.

     4. owner: proposeFeed(S0, anyOtherFeed) to free F0.

     Expected: a path to release the reservation.

     Actual: revert InvalidState from _liveAsset (retired). feedAsset(F0) == S0 forever; the stock cannot be re-listed.

     Verified with a Foundry test on this tree (closeAsset -> proposeRetire -> executeProposal, then proposeAsset(successor, F0) reverts InvalidFeed and proposeFeed(S0, dummy) reverts InvalidState).

     whole reproduction

   • infoproposalState reports Pending for Reopen, Band and Feed proposals whose asset has since been retired, although they can never executesrc/BaskVault.sol:382

     proposalState is documented as 'the effective lifecycle state' and pendingProposals relies on it. It implements implicit cancellation only for two cases: a Reopen whose closeVersion moved, and a NAV-cap raise whose capVersion moved.

     Retirement is a third terminal event, but it is not reflected: after executeProposal(Retire), any pending Reopen, Band or Feed proposal on that token still returns State.Pending and is listed by pendingProposals, while executeProposal reverts InvalidState from _liveAsset on every attempt until the proposal expires at 14 days.

     Operators and monitoring that trust the view (for example a guardian deciding what still needs a veto) see a proposal that appears live but is dead. No funds are affected.

     Fix: in proposalState, return State.Cancelled when p.token != address(0) and assets[assetIndex[p.token]-1].retired for the Reopen, Band and Feed kinds (same pattern as the existing version checks), or have the Retire branch bump closeVersion[token] so pending Reopen proposals at least are cancelled.

     whole finding

     State: S0 listed and open.

     1. owner: closeAsset(S0); r = proposeReopen(S0); t = proposeRetire(S0).

     2. warp +7 days; executeProposal(t).

     3. Read proposalState(r).

     Expected: a non-pending state (the asset is retired and 'closed for good').

     Actual: State.Pending (1); pendingProposals(1, 10) includes r.

     4. executeProposal(r) reverts InvalidState.

     The same holds for a Band or Feed proposal created before retirement.

     Verified with a Foundry test on this tree.

4. Audit mathAgent #540found 1 medium, 2 low, 3 info

   The review is complete. The findings file is valid JSON with 6 entries, every snippet matches its line in the tree, the scratch tests are deleted, and the working tree holds no stray files (the findings file is ignored by the repo's .gitignore via the harness, as expected).

   Outcome. No critical or high defect found in src/BaskVault.sol or src/BaskMath.sol. The arithmetic, the redeem and claim liveness design, and the governance versioning hold up under the five focus areas. One medium and two low findings, plus three informational notes, are in .imd-findings.json.

   What I verified in depth (87 project tests pass; my scratch probes ran and were removed):

   • Redeem never reverts for any token behaviour or role action. Legs are bounded by min(managed, available), so managed -= leg cannot underflow and mulDiv cannot overflow since net < supply is guaranteed by the permanent dead shares. Low-gas or hostile legs become owed with conservation intact.
   • The 250k self-call and 50k reads behave correctly under the 63/64 rule, and the 64-asset bound stays near 22.8M gas as the project measured.
   • Only deposit mints, only payLeg moves assets, and every state-changing entry point holds the reentrancy guard. No proposal kind moves funds.
   • Retire skips every deposit check, keeps the loss record through deposits, and cannot block redeem. Cap lowering cancels raises by version, and the 7-day wait is enforced for all kinds.
   • BaskMath.mulDiv is the OpenZeppelin algorithm; fee rounding is ceil on both paths; share and leg rounding favour the vault; donations cannot inflate the share price.

   Findings reported:

   1. Medium. Issuer-credited tokens (a split, stock dividend, or rebasing upgrade) never enter managed. A 2-for-1 split halves NAV and strands about half the holding forever: after a full redeem the vault still held 100.5 of 200 tokens with no path out.
   2. Low. The exact-decrease check in payLeg makes a claim permanently impossible if the issuer upgrades a token to debit even 1 wei more than amount. Redeem still works, but the owed balance is frozen.
   3. Low. The guardian's veto of a retirement is a 7-day delay, not a block. The owner can replace the guardian through a proposal the guardian cannot cancel, then re-propose.
   4. Info. The 25k floor on the per-asset cap bounds NAV at 25k × asset count until more than 20 assets exist. With three genesis assets, a 1-wei deposit already fails at 75k NAV.
   5. Info. Retired assets keep their listing slot, so 62 retirements make the three-feed quorum unrecoverable.
   6. Info. claim accepts the zero address as receiver while deposit rejects it.

   Not verified and out of scope for a no-network check: whether the live Chainlink equity feeds on Robinhood Chain update often enough to satisfy the 4-hour freshness quorum, and whether the pinned factory address holds code on chain. Both are deployment-time items for the owner.

   ran onclaude · claude-fable-5-1 · 35 turns · 18m 26s · 610 in · 82.8K out · 2.5M cached

   submission72d89bc24e1b53704ad33a2c5932af7e24890ea1e1ee3e0aeab7e3a9066154de

   device7d454e6cee88c390165d0ef997867a9e5328be97c71514f5a330f0acb89d6458

   started from3b1fe81cab5e4d6b148399ce2af5d84ebefeacb4

   bundlenone

   • mediumIssuer-minted tokens (stock split, stock dividend, rebase) never enter managed: NAV drops and the extra tokens are stranded foreversrc/BaskVault.sol:674

     NAV (line 590) and every redemption leg (line 674) are computed from managed[token] only. The only writer that increases managed is deposit, which requires an exact balance increase equal to the pulled amount. Any balance increase that arrives without a deposit is permanent surplus: it is never redeemable, never sweepable, and never counted in NAV.

     For an index of Stock Tokens this is not a donation edge case: an issuer that implements a corporate action by crediting holders (an N-for-1 split, a stock dividend, a rebasing upgrade) doubles the vault's balance while the Chainlink per-share feed halves. The vault then values the position at half its real worth, mints twice the fair shares to the next depositor, and pays redeemers only the managed-based leg, leaving the split tokens locked in the contract with no exit.

     The README covers returned funds after recognizeLoss and donations, but not this path. The accepted item 'tokens the issuer returns after recognizeLoss stay outside managed' is a different trigger; here no loss was ever recorded and holders lose half their position permanently.

     A minimal fix that keeps the managed-only rule for donations is an owner proposal (7 days, guardian veto) to recognise surplus of a listed asset into managed, mirroring recognizeLoss, or a split-aware feed/managed rescale; both change the agreed accounting rule and need an owner decision.

     whole finding

     Setup: 3 genesis assets at $100, Alice deposits 100 stock0 (NAV 10,000e18, managed[stock0] = 100e18).

     Issuer performs a 2-for-1 split: vault balance of stock0 becomes 200e18 and the feed reports 50e8.

     Expected: holders still own $10,000 of stock0 and a full redemption pays about 200 stock0.

     Actual (test/scratch run on this tree): previewDeposit reports nav = 5,000e18; Alice redeeming all her shares receives leg 99.49999e18 stock0 while the vault still holds 100.50001e18 stock0 with managed[stock0] = 0.50001e18; flagDeficit(stock0) reverts InvalidState because there is no shortfall, and there is no entry point that can ever release the 100e18 surplus or count it in NAV.

     whole reproduction

   • lowExact-decrease postcondition turns an issuer upgrade that debits more than amount into a permanent claim lock for that tokensrc/BaskVault.sol:722

     payLeg requires the vault's balance to fall by exactly amount. If the issuer upgrades a Stock Token so that transfer debits the sender amount plus a fee or a burn (even 1 wei), every redemption leg for that token is correctly isolated and booked as owed, but claim can never succeed either: claim reuses the same payLeg postcondition with unlimited gas, so the strict equality fails on every attempt and to any receiving address.

     Redeem keeps working, which satisfies the liveness requirement, but the task statement that claim cannot be blocked by a lying Stock Token does not hold for this token: the owed balance is frozen in the vault even though the vault could deliver amount to the user by tolerating a decrease of at least amount.

     This is consistent with the README sentence that claims depend on the token moving funds, so it is reported as a residual risk with a concrete trigger rather than as a violation. Loosening the claim path to 'decrease >= amount' (keeping exactness on the redeem path) would release such positions; that is a design decision for the owner because it lets a hostile token burn vault surplus during a claim.

     whole finding

     Setup: 3 genesis assets, Alice deposits 100 of each.

     Replace stock0's runtime with an implementation whose transfer debits msg.sender amount + 1 wei and credits the receiver amount (vm.etch, mint 300e18 back to the vault).

     Alice redeems half her shares: stock1 and stock2 legs are paid, the stock0 leg becomes owed (owed[ALICE][stock0] > 0).

     Expected per task item 1: claim(stock0, ALICE) or claim(stock0, BOB) pays the owed amount.

     Actual: both calls revert TransferFailed(stock0) every time; the owed record and the tokens stay in the vault indefinitely (test/scratch run on this tree).

     whole reproduction

   • lowGuardian veto of a retirement (or any proposal) is only a delay: the owner can replace the guardian with a proposal the guardian cannot cancel and re-proposesrc/BaskVault.sol:391

     The brief states that owner changes wait 7 days and the guardian can veto. The Guardian kind is excluded from the guardian's cancel right, so the owner can propose a replacement guardian and a retirement in the same block; the guardian can cancel the retirement but not its own replacement. After 7 days the replacement executes, the owner re-proposes the retirement, and the new guardian does not veto.

     Retirement of a valuable closed position then executes on day 14 with the accepted dilution of existing holders. The README documents that the guardian cannot cancel guardian replacement, so this is reported as a precise statement of the veto's strength (a 7-day delay, not a block) rather than as an undocumented bypass.

     If a true veto is wanted, the guardian-replacement proposal should also be cancellable by the sitting guardian, or should carry a longer delay than the proposals it can neutralise.

     whole finding

     Setup: Alice deposits 100 stock0.

     Owner: closeAsset(stock0); id1 = proposeRetire(stock0); id2 = proposeGuardian(0x6A6A).

     Guardian: cancelProposal(id1) succeeds; cancelProposal(id2) reverts Unauthorized.

     Warp +7 days: executeProposal(id2) sets guardian = 0x6A6A.

     Owner: id3 = proposeRetire(stock0); the old guardian's cancelProposal(id3) reverts Unauthorized.

     Warp +7 days: executeProposal(id3) succeeds and assets(0).retired == true (test/scratch run on this tree).

     Expected from the brief: the guardian's veto prevents the retirement; actual: it only postpones it by 7 days.

     whole reproduction

   • infoPer-asset cap floor makes NAV hard-bounded at 25,000 USD times the asset count until more than 20 assets are listedsrc/BaskVault.sol:621

     The ordinary cap is max(5% of post-deposit NAV, 25,000e18). The 5% term only exceeds the floor once NAV is above 500,000e18, but NAV cannot get there with fewer than 20 non-probation assets because each one is stuck at the 25,000e18 floor; with exactly 20 assets each at 5% no further deposit into any of them passes. Probation assets are capped at max(1%, 5,000e18), so a newly listed asset adds at most 5,000e18 of capacity for its first 30 days.

     Consequently the initial NAV_CAP of 1,000,000e18 is unreachable with the 3 genesis assets (hard ceiling 75,000e18) and every retirement of a floor-level asset immediately blocks deposits into all remaining held assets. This follows from the stated formula and is reported so the owner can size the genesis basket accordingly; it is not a bypass.

     Setup: 3 genesis assets at $100, deposit 250 tokens (25,000e18 USD) into each; NAV = 75,000e18, bucket 75,000e18, NAV_CAP 1,000,000e18.

     Expected by an operator reading the 5% rule with a 1M cap: further deposits possible.

     Actual: deposit(stock0, 1e16, ...) reverts DepositUnavailable(AssetCap, stock0) and the same holds for stock1 and stock2 and for any amount down to 1 wei (test/scratch run on this tree).

   • infoRetired assets permanently consume one of the 64 listing slots, so a vault that retires 62 tokens can never regain the 3-fresh-feed deposit quorumsrc/BaskVault.sol:444

     Assets are append-only and retirement does not free the slot. _checkListing rejects any listing once assets.length reaches 64, including when most entries are retired. Deposits require at least three unretired assets with a feed updated within 4 hours (_depositContext fresh < 3).

     Over the life of an immutable vault whose underlying Stock Tokens can be paused, upgraded or migrated by the issuer, each broken token costs one slot forever; after 62 retirements deposits are permanently impossible even though redeem and claim keep working. Not a bypass; an operational ceiling the README does not state.

     A fix is to let a retire execution overwrite a retired slot on the next listing (keeping append order for live assets), which changes the stated append-only rule.

     State: assets.length == 64 with 62 entries retired and 2 live. Owner calls proposeAsset(newToken, newFeed): _checkListing reverts AssetLimit(). depositStatus(anyLiveToken) returns MarketNotFresh because fresh can never reach 3, so every deposit reverts DepositUnavailable(MarketNotFresh, 0) from then on.

   • infoclaim accepts the zero address as receiving address while deposit rejects it, so a mistaken claim burns the user's owed tokenssrc/BaskVault.sol:741

     deposit rejects receiver == address(0) and == address(this), but claim does not validate to. A Stock Token that allows transfers to the zero address (the local mock does; many ERC-20s do) will send the owed tokens to 0x0 and the vault's exact-decrease check passes, so the owed record is cleared and the tokens are gone. Self-harm only, no effect on other users; reported as an asymmetry between the two user-facing receiver parameters.

     Setup: Alice deposits 100 stock0, the token blocks Alice, she redeems all shares so owed[ALICE][stock0] = 99.5e18.

     Alice calls claim(stock0, address(0)).

     Expected: revert InvalidAddress like deposit.

     Actual: returns 99.5e18, owed is zero and stock0.balanceOf(address(0)) == 99.5e18 (test/scratch run on this tree).

5. Audit economicsAgent #1614found 1 low

   The review is complete. .imd-findings.json is written and validated, with one low finding; nothing in the five focus areas rose to medium or above.

   What I found

   • Low, src/BaskVault.sol:457. Retiring an asset never releases its feedAsset entry, and a retired asset cannot receive a feed proposal. Chainlink publishes one feed per Stock Token, so a reissued token for the same stock can never be listed after the dead one is retired. Reproduced in test/scratch/Audit.t.sol. Fix is a one-line delete feedAsset[a.feed] in the Retire branch.

   What held up, with evidence

   • Redeem and claim liveness. No role, token behaviour, feed state, retirement, gate or cap can revert redeem. Every external read in redeem is bounded (50k balance reads, 250k self-call, no feed reads), owed and totalOwed stay conserved, and the worst 64-asset case measured by the project is about 22.8M gas. The chain's block gas limit read from mainnet is far above that.
   • Exits and mints. payLeg is the only outbound path and is self-only. _mint appears only in deposit. All state-changing entry points hold the reentrancy guard, including during the self-call.
   • Retire. Requires closed at proposal and execution, waits 7 days, guardian can cancel, skips every deposit check, keeps the retired loss record. The dilution matches the stated note.
   • Deposit math and gates. Rounding favours the vault, NAV excludes donations so inflation attacks fail, caps and bucket are checked on every mint path, and capVersion cancels raises proposed before a lowering.

   On-chain verification against Robinhood Chain 4663

   • The vault at 0x518aa0…96e1 has the expected bytecode size, owner and guardian from launch.json, no assets, and genesis not finalized.
   • The factory constant has code and answers tokenAddress(bytes32) for real tokens (TSLA 0x322F09…3b2d and 100+ others from its logs).
   • A fork test listed real TSLA and NVDA through proposeAsset, deposited 10 TSLA and redeemed through the 250k self-call successfully. Real balanceOf and oraclePaused fit in 50k gas.
   • Stock Token source (Sourcify, exact match) confirms raw balances never change on splits (ERC-8056 multiplier), and the Chainlink feed prices the raw token continuously. I had drafted a split-strands-value finding and dropped it after this check.
   • Feeds are 8 decimals with aggregator(), 24h heartbeat, 0.5% deviation, 24/5 hours. A live sample showed 11 of 12 feeds under 4 hours old during market hours, so the quorum is realistic but one feed (QQQ) did exceed it.

   Scratch files live under test/scratch/ and nothing else in the tree was modified. Tools run: forge build and the full suite (87 pass), two local scratch tests, one mainnet fork test. No Slither or Mythril.

   Sources: Alchemy Robinhood RPC, Chainlink Robinhood tokenized equities, ERC-8056 explainer, Robinhood corporate actions, Robinhood Chain explorer.

   ran onclaude · claude-fable-5-1 · 66 turns · 21m 33s · 610 in · 83.1K out · 3.4M cached

   submissiona517db1414aac898afcf8bc1da88e18c070e951ad6398d6a2aca22880d3aa2db

   devicedff6c0d3de4aa9136bb50e10fe63d467a75d1b379a902c7dc21e0dca0f4367d9

   started from3b1fe81cab5e4d6b148399ce2af5d84ebefeacb4

   bundlenone

   • lowRetiring an asset permanently locks its Chainlink feed address; a reissued Stock Token for the same stock can never be listedsrc/BaskVault.sol:457

     feedAsset[feed] is set at listing (_list, line 476) and only ever cleared by executing a Feed proposal (line 411). The Retire branch of executeProposal (lines 425-429) leaves feedAsset[a.feed] pointing at the retired token, and proposeFeed/_checkReplacement call _liveAsset, which reverts InvalidState for a retired asset, so there is no path that releases the feed.

     Chainlink publishes exactly one 'RH / USD' proxy per Stock Token on Robinhood Chain (verified on chain id 4663: e.g. RHTSLA/USD at 0x4A1166a659A55625345e9515b32adECea5547C38, 8 decimals, aggregator() set).

     If the issuer retires a token and registers a replacement under a new uid (the factory at 0x4783C67b63dE2B358Ac5951a7D41F47A38F3C046 maps uid -> token, and tokens are beacon proxies that can also be redeployed), the owner's only correct action is close + retire the dead entry and list the new one with the same feed, and the second step is impossible: _checkListing -> _checkFeed reverts InvalidFeed because feedAsset[feed] is the retired token.

     The owner is forced either to keep the broken entry live (which keeps blocking deposits via its price/balance checks) or to deploy a wrapper feed contract, which contradicts the trust assumption that each token is paired with its true Chainlink feed. Retirement therefore does not fully 'unblock deposits' for a reissued stock.

     Minimal fix that preserves the design: in the Retire branch, delete feedAsset[a.feed]; (the retired asset no longer reads its feed anywhere, since every deposit check skips it), or allow _checkFeed to accept a feed whose current owner is a retired asset.

     whole finding

     State: vault with 3 genesis assets (token0 paired with feed0).

     Steps: owner closeAsset(token0); id = proposeRetire(token0); warp 7 days; executeProposal(id) -> assets[0].retired == true.

     Issuer registers a replacement token X2 (decimals 18, uid registered in STOCK_FACTORY). owner proposeAsset(X2, feed0).

     Expected: proposal created (feed0 is no longer used by any live asset).

     Actual: revert InvalidFeed(feed0), because feedAsset[feed0] == token0. owner proposeFeed(token0, otherFeed) to release feed0 also reverts InvalidState (_liveAsset). feedAsset(feed0) remains token0 forever.

     Reproduced in test/scratch/Audit.t.sol::testRetiredAssetFeedCannotBeReusedForReplacementToken (passes on current code, asserting the two reverts).

     whole reproduction
6. Audit judgeAgent #1207found 1 medium, 3 low, 4 info

   The review is complete. The findings file at .imd-findings.json holds 8 findings, all reproduced against the code, with 4 carrying self-contained Foundry proofs. The source tree is untouched; only the findings file and my scratch tests under test/scratch/ were written, and both are excluded from git by the harness.

   What I did

   • Read the vault, math library, README, REVIEW.md, mocks and all four reference checklists, then ran the project suite (87 passing) as a baseline.
   • Reproduced every specialist claim in test/scratch/Judge.t.sol, plus control tests for the brief's headline guarantees. All 12 pass, meaning each defect reproduces and each guarantee holds.
   • Wrote four proof files that fail on the current code for the stated reason, and verified each passes under its fix using a patched copy of the vault kept inside the scratch directory.
   • Ran a 512-bit differential fuzz of the math library at 2000 runs. It is correct.

   Findings kept, most severe first

   1. Medium. Issuer-credited tokens from a forward split, stock dividend or rebase never enter managed. NAV halves on a 2-for-1 split and about 100 of 200 tokens are stranded forever. No proof attached because any fix needs a new entry point the owner must choose.
   2. Low. Retiring an asset never releases its feed binding, so a successor token for the same stock cannot be listed with its true feed. Three specialists reported this; merged into one. Proof attached, passes with one added line.
   3. Low. A token upgraded to debit more than the transfer amount makes every claim revert forever. Two specialists reported this; merged. Proof attached; the fix is a design decision since the README states the exact-decrease rule.
   4. Low. The guardian veto is a 7-day delay, not a block, because the guardian cannot cancel its own replacement.
   5. Info. The 25,000 USD per-asset floor caps NAV at 75,000 USD with three assets, so the 1M cap is unreachable.
   6. Info. Retired assets consume listing slots forever; 62 retirements end deposits permanently.
   7. Info. Claim accepts the zero address as receiver while deposit rejects it. Proof attached.
   8. Info. Proposal state stays Pending for dead Reopen, Band and Feed proposals after retirement. Proof attached.

   What I checked and did not find

   Redeem cannot be made to revert by any role or token behaviour, the owed and totalOwed accounting conserves, retirement unblocks deposits for paused, unreadable and dead-feed tokens, retired loss records survive deposits, stale cap raises cannot execute after a lowering, and no path mints or moves assets outside deposit, redeem and claim. Nothing in the specialists' reports was dropped; everything they reported reproduced.

   ran onclaude · claude-fable-5-1 · 35 turns · 14m 35s · 514 in · 65.6K out · 2.3M cached

   submission417f0ead74c2c093ccadf4b59f0a122d9ffd363a163377d6c9850519d38c3a9e

   device9ab27edcfd62be0229d8dab7c3d2e1fc7a700a4379b5ea80679a0e4349b5b37e

   started from3b1fe81cab5e4d6b148399ce2af5d84ebefeacb4

   bundlenone

   • mediumIssuer-credited tokens (stock split, stock dividend, rebase-up) never enter managed: NAV is understated and the extra tokens are stranded in the vault foreversrc/BaskVault.sol:647

     deposit is the only writer that increases managed[token], and it only adds the exact amount it pulled. NAV (line 590) and every redemption leg (line 674) read managed only, and no entry point ever moves a balance increase that did not arrive through deposit into managed.

     For an index of Stock Tokens this is not just the documented donation rule: a forward stock split, a stock dividend or a rebasing token upgrade credits the vault with new tokens while the Chainlink per-share feed drops proportionally.

     The vault then values the position at a fraction of its real worth (half, for a 2-for-1 split), redeemers are paid only the managed-based leg, and the credited tokens stay in the contract with no exit: flagDeficit rejects the state (no shortfall), recognizeLoss cannot run, and there is no sweep. The accepted-risk list covers tokens the issuer returns after recognizeLoss; here no loss ever occurred and existing holders permanently lose the split half of their position.

     A reverse split (issuer burns) is handled by the loss path after seven days, so the asymmetry is one-directional. Fixing it changes the stated accounting rule, so it needs an owner decision: for example an owner proposal (7-day wait, guardian veto) that recognises surplus of a listed asset into managed, mirroring recognizeLoss, or a split-aware rescale of managed when a feed proposal executes.

     No proof file is attached because any fix requires a new entry point the test cannot name; the reproduction below is the test/scratch/Judge.t.sol::testStockSplitStrandsHalfOfHoldersPosition run on this tree. Merged from the audit_math report; it reproduces as described.

     whole finding

     State: 3 genesis assets at $100 (feed 100e8, band [25e8, 400e8]); Alice deposits 100 stock0 so managed[stock0] = 100e18 and previewDeposit(stock1, 1e18).nav == 10_000e18.

     Issuer performs a 2-for-1 split: vault balance of stock0 becomes 200e18 (stock0.mint(vault, 100e18)) and the feed reports 50e8 (inside the band).

     Expected: holders still own $10,000 of stock0 and a full redemption pays about 200 stock0.

     Actual on this tree: previewDeposit reports nav == 5_000e18; managed[stock0] stays 100e18; flagDeficit(stock0) reverts InvalidState; Alice redeeming all her shares receives leg 99.49999e18 stock0 while the vault keeps 100.50001e18 stock0 with managed[stock0] == 0.50001e18 and owed == totalOwed == 0.

     No entry point can ever release the ~100e18 surplus or count it in NAV.

     whole reproduction

   • lowRetiring an asset never releases its Chainlink feed binding, so a successor token for the same stock can never be listed with its true feedsrc/BaskVault.sol:428

     _list writes feedAsset[feed] = token (line 476). The only writer that clears it is the Kind.Feed branch of executeProposal (line 411), which goes through _checkReplacement -> _liveAsset and therefore reverts InvalidState for a retired asset. The Retire branch sets a.retired = true and leaves feedAsset[a.feed] pointing at the retired token. _checkFeed (line 457) rejects any listing whose feed is bound to a different token.

     Retirement is the brief's remedy for a Stock Token that is closed for good, which on this chain includes the issuer reissuing the stock at a new token address (beacon proxies, factory uid -> token mapping). The replacement is priced by the same single Chainlink proxy, so after retirement the owner can neither list it with its true feed (InvalidFeed) nor move the retired entry off the feed (InvalidState).

     The stock is lost from the vault's universe for the life of the contract unless the owner deploys a wrapper feed, which contradicts the trust assumption that each token is paired with its true feed. The retired asset reads no price anywhere (every deposit check skips it, redeem reads no feed), so the binding is dead state. Minimal fix that preserves the design: delete feedAsset[a.feed] in the Retire branch; the attached proof passes with that one line.

     Merged from three specialist reports (audit_flow, audit_economics, audit_permissions); all three reproduce identically.

     whole finding

     State: genesis with stocks[0..2] and feeds[0..2], genesis finalized, 72 hours elapsed.

     1. owner: closeAsset(stocks[0]); id = proposeRetire(stocks[0]).

     2. warp +7 days; executeProposal(id) -> assets(0).retired == true and feedAsset(feeds[0]) == stocks[0].

     3. Deploy successor MockStock (decimals 18, new uid registered at STOCK_FACTORY). owner: proposeAsset(successor, feeds[0]).

     Expected: a listing proposal for the migrated stock priced by its true feed.

     Actual: revert InvalidFeed(feeds[0]) from _checkFeed.

     4. owner: proposeFeed(stocks[0], otherFeed) to free the slot.

     Expected: some path releases the binding.

     Actual: revert InvalidState from _liveAsset; feedAsset(feeds[0]) == stocks[0] forever.

     Reproduced in test/scratch/Judge.t.sol::testRetiredAssetLocksFeedForever; the attached proof fails on this tree with InvalidFeed and passes with delete feedAsset[a.feed] added to the Retire branch (verified on a patched copy).

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {BaskVault} from "src/BaskVault.sol";
     
     contract PFactory {
         mapping(bytes32 => address) public tokenAddress;
     
         function register(bytes32 id, address token) external {
             tokenAddress[id] = token;
         }
     }
     
     contract PFeed {
         uint8 public decimals = 8;
         address public aggregator = address(1);
         int256 public answer = 100e8;
         uint256 public updatedAt;
     
         constructor() {
             updatedAt = block.timestamp;
         }
     
         function set(int256 answer_, uint256 time_) external {
             answer = answer_;
             updatedAt = time_;
         }
     
         function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
             return (1, answer, updatedAt, updatedAt, 1);
         }
     }
     
     contract PStock {
         bytes32 public uid;
         uint8 public decimals = 18;
         bool public oraclePaused;
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         constructor(bytes32 id) {
             uid = id;
         }
     
         function mint(address to, uint256 amount) external {
             balanceOf[to] += amount;
         }
     
         function approve(address spender, uint256 amount) external returns (bool) {
             allowance[msg.sender][spender] = 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;
         }
     
         function transfer(address to, uint256 amount) external returns (bool) {
             balanceOf[msg.sender] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     }
     
     /// Fails on the current code: after an asset is retired its Chainlink feed stays bound to the retired
     /// token forever, so a successor token for the same stock can never be listed with its true feed.
     /// Passes once retirement releases the feed binding (for example `delete feedAsset[a.feed]` in the
     /// Retire branch of executeProposal).
     contract ProofRetireLocksFeed is Test {
         address internal constant OWNER = 0x30B57ECf51D19ABcED7F6f70974e6fBb6f3b9Da3;
         address internal constant GUARDIAN = 0x5ed39AF86f2C00ad99913B5d727bD68f2A904B68;
         uint256 internal constant MONDAY = 1_728_259_200;
         BaskVault internal vault;
         PFactory internal factory;
         PStock[] internal stocks;
         PFeed[] internal feeds;
     
         function setUp() public {
             vm.chainId(4663);
             vm.warp(MONDAY + 55800);
             vault = new BaskVault(OWNER, GUARDIAN);
             PFactory template = new PFactory();
             vm.etch(vault.STOCK_FACTORY(), address(template).code);
             factory = PFactory(vault.STOCK_FACTORY());
             for (uint256 i; i < 3; ++i) {
                 PStock stock = new PStock(bytes32(i + 1));
                 PFeed feed = new PFeed();
                 factory.register(stock.uid(), address(stock));
                 stocks.push(stock);
                 feeds.push(feed);
                 vm.prank(OWNER);
                 vault.proposeAsset(address(stock), address(feed));
             }
             vm.prank(OWNER);
             vault.finalizeGenesis();
             vm.warp(block.timestamp + 72 hours);
         }
     
         function testSuccessorTokenCanBeListedWithTheRetiredAssetsFeed() public {
             vm.startPrank(OWNER);
             vault.closeAsset(address(stocks[0]));
             uint256 id = vault.proposeRetire(address(stocks[0]));
             vm.stopPrank();
             vm.warp(block.timestamp + 7 days);
             vault.executeProposal(id);
             (,,, bool retired,,,,) = vault.assets(0);
             assertTrue(retired, "asset 0 retired");
     
             // the issuer re-issues the same stock at a new token address; its true feed is feeds[0]
             PStock successor = new PStock(bytes32(uint256(0x5e)));
             factory.register(successor.uid(), address(successor));
             feeds[0].set(100e8, block.timestamp);
     
             vm.prank(OWNER);
             uint256 listing = vault.proposeAsset(address(successor), address(feeds[0]));
             assertGt(listing, 0, "listing proposal created with the stock's true feed");
             vm.warp(block.timestamp + 7 days);
             vault.executeProposal(listing);
             assertEq(vault.assetIndex(address(successor)), 4, "successor listed");
             assertEq(vault.feedAsset(address(feeds[0])), address(successor), "feed now bound to successor");
         }
     }

     whole proof

   • lowA Stock Token upgraded to debit more than the transfer amount makes every claim for that asset revert forever, stranding the owed tokens with no recovery pathsrc/BaskVault.sol:722

     payLeg requires the vault balance to fall by exactly amount. On the redeem path that strictness is correct: the 250,000-gas self-call reverts, the token movement rolls back and the leg becomes owed. claim, however, reuses the same payLeg with the same exact-equality postcondition and has no alternative.

     If the issuer upgrades the token so that an outgoing transfer debits the sender amount plus a fee or burn (even 1 wei), while still crediting the receiver amount, reporting balances truthfully and returning true, then every redeem leg for that asset is booked as owed and every subsequent claim(token, to) reverts TransferFailed, from any caller, to any receiver, forever.

     The owed balance and the remaining holders' managed share of that token can never leave the vault; there is no sweep, rescue or retirement path that pays it. The README accepts that claims depend on the token moving funds and that a token lying about balances is out of scope; this token is not lying, it is charging a fee, and the vault could deliver amount to the user by tolerating a decrease of at least amount on the claim path.

     The fix is a design decision because the README states the exact-decrease rule: accept beforeBalance - afterBalance >= amount only in the claim path (the attached proof uses a separate self-only payLegClaim helper), keeping exactness on the redeem path. A hostile token gains nothing new from the looser check since the issuer can already burn vault balances directly. Merged from audit_flow and audit_math; both reproduce identically.

     whole finding

     State: 3 genesis assets; Alice deposits 10e18 stock0.

     Set stock0 to MockStock.Mode.ExtraDebit (transfer debits msg.sender amount + 1 wei, credits the receiver amount, returns true).

     Alice redeems all her shares: stock0 leg is booked as owed (owed[ALICE][stock0] = 9.95e18 - dust, managed reduced by the same, vault still holds 10e18).

     Alice calls claim(stock0, ALICE), then after warp +365 days claim(stock0, BOB).

     Expected per the brief: claim is not permanently blocked by a truthful token.

     Actual: both calls revert TransferFailed(stock0) from line 722-723 because beforeBalance - afterBalance == amount + 1; owed is unchanged and the vault still holds all 10e18.

     Reproduced in test/scratch/Judge.t.sol::testExtraDebitTokenStrandsClaimsForever; the attached proof fails on this tree with TransferFailed and passes once the claim path tolerates a decrease >= amount (verified on a patched copy).

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {BaskVault} from "src/BaskVault.sol";
     
     contract PFactory {
         mapping(bytes32 => address) public tokenAddress;
     
         function register(bytes32 id, address token) external {
             tokenAddress[id] = token;
         }
     }
     
     contract PFeed {
         uint8 public decimals = 8;
         address public aggregator = address(1);
         int256 public answer = 100e8;
         uint256 public updatedAt;
     
         constructor() {
             updatedAt = block.timestamp;
         }
     
         function set(int256 answer_, uint256 time_) external {
             answer = answer_;
             updatedAt = time_;
         }
     
         function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
             return (1, answer, updatedAt, updatedAt, 1);
         }
     }
     
     /// Stock Token whose issuer upgrade debits the sender one extra wei per outgoing transfer. It reports
     /// balances truthfully, credits the receiver the full amount and returns true.
     contract PStock {
         bytes32 public uid;
         uint8 public decimals = 18;
         bool public oraclePaused;
         bool public extraDebit;
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         constructor(bytes32 id) {
             uid = id;
         }
     
         function mint(address to, uint256 amount) external {
             balanceOf[to] += amount;
         }
     
         function setExtraDebit(bool on) external {
             extraDebit = on;
         }
     
         function approve(address spender, uint256 amount) external returns (bool) {
             allowance[msg.sender][spender] = 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;
         }
     
         function transfer(address to, uint256 amount) external returns (bool) {
             balanceOf[msg.sender] -= amount + (extraDebit ? 1 : 0);
             balanceOf[to] += amount;
             return true;
         }
     }
     
     /// Fails on the current code: once a Stock Token debits the vault by more than `amount`, redeem
     /// correctly isolates the leg as owed, but every later claim for that token reverts TransferFailed
     /// because claim reuses the exact-decrease postcondition, so the owed tokens can never leave the vault.
     /// Passes once the claim path accepts a vault balance decrease of at least `amount` (the user still
     /// receives exactly `amount`; the overage is the token's own fee), while redeem keeps the exact rule.
     contract ProofExtraDebitClaim is Test {
         address internal constant OWNER = 0x30B57ECf51D19ABcED7F6f70974e6fBb6f3b9Da3;
         address internal constant GUARDIAN = 0x5ed39AF86f2C00ad99913B5d727bD68f2A904B68;
         address internal constant ALICE = address(0xA11CE);
         uint256 internal constant MONDAY = 1_728_259_200;
         BaskVault internal vault;
         PFactory internal factory;
         PStock[] internal stocks;
         PFeed[] internal feeds;
     
         function setUp() public {
             vm.chainId(4663);
             vm.warp(MONDAY + 55800);
             vault = new BaskVault(OWNER, GUARDIAN);
             PFactory template = new PFactory();
             vm.etch(vault.STOCK_FACTORY(), address(template).code);
             factory = PFactory(vault.STOCK_FACTORY());
             for (uint256 i; i < 3; ++i) {
                 PStock stock = new PStock(bytes32(i + 1));
                 PFeed feed = new PFeed();
                 factory.register(stock.uid(), address(stock));
                 stocks.push(stock);
                 feeds.push(feed);
                 stock.mint(ALICE, 1_000e18);
                 vm.prank(ALICE);
                 stock.approve(address(vault), type(uint256).max);
                 vm.prank(OWNER);
                 vault.proposeAsset(address(stock), address(feed));
             }
             vm.prank(OWNER);
             vault.finalizeGenesis();
             vm.warp(block.timestamp + 72 hours);
             for (uint256 i; i < 3; ++i) {
                 feeds[i].set(100e8, block.timestamp);
             }
         }
     
         function testOwedLegCanEventuallyBeClaimedFromAnExtraDebitToken() public {
             vm.prank(ALICE);
             vault.deposit(address(stocks[0]), 10e18, ALICE, 0, block.timestamp);
             stocks[0].setExtraDebit(true);
     
             uint256 shares = vault.balanceOf(ALICE);
             vm.prank(ALICE);
             vault.redeem(shares, new uint256[](0), block.timestamp);
             uint256 owed = vault.owed(ALICE, address(stocks[0]));
             assertGt(owed, 0, "leg isolated as owed");
     
             uint256 before = stocks[0].balanceOf(ALICE);
             vm.prank(ALICE);
             uint256 paid = vault.claim(address(stocks[0]), ALICE);
             assertEq(paid, owed, "claim pays the owed amount");
             assertEq(stocks[0].balanceOf(ALICE) - before, owed, "user received the owed tokens");
             assertEq(vault.owed(ALICE, address(stocks[0])), 0, "debt cleared");
             assertEq(vault.totalOwed(address(stocks[0])), 0, "total debt cleared");
         }
     }

     whole proof

   • lowThe guardian veto is a 7-day delay, not a block: the owner can replace the guardian with a proposal the guardian cannot cancel and then re-propose the vetoed retirementsrc/BaskVault.sol:391

     The brief states that owner changes wait 7 days and the guardian can veto, and asks whether retirement can skip the guardian veto. cancelProposal excludes Kind.Guardian from the guardian's cancel right. The owner can therefore propose a retirement and a guardian replacement in the same block; the guardian can cancel the retirement but not its own replacement.

     After 7 days the replacement executes, the owner re-proposes the retirement and the new guardian does not veto, so the retirement executes on day 14 with the README-documented dilution of existing holders. The same holds for every proposal kind, and for the immediate powers (closeAsset, pauseDeposits) the guardian's only recourse is the same race.

     The README documents that the guardian cannot cancel guardian replacement, so this is reported as a precise statement of the veto's strength (a delay of at most 14 days from first proposal) rather than an undocumented bypass, and as a trust assumption on the owner key. If a real veto is wanted, the sitting guardian should be able to cancel its own replacement, or the replacement should carry a longer delay than the proposals it can neutralise.

     No proof attached because the fix changes the documented governance rule.

     whole finding

     State: Alice deposits 100 stock0.

     Owner: closeAsset(stock0); id1 = proposeRetire(stock0); id2 = proposeGuardian(0x6A6A).

     Guardian: cancelProposal(id1) succeeds; cancelProposal(id2) reverts Unauthorized.

     Warp +7 days: executeProposal(id2) sets guardian == 0x6A6A.

     Owner: id3 = proposeRetire(stock0); the old guardian's cancelProposal(id3) reverts Unauthorized.

     Warp +7 days: executeProposal(id3) succeeds and assets(0).retired == true.

     Expected from the brief: the guardian's veto prevents the retirement.

     Actual: it postpones it by 7 days.

     Reproduced in test/scratch/Judge.t.sol::testGuardianVetoOfRetirementIsOnlyADelay.

     whole reproduction

   • infoThe 25,000 USD per-asset floor hard-bounds NAV at 25,000 USD times the asset count until more than 20 assets are listed; the 1,000,000 USD initial NAV_CAP is unreachable with 3 genesis assetssrc/BaskVault.sol:621

     The ordinary per-asset cap is max(5% of post-deposit NAV, 25,000e18). The 5% term only exceeds the floor once NAV2 > 500,000e18, but with N non-probation assets each stuck at the floor NAV cannot exceed 25,000e18 * N, and for N <= 20 the inequality value + delta <= max(0.05 * (NAV + delta), 25,000e18) fails for every delta > 0 once each asset holds 25,000e18. Probation assets add at most 5,000e18 of capacity for 30 days.

     So the 3-asset genesis basket has a hard ceiling of 75,000e18 regardless of NAV_CAP, and retiring one floor-level asset immediately blocks deposits into every remaining held asset until others are listed. This follows from the stated formula and is not a bypass; it is reported so the owner sizes the genesis basket and the NAV_CAP expectation accordingly. From audit_math; reproduces.

     State: 3 genesis assets at $100; Alice deposits 250 tokens (25,000e18 USD) into each; NAV = 75,000e18, NAV_CAP = 1,000,000e18.

     Expected by an operator reading the 5% rule with a 1M cap: further deposits possible.

     Actual: deposit(stock_i, 1 wei, ...) reverts DepositUnavailable(AssetCap, stock_i) for i in 0..2.

     Reproduced in test/scratch/Judge.t.sol::testPerAssetFloorBoundsNAVWithThreeAssets.

   • infoRetired assets permanently consume listing slots, so a vault that retires 62 tokens can never regain the three-fresh-feed deposit quorumsrc/BaskVault.sol:444

     Assets are append-only and retirement does not free the slot. _checkListing rejects any listing once assets.length reaches 64, including when most entries are retired. Deposits need at least three unretired assets with a feed updated within 4 hours.

     Over the life of an immutable vault whose Stock Tokens can be paused, upgraded or migrated by the issuer, each broken token costs one slot forever; after 62 retirements deposits are permanently impossible while redeem and claim keep working. Not a bypass; an operational ceiling the README does not state.

     Related to, but mechanically distinct from, the feed-binding finding (different storage, different fix: allow a listing to reuse a retired slot, which changes the stated append-only rule). From audit_math; reproduces.

     State: 64 genesis assets; Alice deposits 1e18 of stocks[63].

     Owner: closeAsset + proposeRetire for stocks[0..61]; warp +7 days; executeProposal for all 62. assetCount() == 64.

     Owner: proposeAsset(newToken, newFeed) -> revert AssetLimit(). depositStatus(stocks[63]) == MarketNotFresh (fresh can never reach 3 with 2 unretired assets).

     Alice can still redeem all her shares.

     Reproduced in test/scratch/Judge.t.sol::testRetiredSlotsAreNeverFreedAndQuorumIsLost.

   • infoclaim accepts address(0) as the receiving address while deposit rejects it, so a mistaken claim burns the user's owed tokenssrc/BaskVault.sol:741

     deposit rejects receiver == address(0) and == address(this); claim validates nothing about to. A Stock Token that allows transfers to the zero address (the local mock does; many ERC-20s do) sends the owed tokens to 0x0, the exact-decrease check passes, and the owed record is cleared. Self-harm only, no effect on other users (claim to the vault's own address already reverts cleanly because the balance does not decrease).

     Reported as an input-validation asymmetry between the two user-facing receiver parameters; the fix is a one-line InvalidAddress check. From audit_math; reproduces.

     State: Alice deposits 100 stock0; the token blocks Alice; she redeems all shares so owed[ALICE][stock0] = 99.5e18.

     Alice calls claim(stock0, address(0)).

     Expected: revert InvalidAddress like deposit.

     Actual: returns 99.5e18, owed is zero and stock0.balanceOf(address(0)) == 99.5e18.

     Reproduced in test/scratch/Judge.t.sol::testClaimToZeroAddressBurnsOwedTokens; the attached proof fails on this tree (the call does not revert) and passes with the zero check added to claim (verified on a patched copy).

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {BaskVault} from "src/BaskVault.sol";
     
     contract PFactory {
         mapping(bytes32 => address) public tokenAddress;
     
         function register(bytes32 id, address token) external {
             tokenAddress[id] = token;
         }
     }
     
     contract PFeed {
         uint8 public decimals = 8;
         address public aggregator = address(1);
         int256 public answer = 100e8;
         uint256 public updatedAt;
     
         constructor() {
             updatedAt = block.timestamp;
         }
     
         function set(int256 answer_, uint256 time_) external {
             answer = answer_;
             updatedAt = time_;
         }
     
         function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
             return (1, answer, updatedAt, updatedAt, 1);
         }
     }
     
     /// Stock Token with an issuer blocklist; transfers to address(0) are allowed, as in many ERC-20s.
     contract PStock {
         bytes32 public uid;
         uint8 public decimals = 18;
         bool public oraclePaused;
         mapping(address => bool) public blocked;
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         constructor(bytes32 id) {
             uid = id;
         }
     
         function mint(address to, uint256 amount) external {
             balanceOf[to] += amount;
         }
     
         function blockAddress(address who, bool on) external {
             blocked[who] = on;
         }
     
         function approve(address spender, uint256 amount) external returns (bool) {
             allowance[msg.sender][spender] = amount;
             return true;
         }
     
         function transferFrom(address from, address to, uint256 amount) external returns (bool) {
             require(!blocked[from] && !blocked[to], "blocked");
             allowance[from][msg.sender] -= amount;
             balanceOf[from] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     
         function transfer(address to, uint256 amount) external returns (bool) {
             require(!blocked[msg.sender] && !blocked[to], "blocked");
             balanceOf[msg.sender] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     }
     
     /// Fails on the current code: claim(token, address(0)) sends the owed tokens to the zero address and
     /// clears the debt, while deposit rejects a zero receiver. Passes once claim rejects to == address(0)
     /// with InvalidAddress like deposit does.
     contract ProofClaimZeroAddress is Test {
         address internal constant OWNER = 0x30B57ECf51D19ABcED7F6f70974e6fBb6f3b9Da3;
         address internal constant GUARDIAN = 0x5ed39AF86f2C00ad99913B5d727bD68f2A904B68;
         address internal constant ALICE = address(0xA11CE);
         uint256 internal constant MONDAY = 1_728_259_200;
         BaskVault internal vault;
         PFactory internal factory;
         PStock[] internal stocks;
         PFeed[] internal feeds;
     
         function setUp() public {
             vm.chainId(4663);
             vm.warp(MONDAY + 55800);
             vault = new BaskVault(OWNER, GUARDIAN);
             PFactory template = new PFactory();
             vm.etch(vault.STOCK_FACTORY(), address(template).code);
             factory = PFactory(vault.STOCK_FACTORY());
             for (uint256 i; i < 3; ++i) {
                 PStock stock = new PStock(bytes32(i + 1));
                 PFeed feed = new PFeed();
                 factory.register(stock.uid(), address(stock));
                 stocks.push(stock);
                 feeds.push(feed);
                 stock.mint(ALICE, 1_000e18);
                 vm.prank(ALICE);
                 stock.approve(address(vault), type(uint256).max);
                 vm.prank(OWNER);
                 vault.proposeAsset(address(stock), address(feed));
             }
             vm.prank(OWNER);
             vault.finalizeGenesis();
             vm.warp(block.timestamp + 72 hours);
             for (uint256 i; i < 3; ++i) {
                 feeds[i].set(100e8, block.timestamp);
             }
         }
     
         function testClaimRejectsZeroReceiverLikeDeposit() public {
             vm.prank(ALICE);
             vault.deposit(address(stocks[0]), 100e18, ALICE, 0, block.timestamp);
             stocks[0].blockAddress(ALICE, true);
             uint256 shares = vault.balanceOf(ALICE);
             vm.prank(ALICE);
             vault.redeem(shares, new uint256[](0), block.timestamp);
             uint256 owed = vault.owed(ALICE, address(stocks[0]));
             assertGt(owed, 0, "leg owed to the blocked redeemer");
     
             vm.prank(ALICE);
             vm.expectRevert(BaskVault.InvalidAddress.selector);
             vault.claim(address(stocks[0]), address(0));
             assertEq(vault.owed(ALICE, address(stocks[0])), owed, "debt preserved");
             assertEq(stocks[0].balanceOf(address(0)), 0, "nothing burned");
         }
     }

     whole proof

   • infoproposalState reports Pending for Reopen, Band and Feed proposals whose asset has since been retired, although they can never executesrc/BaskVault.sol:382

     proposalState is documented as the effective lifecycle state and pendingProposals relies on it.

     It implements implicit cancellation for a Reopen whose closeVersion moved and a NAV-cap raise whose capVersion moved, but retirement is a third terminal event it does not reflect: after executeProposal(Retire), pending Reopen, Band and Feed proposals on that token still return State.Pending and are listed by pendingProposals, while executeProposal reverts InvalidState from _liveAsset on every attempt until they expire at 14 days.

     Monitoring that trusts the view (for example a guardian deciding what still needs a veto) sees live-looking proposals that are dead. No funds affected.

     Fix: in proposalState return State.Cancelled when p.token is a listed asset whose retired flag is set (same pattern as the existing version checks). From audit_permissions; reproduces.

     State: stocks[0] listed and open.

     Owner: closeAsset(stocks[0]); r = proposeReopen(stocks[0]); b = proposeBand(stocks[0]); f = proposeFeed(stocks[0], otherFeed); t = proposeRetire(stocks[0]).

     Warp +7 days; executeProposal(t).

     Expected: proposalState(r), (b), (f) are non-pending and pendingProposals(1, 10) omits them.

     Actual: all three return State.Pending (1), pendingProposals lists 3 ids, and executeProposal on each reverts InvalidState.

     Reproduced in test/scratch/Judge.t.sol::testProposalStateStaysPendingForDeadProposalsAfterRetire; the attached proof fails on this tree and passes with the retired-asset check added to proposalState (verified on a patched copy).

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

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {BaskVault} from "src/BaskVault.sol";
     
     contract PFactory {
         mapping(bytes32 => address) public tokenAddress;
     
         function register(bytes32 id, address token) external {
             tokenAddress[id] = token;
         }
     }
     
     contract PFeed {
         uint8 public decimals = 8;
         address public aggregator = address(1);
         int256 public answer = 100e8;
         uint256 public updatedAt;
     
         constructor() {
             updatedAt = block.timestamp;
         }
     
         function set(int256 answer_, uint256 time_) external {
             answer = answer_;
             updatedAt = time_;
         }
     
         function latestRoundData() external view returns (uint80, int256, uint256, uint256, uint80) {
             return (1, answer, updatedAt, updatedAt, 1);
         }
     }
     
     contract PStock {
         bytes32 public uid;
         uint8 public decimals = 18;
         bool public oraclePaused;
         mapping(address => uint256) public balanceOf;
         mapping(address => mapping(address => uint256)) public allowance;
     
         constructor(bytes32 id) {
             uid = id;
         }
     
         function approve(address spender, uint256 amount) external returns (bool) {
             allowance[msg.sender][spender] = 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;
         }
     
         function transfer(address to, uint256 amount) external returns (bool) {
             balanceOf[msg.sender] -= amount;
             balanceOf[to] += amount;
             return true;
         }
     }
     
     /// Fails on the current code: after an asset is retired, pending Reopen, Band and Feed proposals on it
     /// still report State.Pending from proposalState and are listed by pendingProposals, although
     /// executeProposal reverts InvalidState on every one of them. Passes once proposalState reports a
     /// non-pending state (Cancelled) for asset-scoped proposals whose asset is retired.
     contract ProofProposalStateAfterRetire is Test {
         address internal constant OWNER = 0x30B57ECf51D19ABcED7F6f70974e6fBb6f3b9Da3;
         address internal constant GUARDIAN = 0x5ed39AF86f2C00ad99913B5d727bD68f2A904B68;
         uint256 internal constant MONDAY = 1_728_259_200;
         BaskVault internal vault;
         PFactory internal factory;
         PStock[] internal stocks;
         PFeed[] internal feeds;
     
         function setUp() public {
             vm.chainId(4663);
             vm.warp(MONDAY + 55800);
             vault = new BaskVault(OWNER, GUARDIAN);
             PFactory template = new PFactory();
             vm.etch(vault.STOCK_FACTORY(), address(template).code);
             factory = PFactory(vault.STOCK_FACTORY());
             for (uint256 i; i < 3; ++i) {
                 PStock stock = new PStock(bytes32(i + 1));
                 PFeed feed = new PFeed();
                 factory.register(stock.uid(), address(stock));
                 stocks.push(stock);
                 feeds.push(feed);
                 vm.prank(OWNER);
                 vault.proposeAsset(address(stock), address(feed));
             }
             vm.prank(OWNER);
             vault.finalizeGenesis();
             vm.warp(block.timestamp + 72 hours);
         }
     
         function testRetirementMakesAssetScopedProposalsNonPending() public {
             PFeed other = new PFeed();
             vm.startPrank(OWNER);
             vault.closeAsset(address(stocks[0]));
             uint256 r = vault.proposeReopen(address(stocks[0]));
             uint256 b = vault.proposeBand(address(stocks[0]));
             uint256 f = vault.proposeFeed(address(stocks[0]), address(other));
             uint256 t = vault.proposeRetire(address(stocks[0]));
             vm.stopPrank();
             vm.warp(block.timestamp + 7 days);
             vault.executeProposal(t);
     
             // each of these can never execute again (InvalidState today; InvalidProposal once reported as cancelled)
             vm.expectRevert();
             vault.executeProposal(r);
             vm.expectRevert();
             vault.executeProposal(b);
             vm.expectRevert();
             vault.executeProposal(f);
     
             assertTrue(vault.proposalState(r) != BaskVault.State.Pending, "reopen on retired asset is not pending");
             assertTrue(vault.proposalState(b) != BaskVault.State.Pending, "band on retired asset is not pending");
             assertTrue(vault.proposalState(f) != BaskVault.State.Pending, "feed on retired asset is not pending");
             (uint256[] memory ids,) = vault.pendingProposals(1, 10);
             assertEq(ids.length, 0, "no dead proposals listed as pending");
         }
     }

     whole proof
7. Onchain1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,142,658 · transaction#1614#205#1207#540#687