vault-strategy: raise MAX_ASSETS to 16

Bump the basket cap from 8 to 16 (used only in add_asset's TooManyAssets guard;
assets are separate PDAs, so no layout impact). Update the worked account-count
numbers in the MAX_ASSETS comment and README: at 16 assets deposit references 94
accounts and withdraw 74, still within the 128-account transaction lock limit but
past the 1232-byte legacy size, so large baskets need a v0 transaction with an
Address Lookup Table.

Add test_add_asset_enforces_max_assets: fill a strategy to 16 assets (625 bps each)
and assert the 17th reverts with TooManyAssets. 20 tests pass.

Author: claude

finance/vault-strategy/anchor/README.md

@@ -25,7 +25,7 @@ A note on the word **vault**: by the common standard (ERC-4626) a vault holds a
 
 Because the asset set is dynamic, `deposit` must value *every* asset. The assets live at PDAs indexed `0..asset_count`, and `deposit` re-derives that complete range from the accounts it is given, refusing to run if any asset is missing (`IncompleteAssetAccounts`). This makes it structurally impossible to omit an asset and understate NAV.
 
-Referencing every asset has a transaction-size cost: `deposit` pulls in `14 + 5N` accounts and `withdraw` `10 + 4N`, where `N` is the asset count. That stays within Solana's 128-account transaction lock limit at the `MAX_ASSETS` cap of 8 (54 accounts for `deposit`), but a basket beyond roughly three assets no longer fits a legacy transaction's 1232-byte limit, so the client must send a v0 transaction with an [Address Lookup Table](https://docs.anza.xyz/proposals/versioned-transactions).
+Referencing every asset has a transaction-size cost: `deposit` pulls in `14 + 5N` accounts and `withdraw` `10 + 4N`, where `N` is the asset count. That stays within Solana's 128-account transaction lock limit at the `MAX_ASSETS` cap of 16 (94 accounts for `deposit`), but a basket beyond roughly three assets no longer fits a legacy transaction's 1232-byte limit, so the client must send a v0 transaction with an [Address Lookup Table](https://docs.anza.xyz/proposals/versioned-transactions).
 
 Prices come from [Pyth Network](https://pyth.network/) `PriceUpdateV2` accounts. A 60-second staleness window is enforced; zero or negative prices are rejected.
 

finance/vault-strategy/anchor/programs/vault-strategy/src/state/strategy.rs

@@ -4,12 +4,12 @@ use anchor_lang::prelude::*;
 /// (each asset is its own account); the cap bounds how many accounts deposit and
 /// withdraw, which must reference every asset at once, pull into a single
 /// instruction: deposit uses 14 + 5*N accounts and withdraw 10 + 4*N, where N is the
-/// asset count. At the cap of 8 that is 54 accounts for deposit, comfortably within
-/// Solana's 128-account transaction lock limit but past the 1232-byte legacy
+/// asset count. At the cap of 16 that is 94 accounts for deposit (74 for withdraw),
+/// within Solana's 128-account transaction lock limit but past the 1232-byte legacy
 /// transaction size (which fits only ~3 assets), so a client depositing into a large
 /// basket must send a v0 transaction with an Address Lookup Table. USDC is the base
 /// currency, held separately, and does not count against this.
-pub const MAX_ASSETS: u8 = 8;
+pub const MAX_ASSETS: u8 = 16;
 
 /// One strategy (basket). Its address is a PDA seeded by a caller-chosen index,
 /// e.g. seeds `"strategy" + 0`, so strategies are addressed by a simple counter

finance/vault-strategy/anchor/programs/vault-strategy/tests/vault_strategy.rs

@@ -755,6 +755,58 @@ fn test_add_asset_rejects_weight_overflow() {
     assert!(result.is_err(), "weights over 10000 bps must fail");
 }
 
+/// Create a fresh mint and whitelist it in the registry. The bound price feed is an
+/// arbitrary pubkey: callers that never value this asset (e.g. the cap boundary test)
+/// do not need a real feed account.
+fn create_and_whitelist_mint(ctx: &mut TestContext) -> (Pubkey, Pubkey) {
+    let mint = create_token_mint(&mut ctx.svm, &ctx.payer, TOKEN_DECIMALS, None).unwrap();
+    let (entry, _) = Pubkey::find_program_address(
+        &[b"whitelist", ctx.registry_pda.as_ref(), mint.as_ref()],
+        &ctx.vault_program_id,
+    );
+    let ix = Instruction::new_with_bytes(
+        ctx.vault_program_id,
+        &vault_strategy::instruction::WhitelistAsset {
+            price_feed: Keypair::new().pubkey(),
+        }
+        .data(),
+        vault_strategy::accounts::WhitelistAssetAccountConstraints {
+            authority: ctx.payer.pubkey(),
+            registry: ctx.registry_pda,
+            asset_mint: mint,
+            whitelist_entry: entry,
+            system_program: system_program::id(),
+        }
+        .to_account_metas(None),
+    );
+    send_transaction_from_instructions(&mut ctx.svm, vec![ix], &[&ctx.payer], &ctx.payer.pubkey())
+        .unwrap();
+    (mint, entry)
+}
+
+#[test]
+fn test_add_asset_enforces_max_assets() {
+    let mut ctx = setup_full();
+    let router = ctx.router_program_id;
+    init_strategy(&mut ctx, FEE_BPS, SLIPPAGE_BPS, router);
+
+    // Fill the basket to the cap: 16 assets at 625 bps each = 10000.
+    for index in 0..16u8 {
+        let (mint, entry) = create_and_whitelist_mint(&mut ctx);
+        let vault = derive_ata(&ctx.strategy_pda, &mint);
+        add_asset(&mut ctx, index, mint, entry, vault, 625).unwrap();
+    }
+    let strategy = read_strategy(&ctx);
+    assert_eq!(strategy.asset_count, 16);
+    assert_eq!(strategy.total_weight_bps, 10_000);
+
+    // The 17th asset must be rejected. Weight 0 so the cap, not the weight sum, trips.
+    let (mint, entry) = create_and_whitelist_mint(&mut ctx);
+    let vault = derive_ata(&ctx.strategy_pda, &mint);
+    let result = add_asset(&mut ctx, 16, mint, entry, vault, 0);
+    assert!(result.is_err(), "adding beyond MAX_ASSETS must revert");
+}
+
 #[test]
 fn test_initialize_rejects_excessive_fee() {
     let mut ctx = setup_full();