Skip to content
This repository was archived by the owner on Jun 23, 2026. It is now read-only.
bigzPubkey edited this page Jun 20, 2023 · 10 revisions

The drift-vaults program is a proof-of-concept example of composing on top of drift protocol-v2. It's an open, permissionless contract for a group to deposit and withdraw into a shared pool (or "vault") managed by a single delegate. The vault's delegate is limited to only place/cancel orders on behalf of the pooled user account. For their services, the vault manager can set custom terms for the agreement.

Initialization

Upon vault initialization, a vault manager can set:

  • name (unique identity for the vault)
  • management fee (can only be updated lower)
  • performance fee (can only be updated lower)
  • redemption period (can only be updated lower)
  • permissioned (optional, only vault manager can initialize new vault depositor accounts)

Deposit / Withdraw

Vault depositors can choose a vault to deposit in upon withdraw receive their pro-rata share of the pool (after fees). Withdraws first require a request, followed by waiting the custom redemption period, then ultimately withdrawing. The value received is the worse of the before and after value, which gives the remaining depositors the best outcome and avoids the ability to 'target' or 'punish' the particular user withdrawing when there are others still in the pool.

Fees

Fees parameters are in PERCENTAGE_PRECISION (1e6) and annualized.

Management fees are charged across the entire vault (and only when there are non-manager deposits). They are compounding upon action, so with frequent vault depositors actions the fee is slightly lower.

Performance fees are calculated upon per depositor action and can also be 'triggered' periodically. "Watermarks" are tracked to ensure no double charging for oscillating or drawdown. Note that this fee cannot be clawed back.

Liquidations

In the event that a vault depositor withdraw attempt violates the account's initial margin requirement (i.e the vault manager's delegate is running the account with too much leverage), the vault depositor can temporarily take over the account and close out positions. Vault managers can track outstanding total withdraw requests to ensure their strategies don't consume too much margin to allow for depositor take overs. A custom set redemption period can help give time for certain strategy to 'unwind' safely/prudently.

Risks

This design/implementation is not trustless between depositors and vault managers. If the vault manager's reputation or other stake is not there the incentives can be mismatched. Simply put, so long as the amount managed exceeds any manager personal stake, the adversarial incentive is to drain the vault by placing losing trades to another account. Thus it is very important for depositors to trust the vault manager as there is no on-chain method for recourse.

If you are a developer or mechanism designer with ideas on creating stronger 'skin-the-game' relationship, please share in Issues

Design Space

Below are a few example use cases:

  • pooled market making

a single market maker who wants run a strategy multiple passive capital providers. each one gets pro-rata performance. permissioned assumes there is some off-chain trust/relationship 0 management fee, 5% performance fee, 3-day redemption period to incentivize manager returns for strategy

  • index fund

manager creates vault with 0% performance fee and .1% management fee offering a crypto market-cap weighted basket 1-day redemption period for time for rebalancing

  • leverage lending

manager deposits $1 and adds -1000% manager fee, 0 redemption period (paying depositors for providing capital) depositors come in, enticed by negative fee, and give manager access to more margin. depositors can take over whenever they deem the manager fee isnt worth it (e.g. manager owned is too low or zero)

Clone this wiki locally