If there are unstaked assets, LRT can be depostied and redeemed for the underlying asset

Currently the restaking repo does not support the Token Extensions Program ( Token22 ). Since the Token Extensions Program is a byte for byte recreation of the Token Program, we only need to accept both token program, we will not support any advance features out of the gate.

via felix @ asymmetric:

One pattern that seems a bit risky is that you initialize fields like VaultOperatorDelegation::last_update_slot to 0 when the account is created. I think it would be more correct to set them to the current slot during creation.

For SlotToggle structs, we should be setting the slot added and slot removed to the current slot

Add a minimum amount out when burning assets from the vault to avoid high slippage from fees or a slashing event in between getting the spot price and it executing on-chain

via Felix @ Asymmetric:

• BurnWithdrawTicket is permissionless. I think that could be fine, but the problem is that min_out is passed via the Instruction. This could be abused by triggering a lot of slippage and burning other peoples withdraw tickets with a min_out of 0

We don't want vault withdrawal tickets sitting around as they cause a yield drag on the assets in the vault and can allow someone to continue earning rewards, but frontrun withdraws.

Given:

• There is a withdraw ticket created with funds cooling down for withdraw. Let's say the ratio is 1:1, so 1000 VRTs were deposited and 1000 collateral tokens were set aside.

When:

• There is a slashing event of 100 tokens while the funds are maturing in the VaultDelegationList.

Then:

• There will be 900 total tokens set aside for the withdrawal reserve in the vault, but the withdrawal ticket has 1000. When burning the withdraw ticket, there will be an underflow and the program is stuck.

Looks like a double borrow might be possible

• Replace withdrawal asset instruction with an instruction that allows one to delegate the token account to a third party
• Accept spl token program or token22 (allows delegation of transfer_checked/more complex withdrawal logic to third parties)

Entities can avoid slashing if they deactivate. There needs to be a cooldown period for deactivation. Ideally one full solana epoch.

Add more specific errors for operations and instructions that have several failure modes

When I run cargo nextest run --all-features, sometimes, test fails at vault::crank_vault_update_state_tracker::tests::test_crank_vault_update_state_tracker_same_index_twice_fails.

thread 'vault::crank_vault_update_state_tracker::tests::test_crank_vault_update_state_tracker_same_index_twice_fails' panicked at integration_tests/tests/vault/crank_vault_update_state_tracker.rs:289:9:
assertion `left == right` failed
  left: AlreadyProcessed
 right: InstructionError(0, Custom(2020))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Environment:
OS: Ubuntu 22.04.4 LTS
rustc: rustc 1.80.0 (051478957 2024-07-21)

AVS, operator, and vault opt-in is difficult to track across different accounts. In addition, the amount staked can be difficult to track across vaults too. For AVS that allow stake from different vaults, normalizing the prices between the assets in the vault can be difficult too.

Need to build a program that stores all of this information in an account so AVS can load it. As a part of this, it may be worth considering adding an activation period so staked amounts, opt-in/opt-out can't be changed mid-epoch.

Currently, when processing the crank_vault_update_state_tracker instruction, we only check the state of the VaultUpdateStateTracker. However, we do not verify the VaultOperatorDelegation state. To prevent issues, we should ensure that the VaultOperatorDelegation is not updated within the same epoch.

Boxes are used (yuk). Try zero-copy or design better account loading so the program is more efficient

Add a minimum amount out when minting assets from the vault to avoid high slippage from fees or a slashing event in between getting the spot price and it executing on-chain

Add per-epoch withdraw caps on a vault basis as a pro-rata share of the vault stake which prevents excess withdraws

The vault delegation list can grow unbounded, which may overflow the stack and/or heap. In addition to more efficient deser, consider adding a custom heap function.

The vault needs some encoding around max deposit + withdraw fees. Something in the 5% range seems reasonable.

In addition, to avoid sudden changes in the withdraw/deposit fee, it would be wise to add limitations on how much the deposit/withdraw fees can change within a given time window.

When initializing the vault, the current implementation sets last_full_state_update_slot to 0. However, I believe it should be initialized with the current slot. If it's set to 0, it creates an issue with the initialization of vault_operator_delegation, resulting in a VaultError::VaultUpdateNeeded.

Payer not needed since no accounts are being created

For situations where keypair is hacked, allowing for changing of staker in VaultStakerWithdrawTicket would be nice. Need to change PDA derivation to not include staker (be based on some random base keypair that's a signer on the message)