Partially Collateralized Options — Now in DeFi
Mechanism — Opyn partial collateralization
Why do we need a margin system?
One of the biggest limitations of DeFi options so far is how capitally intense they are to mint — users have been required to post 100% of the maximum loss as collateral.
In TradFi, an options minter and seller needs very little collateral compared to the maximum loss. This is one of the main reasons that options are such levered positions in TradFi derivative markets.
For our partial collateral launch at Opyn, our goal is to do much, much better than the current standard DeFi collateralization for options. Our target it to make sure that the margin is greater than the premium (not strike) of our option, which will be just a small fraction of the max loss in most cases.
Shocking the Premium
We need to make sure that we don’t use the current premium though — we need some buffer. We want to take what the premium would be if we were to experience a crisis (like Black Thursday) to make sure that option writers don’t walk away from their obligations.
We call this worst-case premium a “shock” premium. This “shock” premium is a lower bound on our margin (we wouldn’t want to be more aggressive because that’d be unsafe).
This is difficult because we assume no reliable oracle exists on-chain for the premium of the option, unlike what traditional options margin models assume (our system would be less robust but more margin-efficient if we did assume we had the oracle price of the option on-chain).
We instead only assume an oracle for the price of the underlying exists on-chain. This is a good assumption as options prices are much easier to manipulate than the prices of their underlying.
Unlike margin lending, like Compound or Maker, we instead must shock two variables — both the price of the underlying as well as the implied volatility because both spike during crises, and both can go against options writers.
An example:
The below put option is an example of how the new options margin will work. It’s a representative example because we’ve seen near at-the-money “weeklies” being extremely popular:
Thus, we must ensure that our margin requirement is above $540.00 to ensure that writers wouldn’t walk away from their obligations if Black Thursday were to happen again.
This implies 3.0x-3.6x more capital-efficiency, compared with 4.6x for Reg T.
We could go even more aggressive than 3.6x, but not without risk to the system. This is crypto, not boring stocks, so crazy shit happens and we have to be more conservative in our margin reqs! We want to make sure that writer would be underwater if Black Thursday were to happen again and the put price spiked before liquidations could execute.
How it works:
The margin for a put can be given by:
margin(Strike, ETH price, t) = P(t) * min(Strike, (1-SpotShock)*SpotPrice)+ max(Strike — (1-SpotShock)* SpotPrice, 0)
For our put:
margin(2000, 2050, 7 days) = .14 * min(2000, (1–0.25)*2050)+ max(2000 — (0.75 * 2050), 0) = $677.80
Here, t is the time to maturity. P(t) is a mapping with the shock values of ATM options with different maturities and SpotShock is how much we expect the underlying asset could move before a liquidation could occur.
High level mathematical intuition:
We want our margin to be greater than the premium of our option if ETH were to sell-off immediately and volatility were to spike, like on Black Thursday. In the long run, governance can decide what the shock IV and shock sell-off they are comfortable with.
P(t) is perhaps the most important part, as it is a mapping that takes in a time to expiry and outputs the premium of an at the money option with that maturity assuming our shock volatility. Since lookups are cheap from a gas perspective, we can add a number of key-value pairs representing number of days until expiry for ATM option, and its corresponding shock premium (in this case 7 days). This is our preferred solution amongst many we have considered.
The rest of the equation above uses the convexity property of options to linearly interpolate from the ATM option price to the relevant strike. That is, since the option has a convex price with respect to the underlying, we can draw a line from any two points on the price curve and the line would be above the curve everywhere. We draw a line between at-the-money premium and the premium if ETH were at zero (which is basically the strike of the put).
Note that our approximation is extremely computationally efficient and a pretty close approximation for the actual premium of different options:
We’ll be releasing a paper that goes more in depth, detailing the mathematical basis (w/ proofs) for partial collateralized options in the next few weeks.
How do we keep the margin system safe? Liquidations.
Remember from above that the collateral requirement must be strictly more than the value of the options minted, plus some buffer. For example, an option with a value of $7 might require $65 of collateral.
If the amount of collateral remains above $70, the user who minted the vault is safe. But, if the collateral gets less than $65, we are in the liquidation zone. If the collateral gets less than $7, we are in the insolvency zone.
In the liquidation zone, the collateral in someone’s vault is worth more than their obligations, i.e. the value of the options they have minted. Therefore, we can incentivize a rational liquidator to close this concerning vault on behalf of the user by offering them enough of the collateral in return for them burning options against the vault.
How does this process happen?
In Opyn v1, we used Compound-style liquidations, but this is way too punitive with options. This is because the minimum collateral required in the design above can be many times more than the value of the collateral. So, if we just require that a liquidator brings options in exchange for collateral, they can make very large profits on any capital they bring. Great for liquidators, but far too harsh for normal users who want to sell options.
So, we must use some market determined price discovery mechanism to liquidate each vault.
We could use a liquid AMM for this price discovery, but that would require a liquid AMM for options — which isn’t a solved problem yet!
Instead, our proposed price discovery mechanism for our option is an auction, inspired by Yield Protocol.
Yield-inspired Reverse Dutch Auction
High level: Protocol auctions off collateral of liquidatable vaults in exchange for all of the naked options that have been written from that vault. As time passes, it auctions off increasing amounts of the collateral. As in Yield, “collateral vaults can be bought whole, or partially,” as long as “more than Liquidations.DUST is left.”
Example for Opyn (made up numbers for ease of understanding):
Say 100 options have been written from a vault, and the margin required for each option is $10, but each option is worth $5, so $1000 margin is required total to cover options worth $500 total. However, let’s say only $700 of collateral is in the vault, so the vault is in the liquidation zone.
The system seizes the vault and tries to buy the options that were minted from the vault by offering some of the collateral in the vault in exchange for those options.
What our system will do is that it will first bid a very small amount of collateral for the 100 options, say $10 or $0.10 each. No one will execute this trade.
A bit later, Opyn’s bid will be $100. No one will execute this trade. This process will be done continuously on a per block basis.
Quite a while later, Opyn will raise its bid to $550. At this point, a liquidator might execute this trade, if not, someone will definitely shortly thereafter when Opyn raises its bid to $600+, assuming gas is less than $100, which might not be a fair assumption.
See how Opyn was able to liquidate at a relatively fair price despite not knowing the value of the options it needed to buy! This was because it used the auction as a price discovery mechanism.
Virtual Auction Commencement
One improvement we can make to Yield Protocol that is kind of counterintuitive — we can actually start the liquidation virtually on chain without any transaction.
Thus far, auction-based liquidations must be begun by a user — see “bite” in Maker. However, the person beginning the liquidation is usually a benevolent user, and this transaction needs to especially be called when there is a crash and gas prices are elevated.
The way this works is by using an oracle that has a reliable historical prices for the underlying asset. Our liquidation system is deterministic, meaning that at any block for every vault, there is an oracle price for the underlying that would trigger a liquidation, and that price is knowable and computable for every block at every price.
So, what we can do is that we can say that at any block, if the oracle is at such a price that it would cause a liquidation, a “virtual auction” begins. However, the contracts don’t realize that they’re in a state of auction — they need to be “told” later that they were retroactively in a state of auction.
The way this works — imagine that we’re in a virtual Reverse Dutch Auction for oTokens, and the liquidations method specifies that the protocol continues to bid $5 more every block for the oTokens it needs.
So, say that ETH hits $1500 at block A, and this causes a single vault to be underwater. A virtual auction is therefore begun — the way it works is that, if someone later can prove that at block A that vault was underwater by directing it to the relevant historical oracle price, and let’s say the current block is block A+10 (i.e. it’s been 10 blocks since A), then the user would be able to collect $5 * 10 = $50 for the oTokens. In this sense, the protocol was in an auction, increasing its offer price by $5 every block since the liquidation price was achieved, without requiring any transaction to formally begin the auction.
This historical oracle can be provided via a Chainlink roundId, a Uniswap historical twap, or some other oracle solution. Our system only needs to confirm that the timestamp of oracle price provided and ensure that it is within the time bounds of an auction. We propose that the initial implementation be via a Chainlink pricer contract which accepts a roundId for a particular asset. The Chainlink contracts can be queried for the relevant price and timestamp.
A user would have the ability to add collateral for a vault or prove that a vault is collateralized by paying gas to check the vault collateralization and update a timestamp on a vault. This could occur even if a virtual auction had started, as long as the vault hasn’t been liquidated (partially or fully). This vault timestamp acts as a check on the liquidator and any liquidation needs to have a oracle price with a timestamp after the timestamp of the last vault update/collateralization check. This has the benefit of allowing users to save their vault as the auction starts by acting quickly. It also has the ability of preventing transiently undercollateralized vaults from being liquidated.
Issues with Maker’s v1 liquidation mechanism: Dutch Auction for Collateral
Imagine we have 1 ETH, which is worth $1500, in a vault which has minted 1000 DAI. Say ETH falls to $1300 in price, and so we get liquidated because we violated Maker’s collateral requirement of 1.5x.
The Maker system wants to close this concerning vault. The liquidation auction begins in order to do this: in order to get DAI to burn in order to close the 1000 DAI debt the vault has, bids are requested on the amount of DAI a liquidator is willing to provide in an auction for the collateral. In the case that this auction reaches 100% of the outstanding DAI, the auction moves into a reverse dutch auction for the collateral where liquidators offer increasingly lower amounts of the collateral that they would accept in exchange for repaying the DAI debt. In the case that the first auction does not receive a offer on the entirety of the DAI debt, all of the vault collateral is won by the highest DAI bid.
If there is a liveness failure, and users aren’t able to have their liquidation transactions finalize on the blockchain, either due to gas fees or something else, it’s possible that the consequences could be catastrophic for system health. This is what happened on Black Thursday, when liquidators paid 0 DAI for $8.32 million in collateral due to delays in getting liquidations on chain.
Therefore, the system lost lots of collateral but didn’t reduce its DAI debt at all. This liquidation itself was extremely harmful for system health, and the Maker system would have been healthier if the liquidations never happened.
Opyn proposed mechanism: Reverse Dutch Auction for minted oTokens
Instead, in the event of a liveness failure for Opyn v2, where users aren’t able to have their transaction finalize on the blockchain, we don’t want an unhealthy liquidation to take place — we’d rather no liquidation take place than the one described above.
The way we do this is through a reverse dutch auction, highly similar to the one in Yield Protocol, with some extra tweaks
The vault will try to bid for the the oTokens that have been written against it. It will begin by offering a small amount of its collateral in exchange for all of the oTokens that have been written against it. If no one fills that offer, it will offer increasingly more collateral in exchange for all the oTokens, until it eventually offers all of its collateral.
If no one repays the debt, even for all of the collateral we can assume that the vault has reached a state of insolvency or that there has been a liveness failure.
Opyn research: margin system design by Zubin Koticha, Andrew Leone, Apoorva Koticha
A special thanks to to Dan Robinson, Dave White for comments and feedback on the mechanism design!
For further explanation of the margin system in v2, please feel free to jump into the Opyn Discord and ask us questions in #research!
