Revenue Pool
A portion of the fees collected within the protocol (denomiated in a particular token: USDC, SOL, etc) go into that spot market's revenue pool.
The revenue pool is added to 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)
- revenue vault [TODO]
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 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 borrow interest reserved for revenue pool |
user_if_factor | this proportion of total_if_factor that is reserved for staked users (the other piece is reserved for the protocol itself) |
liquidation_if_factor | proportion of liability transfer in liquidate_borrow that is sent to 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 recieve no interest from borrows. The following instructions interact w/ the insurance fund:
- resolve_borrow_bankruptcy
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 peroid (note this doesnt include bankruptcy resolution) |
revenue_withdraw_since_last_settle | revenue pool draws on behalf of user pnl since last settle (note this doesnt 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 insurance fund since inception |
quote_max_insurance | max funds it can settle from insurance fund since inception U |
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 market 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 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 is can only be resolved by insurance fund deposits (within the market's constraints), not by social loss with other users
Potentially in the settlement from revenue pool a portion may go to a revenue vault
