Overview
The BULL vault (the Vault) executes a principal-protected strategy on the Derive Exchange. The vault will borrow USDC against the native yield accrued on Vault-held assets which will then be used to purchase ETH call spreads to potentially boost the yield.
Orders are signed by a smart contract that validates:
[Principal Protected] The total Value of yield-bearing assets held by the vault never decreases below the principal.
[Fair Pricing] Calls bought and sold are sufficiently close to mark prices.
All trades are conducted on the Derive Exchange. In particular:
Buying call spreads will take place via RFQ
Selling the yield-bearing asset to payoff USDC debt and buying the yield-bearing asset with winnings from the spreads will be done on the Orderbook.
When the call spreads expire
If the spreads are in-the-money (ITM), the Vault will be paid out USDC. This will payoff some or all of the USDC debt (borrowed against the yield-bearing asset principal to buy call spreads). Any residual USDC will be swapped into the yield-bearing asset.
If the spreads are out-of-the-money (OTM), an equivalent amount of the yield-bearing asset is sold via the OB to pay off the USDC debt.
The call spreads bought target a 2.5x boost. This means that the
mark_priceof the spread divided by thestrike_rangewill be 0.4. E.g. if thestrike_rangeis $50, themark_priceof the spread will be targeted to be $20.Parameters
expiry(e.g. weekly),mark_price / strike_range: 2.5x
will be further refined given Vault performance.
Call Spread Strategy
Step by step:
The Vault will hold all users’ deposited assets and earns the yield native to this asset.
Each week, the Vault will compute the yield generated from holding the asset. The Vault will then borrow an equivalent amount of USDC from the protocol.
The USDC will then be used to purchase, say, weekly 65/35 delta call spreads on ETH. That is, the Vault will purchase weekly call options closest to 65 delta and sell weekly call options closest to 35 delta.
The calls expire after one week.
Payoffs:
The calls are ITM: the Vault will receive a USDC payout from the purchased spreads. If there is still outstanding USDC debt, then an equivalent amount of the yield-bearing asset will be sold to pay off the debt (leaving the vault with only the yield-bearing asset).
The calls are OTM: An equivalent amount of the yield-bearing asset is sold to pay off all USDC debt, leaving the vault with only the yield-bearing asset.
The new week begins and the Vault will sell the previous week’s accrued yield native to the asset (i.e. ignoring the possible call spread profits) to fund the next round of spread purchases.
Example:
The Vault holds $10,000 of sUSDe and, over the course of week 0, earns $33.70 of sUSDe interest (~17% APY).
At the start of week 1, The Vault will borrow $33.70 of USDC from the protocol.
The Vault will purchase 0.35 x of the 3,400/3,600 weekly call spread. See sUSDeBULL strategy for more detail.
If ETH increases and the vault earns, say, $70 (max payout) from the spreads, all $33.70 of debt will be paid off and the remaining $66.30 USDC will be converted to sUSDe via the OB. Over week 1, the $10,000 sUSDe principal could have earned $23.78 (~12% APY). At the start of week 2, $23.78 will be used to purchase the next round of spreads.
Smart Contract 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 sell amount of sUSDe against the vault’s balance and refuse 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. A complete list of contract safeguards will be added here shortly.