Maxi Execution

A technical explanation of how the Covered Put Spread Strategy executes

TLDR

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 RFQ Auction

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

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 put options at a price of $250), 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 as IP whitelisting of session keys, etc.

A Vault has to go through the same flow, except the session key 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 agains 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:

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.