drift-labs / drift-vaults

a vault program on top of protocol-v2 for delegate-managed trades with customizable terms

Drift Vaults

soon^TM

did you see the CLI? and the wiki?

Development

• anchor 0.29.0
• rust 1.70.0
• solana 1.16.27

avm use 0.29.0
rustup default 1.70.0
sh -c "$(curl -sSfL https://release.solana.com/v1.16.27/install)"

Run tests

cd ts/sdk
yarn
yarn build

cd ..
export ANCHOR_WALLET=~/.config/solana/id.json
anchor test

drift-vaults's Issues

Delete / Finalize Vaults

sharing thoughts on topic raise by both @dannpl and @wphan

• easy to support if vault.total_shares = 0 and vault.init_ts - now > MIN_VAULT_LIFETIME, then let anyone close out vault (and associated user account through cpi call)
• force closure, when these invariants above aren't true, seems more difficult/complex
• ensuring that vault.total_shares can get to 0 (rather than dust) should be examined during testing

Trust Model between Depositors, Vault Managers, and Delegates

Issue Summary:

Current implementation of the Drift-Vaults program, as described in the wiki, requires significant trust from depositors towards both the vault manager and delegate. In addition, vault managers need to trust the delegate. Although certain incentives and penalties are in place, potential weaknesses and vulnerabilities may still exist. There is a need to explore additional strategies to enhance the robustness of the trust model.

Detailed Description:

Presently, the vault manager earns management fees and profit shares, providing an incentive to attract deposits and maintain good performance. However, this structure relies on the depositor's trust in the manager's ability to deliver sustainable returns. While historical performances provide some degree of assurance, they are insufficient in guaranteeing future outcomes. If the manager and delegate roles were managed via upgradable time-delayed smart contracts, this could improve deterministic properties of the system.

Still some potential vulnerabilities exist that could undermine trust. Some potential enhancements to address these concerns (that I believe are more complex than the guarantees they provide):

• Mandatory Excessive Manager Collateral: This solution requires the manager to provide substantial collateral as a guarantee. However, it is challenging to enforce and requires the manager to provide large upfront capital, somewhat negating the purpose of the vault program.

• Delegate Instruction Introspection: This solution involves monitoring and evaluating the delegate's instructions to prevent potentially detrimental actions. However, defining 'bad orders' is non-trivial, and excessive restrictions could inadvertently limit strategies for preventing loss.

• Custom Approved Counterparty Lists: Allowing users to create a list of approved counterparties for trades could enhance trust. However, the risk of collusion between the manager and an approved counterparty, if not the vAMM, could offset its benefits.

Add memo when creating a vault

We going to create a open source socialFi for slide.

We want to add a flag to find easy if the vault is created by Slide

https://github.com/slide-labs/slide-socialfi

it's helpfully if add a memo

drift-vaults/programs/drift_vaults/src/state/vault.rs

Line 28 in 76c2751

pub struct Vault {

#[assert_no_slop]
#[account(zero_copy)]
#[derive(Default, Eq, PartialEq, Debug)]
#[repr(C)]
pub struct Vault {
    /// The memo of the vault. (e. g Slide - Vault)
    pub memo: [u8; 32],