TLDR

The vault trades are executed on the Derive Exchange via RFQs (Request for Quote).
The vault sends out an intention to sell a call spread (request) and receives back responses from market makers (quotes). The vault executes the best quote provided it's price is within the vault's desired range.
RFQ executions are signed by a smart contract that validates that the total amount of options sold does not exceed a % of the vault's TVL, that the quote prices are within a reasonable distance from the oracle marks, and more.
At option expiry, the vault will attempt to close out any USDC credit or debit by selling or buying its collateral on the Derive orderbook.
The vault only trades 7DTE expiries, and will select a spread that is closest to the target values. The target values are subject to adjustments if the asset price were to grow or fall significantly.

Vault Positions Lifecycle

The vault positions go through the following stages:

Stage 1 - Only Collateral

The vault launches with only its collateral and no positions. If the vault collects option premiums and cannot sell the received USDC into collateral due to low liquidity, the vault might also proceed to the next stage with a small amount of positive USDC balance (to be explained in stage 4).

Stage 2 - Option Limit Order Auction

The vault begins to execute a ''RFQ auction'' to sell spreads.

Select a call spread from the desired expiry s.t. it's mark price is close to the target price.
- The executor uses the orderbook API to find the spread of the target DTE that is closest to its target price.
- The signing smart contract will validate that the DTE and the mark price of the option are within target range.
Calculate desired_amount for this spread, equal to the amount of collateral held. Split this amount into smaller ''lots'' (e.g., split 4000 weETH worth of desired size into 10 lots of size 400). These lots will be executed consecutively.
Send a request-for-quote for this spread with size 400. Note that the RFQ automatically expires after 2 minutes and if not filled, a new one is sent.
Calculate desired_price for this call spread. This is based on the forward price and volatility feeds from Block Scholes, and uses Black76 formula.
Freeze for 15 seconds to allow market makers to send quotes.
Every second, recalculate desired_price using fresh feeds and scale it down by a factor. The desired_price thus gets progressively smaller until it hits a minimum after 2 minutes. The scaling factors equals 1/(1 + mark_spread) where mark_spread = min_since_lot_start * 0.5. In other words, after 2 minutes the vault's desired_price is 50% of the mark price.
Every second, compare the current best quote (across all market makers that sent them) to the desired_price. Note that the RFQ system is a blind auction, namely market makers do not know other market makers' quotes. This prevents them from colluding and / or naively bidding the vault's worst possible desired_price.
If the price of the best quote is higher than the desired_price, obtain a signature from the smart contract signer. If the transaction was successful, call the API to execute the quote.
Keep re-creating new lots until the full desired amount is filled. Note that each new lot's desired_price is reset to mark price and goes down to 50% of the mark price over the lot's 2 minute lifespan.

Stage 3 - Await Option Settlement

After the order is fully filled or the hard stop has been reached, the executor will sleep until the option is expired and settled. After a settlement has been confirmed, the executor proceeds to stage 4.

Stage 4 - Collateral Limit Order Auction

Note that if the spread expired out-of-the-money, the vault will have positive USDC balance it acquired due from the premiums received in stage 2. If the spread expired ITM, the USDC balance can be positive or negative depending on if the premiums were enough to cover the settlement loss.

The vault then begins to execute a ''limit order auction'' to buy or sell enough collateral to get rid of any USDC balance and bring itself back to Stage 1.

Calculate desired_price for the spot asset - this is based on the spot price oracle.
Calculate desired_amount = num of USDC / desired_price. For example, if the vault has $6,000 USDC and the LRT price is $3,000, the vault will attempt to buy 2 LRTs. Alternatively, if the vault has $30,000 USDC debt due to an option that expired ITM, it will attempt to sell 10 LRTs.
Obtain a signature from the signing smart contract.
Send a limit order with the limit_price = desired_price and amount = abs(desired_amount). The order is a buy order if desired_amount > 0, otherwise it's a sell order.
Every second, recalculate desired_price using fresh feeds and add a small spread to the price (if buying) or subtract the spread (if selling). The spread is calculated as spot_spread = spot_spread_per_sec x (now - auction_start_sec), subject to a max_spot_spread. It is applied as desired_price = (1 +/- spot_spread) x mark_spot.
If desired price has changed by more than spot_price_change_tolerance, cancel the old order, request a new signature, and send out a new order using the new desired_price and desired_amount = remaining num of USDC / desired_price.
Stop if desired_amount = 0.
If USDC balance is positive, hard stop when (now - auction_start_sec) exceeds some max_spot_auction_sec, e.g., 15 min. Note that it is possible for the auction to terminate and proceed back to stage 1 with some leftover USDC balance. If USDC balance is negative, the auction will continue indefinitely until the debt is repaid.
The vault may allow some negligible amount of USDC debt to be left in the subaccount (in case this amount is difficult to get rid of due to orderbook minimum size restrictions or temporary liquidity problems).

Smart Contract Strategy Mandate Enforcement

The subaccount owned by the vault is registered with the Derive Exchange in the same way as a regular user, with the core difference being in the way the order signing is performed.

Derive ensures full custody of users' funds by requiring (at a smart contract level) that any trade between two parties has messages signed by their session keys. A session key is just a separate private / public key pair that the user gives trading permissions by registering it with Derive's matching smart contract.

For example, in order for a trade between Alice and Bob to take place (e.g., to sell 8 call options at a price of $12.5), both Alice and Bob must sign a message where they agree for such a trade, and both messages will be validated by the matching smart contract. Only the Exchange is allowed to submit such messages to the smart contract, which allows for added layers of security such as IP whitelisting of session keys, etc.

A vault has to go through the same flow, except the session keys it uses are not just plain old private keys stored somewhere secretly. Instead, the vault's session key is a smart contract, and signatures are generated by calling this contract's function.

The contract will only generate a signature if a set of validations passes, for example, it will check the requested RFQ execution amount against the TVL of the vault and refuses to generate a signature if the amount requested is too large. Similarly it will refuse to sign the RFQ execution if that price is too far away from an oracle price. The set of validations that the signer will run are as follows:

Ensure spread's mark price and expiry are within a certain target range
Ensure that at most one signed execution can at any time
Ensure that no order can be signed if USDC balance is too negative
Ensure that the amount in the execution does not exceed a % of TVL
Ensure that the amount of the spot order does not exceed what's required to clear the USDC balance
Ensure the spread trade price is higher than a threshold (calculated using oracle mark volatility and forward prices, then scaled down by a factor)
Ensure that the spot limit price is within a range from the oracle mark price
Ensure that the order signature will expire in < 10 min

This set of rules guarantees that the vault executor cannot trade outside of the vault's strategy mandate, and it protects the vault shareholders from badly prices trades being placed. At the same time, the off-chain components of the strategy (e.g., being able to cancel an open spot order when the price moves to avoid being picked off) enhances the execution quality.

Harvest Execution

BULL Execution

Safe Harvest Strategy

Safe Harvest Risks

Maxi Execution