Skip to main content
Harvest Execution

A technical explanation of how the Derive Covered Call Strategy executes

Updated over a week ago

TLDR

  • The vault trades are executed on the Derive Exchange via the orderbook.

  • Orders are signed by a smart contract that validates that the total amount of options sold does not exceed the collateral position, that the limit prices are within a reasonable distance from the oracle marks, and more.

  • The execution is performed via “limit order auctions” - i.e. the vault sends out limit orders starting at a conservative price (e.g. equal to oracle mark) and progressively replaces the orders with more attractive prices until the desired amount of options is sold.

  • At option expiry, the vault will attempt to close out any USDC credit or debit by selling or buying its collateral using the same “limit order auction” mechanism.

  • The choice of options’ delta range and expiry will be subject to a backtest and liquidity considerations. Tentatively, the vault will be selling options in the 5-15 delta range, with 0DTE, 1DTE or 7DTE expiry.

Vault Positions Lifecycle

The vault positions go through the following stages:

1. Only Collateral

The vault launches with only its collateral. If the vault collects option premiums and cannot sell the received USDC into its 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).

2. Option Limit Order Auction

The vault begins to execute a “limit order auction” to sell options.

  • Select an option from the desired expiry and delta range.

    • The executor uses the orderbook API to find the option of the target DTE that is closest to its target delta

    • The signing smart contract will validate that the DTE and delta of the option are within range

  • Calculate desired_price for this option. This is based on the forward price and volatility feeds from Block Scholes, and uses Black76 formula.

  • Obtain a signature from the smart contract signer.

  • Send a sell limit order with the limit_price = desired_price and amount = number of LRTs.

  • Market makers or any other retail user can trade against this order via the UI or orderbook API.

  • Every second, recalculate desired_price using fresh feeds and add a small negative spread to the implied volatility, iv_spread = - iv_spread_per_sec x (now - auction_start_sec). The spread is capped at max_iv_spread, and the volatility has a floor of min_iv.

  • If desired price has changed by more than option_price_change_tolerance, cancel the old order, request a new signature, and send out a new order using the new desired_price and amount = number of LRTs - number of filled options.

  • Stop if number of filled options = number of LRTs.

  • Hard stop when (now - auction_start_sec) exceeds some max_option_auction_sec, e.g. 1 hour.

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.

4. Collateral Limit Order Auction

Note that if the option expired out-of-the-money, the vault will have positive USDC balance it acquired due from the premiums received in stage 2. If the option 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 underlying 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 smart contract signer.

  • 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.

  • 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.

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 sells 8 call options at a price of $12.5), both Alice and Bob must sign a messages 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 order’s amount against the collateral position the vault holds and refuses to generate a signature if the amount requested is too large. Similarly it will refuse to sign a price if that price is too far away from an oracle price. The set of validations that the signer will run are as follows:

  • Ensure option delta and expiry are within a certain range.

  • Ensure that at most one signed order can be open at any time.

  • Ensure that no option order can be signed if USDC balance is negative.

  • Ensure that the amount in the option order does not exceed its collateral position.

  • Ensure that the amount of the spot order does not exceed what’s required to clear the USDC balance.

  • Ensure the option limit price is higher than a threshold (calculated using oracle volatility and forward prices with a spread and a floor applied to the volatility).

  • 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 priced trades being placed. At the same time, the off-chain components of the strategy (such as being able to cancel an open order when the price moves to avoid being picked off) enhances the execution quality.

Did this answer your question?