vault-strategy: index-seeded strategies, auto-deploying deposits, and set_weight

[mikemaccana]

Summary

Reworks the vault-strategy example with three changes plus a cleanup:

• Strategies are addressed by a caller-chosen index instead of the manager's key.
• Deposits are deployed into the basket at their target weights in the same transaction, and a strategy must be fully allocated (weights sum to 100%) before it accepts deposits.
• A new set_weight instruction lets the manager retune or retire an asset.
• The now-redundant invest handler is removed.

Key Changes

• Strategy PDA seed: ["strategy", index] (a u64 chosen at init) instead of ["strategy", manager_pubkey], so a manager can run more than one strategy. The manager is still stored on the Strategy account and used for has_one authorization.
• Auto-deploying deposits: deposit values every asset for NAV, mints shares, then swaps each depositor's USDC into the basket at its target weights through the registered router, in one transaction, under an oracle-computed slippage floor. Its remaining_accounts are now [asset_config, vault, mint, rate, price_feed] per asset, plus the router accounts. No USDC is left sitting idle.
• Full-allocation invariant: a strategy accepts deposits only once its target weights sum to exactly 10,000 bps; deposit reverts with StrategyNotFullyAllocated otherwise. add_asset and set_weight keep the <= 10,000 cap so the manager can pass through intermediate states while configuring.
• set_weight (new, manager-only): changes an asset's target weight, including to zero to retire it. The asset's index is preserved, so the contiguous 0..asset_count range the valuation handlers depend on stays intact. Retiring an asset then means reassigning its weight to another asset to return to 100% and selling the holdings out with rebalance.
• Removed invest: once deposits fully deploy and rebalance covers asset-to-asset moves (including liquidating a retired asset), a "deploy idle USDC" handler has no honest role and contradicts the full-allocation invariant.
• Basket cap: MAX_ASSETS raised from 8 to 16.
• Docs: README.md and CHANGELOG.md updated to match. (VIDEO_SCRIPT.md is intentionally not part of this PR.)

Implementation Details

• The strategy index is stored on the account and used (as to_le_bytes()) to re-derive the PDA for signer seeds across deposit, collect_fees, rebalance, withdraw, and add_asset.
• deposit deploys usdc_amount * weight_bps / 10000 per asset via mock_swap_router::cpi::swap_usdc_for_asset with the strategy PDA signing; retired assets (weight 0) are skipped, and only sub-cent rounding dust can remain as USDC.
• Referencing every asset bounds basket size: deposit uses 14 + 5N accounts and withdraw 10 + 4N (N = asset count). At MAX_ASSETS = 16 that is 94 accounts for deposit, within Solana's 128-account transaction lock limit but past the 1232-byte legacy transaction size (~3 assets), so a large basket needs a v0 transaction with an Address Lookup Table (documented in the README and the MAX_ASSETS comment).
• Tested with cargo build-sbf + cargo test (LiteSVM), 20 tests: the full lifecycle (deposit + auto-deploy, a price move, rebalance back to target, a second depositor priced at the new NAV, a year's fee, in-kind withdrawal), retire-then-reallocate, the MAX_ASSETS boundary (fill to 16, reject the 17th), and the rejection paths (under-allocated strategy, non-manager set_weight, unregistered router, incomplete asset accounts, oracle-bounded slippage, over-cap fee/slippage, non-whitelisted asset, weight overflow).

Note on large baskets: the suite exercises deposits with 2 assets over legacy transactions. A deposit into a near-cap basket must be sent as a v0 transaction with an Address Lookup Table and runs ~N router swap CPIs, whose compute-unit cost is not yet covered by a test.

https://claude.ai/code/session_01RajngzX57RGaQx5sKPbysZ

🤖 Generated with Claude Code