Revenue Pool
A portion of the fees collected within the protocol (denominated in a particular token: USDC, SOL, etc) go into that spot market's revenue pool.
The revenue pool increases from various portions of the protocol:
- borrow fees
- spot market exchange fees
- perpetual market exchange fees
- liquidations
and ultimately goes to fund:
- insurance vault
- perpetual market amm (conditionally)
Insurance Fund
Every hour (on the hour), a portion of the revenue pool can be settled to the insurance fund using the permissionless settle_revenue_to_insurance_fund instruction:
If the insurance fund has users staked, each individual hourly settlement is capped to what would amount to 1000% APR
- thus an astronomically large inflow into the revenue pool (relatively to user insurance staked amounts) would result in revenue that slowly reaches the insurance over a longer period of time rather than immediately
- this encourages more insurance fund stakers (who require a medium horizon of insurance offering) to join during the high annualised cap inflow
Insurance Fund Stakers must adhere to the cooldown period for withdrawals (see ๏ปฟInsurance Fund Staking).
Spot Markets
Spot Markets allow for swaps between tokens and interest payments between depositors and borrowers. These token swaps and flow of interest are parameterised to allow fee collection for the revenue pool and thus ultimately insurance.
Within the program, its parameterised by the following in bold:
Field | Description |
total_if_factor | percentage of the borrow interest reserved for revenue pool |
user_if_factor | this proportion of total_if_factor is reserved for staked users (the other piece is reserved for the protocol itself) |
liquidation_if_factor | the proportion of liability transfer in liquidate_borrow that is sent to the revenue pool |
Thus the following must be true: user_if_factor <= total_if_factor. For example, if the total_if_factor is 100%, depositors would receive no interest from borrows. The following instructions interact w/ the insurance fund:
- resolve_borrow_bankruptcy
Perpetual Markets
Perpetual Markets are bootstrapped by the ๏ปฟDrift AMM which depending on market-making performance conditions can add and remove funds from the revenue pool.
Within the program, its parameterized by the following in bold:
Field | Description |
max_revenue_withdraw_per_period | the amm's max revenue pool draw per period (note this doesn't include bankruptcy resolution) |
revenue_withdraw_since_last_settle | revenue pool draws on behalf of user pnl since the last settle (note this doesn't include bankruptcy resolution) |
last_revenue_withdraw_ts | the last timestamp of a revenue withdraw (track in order to reset the period) |
A perpetual market's amm may draw up to max_revenue_withdraw_per_period from the revenue pool every period.
๏ปฟ
Additionally, for direct draws from the insurance fund, it parameterized by the following in bold:
Field | Description |
quote_settled_insurance | settled funds from the insurance fund since inception |
quote_max_insurance | max funds it can settle from insurance fund since inception |
unrealized_max_imbalance | max amount of pnl the net users can be owed within a market before: 1. draws from insurance are allowed 2. initial asset weights for this pnl gets discounted |
Unlike spot markets, perp markets are capped by the max draw from insurance via quote_max_insurance
quote_settled_insurance tracks the insurance fund draw amount since inception. Once this threshold is reached or the insurance fund is depleted, the market will then resort to the AMM ๏ปฟFee Pool. For any remaining losses not covered, the market will perform socialized losses in bankruptcy events.
The following instructions interact w/ the insurance fund:
- resolve_perp_pnl_deficit
- resolve_perp_bankruptcy
notes:
resolve_perp_pnl_deficit can only be resolved by insurance fund deposits (within the market's constraints), not by social loss with other users
