Designing an Options Protocol from Scratch

Over the last year, there has been an explosion in the number of options protocols in DeFi. The first one, Opyn, launched on Feb 12 2020 and multiple other competitors quickly came onto the scene. These include Hegic, Primitive, Auctus, Pods, Siren, Charm, Premia, Potion, and so on. Each of these protocols have their differences, but due to their complexity, the differences are often hard to grok. This essay attempts to design an options protocol from scratch, by exploring the various axes that they can differ on, and their respective tradeoffs.

1. Minting & Collateral

The first question to consider when designing an options protocol is the following: how do we back the options contracts? Options contracts are contracts that give buyers the right, but not the obligation, to buy or sell some underlying asset. For an options contract to pay out, the contract must be backed by sufficient collateral. The most straightforward model here is to fully-back these contracts with collateral. For example, a $2000 ETH Call contract should be backed by 1 ETH, and at expiry, the Call contract buyer can exchange $2000 for that 1 ETH.

This is where many different protocols differ, with the broad goal of improving capital efficiency. As you should be able to notice, capital efficiency in this model above is terrible because the assets are sitting completely idle. Pods, for example, improves capital efficiency by using interest-bearing assets (cDAI, aUSDC) as collateral so that the capital sitting in the protocol is not completely idle. Other protocols may try to avoid being fully collateralized by having some liquidation mechanism in case the value of the collateral falls below some threshold.

The second axis by which the protocols differ here is the way that the capital is used to back the option contracts. The first model here is “individually backed” which means that each option contract is completely separated from each other. A $2000 and $1800 ETH Call Option are backed by two entirely different pools of capital. The second model is “pooled liquidity”, which means that all options are backed by a giant pool of capital. This means that if ETH is trading at $2500 and you are trying to exercise a $2000 Call or a $2100 Call, both options will get paid out from a single pool of capital. This model also means that options buyers can create any option with any strike/expiry, and have that option backed by this giant pool of capital. This is the model that Hegic employs.

The benefit of the first model is that options sellers can pick and choose which exact option they want to sell. However, because of this, liquidity also gets fragmented. The natural remedy for this is for the market to agree on a few specific strike prices so that buyers and sellers can aggregate their liquidity around a few specific options. This is how most options markets run in the real world as well. On the other hand, the benefit of the second model is that option buyers have superb flexibility, and can create/exercise any option with any strike or expiry against the pool. Naturally, the sellers in this model are the ones who do not have flexibility because they do not have the choice of which exact option they want to sell — only buyers do. They are just “passive capital” that needs to back the payouts of the option contracts at the end of the day.

The experience of the first model is like going to an exchange like Deribit. The exchange pre-defines which strikes/expiries are tradeable, and most of the liquidity will aggregate around a few specific options. On the other hand, the second model is like going to an OTC Desk and asking them to quote you a price for some option — you could ask for some really specific option that does not exist on an exchange (e.g $88888 BTC strike call option for next Thursday) and the OTC desk will quote you some price for it.

2. Pricing & Exchange

Now that we have figured out how to collateralize and create these options contracts on-chain, the next question is how to price and exchange them. The simplest model here is to tokenize the options contracts and have them trade on an order book. Using this model, buyers and sellers can discover and agree on prices through the bid/ask mechanism of the order book.

However, order books are terribly difficult to bootstrap, especially for options. Because there are so many different options contracts, market makers have to spread their capital across different products. Furthermore, there are very few market makers who have the expertise of pricing crypto options contracts as well as the technical chops to market make on decentralized exchanges. These problems lead to very illiquid option markets.

The natural solution to this is by using the AMM model for pricing and exchanging these options, because AMMs encourage passive participation from LPs and expands the amount of assets that are used for market making vastly. One of the most difficult problems here is that the Uniswap formula for pricing assets does not work well for options contracts. This blog post does a good job explaining why using a naive Uniswap pricing formula will create substantial impermanent loss for the liquidity providers. As a solution, many teams have decided to tackle this approach by creating custom AMMs to price the options. This is a fairly complex endeavour, and where most protocols differ. Teams have taken different approaches to this implementation, such as using approximations of Black-Scholes or other more radical/innovative pricing models.

Using these two axes (Minting/Collateral mechanism + Pricing/Exchange mechanism), we can come up with any options protocol that we dream of. For example:

  • Pooled funds + Black-Scholes pricing = Hegic
  • Individual options pool + yield-bearing collateral + Black-scholes AMM = Pods
  • Individual options pool + options-as-collateral (spreads) = Opyn v2
  • Individual options pool+ prediction-market pricing = Charm
  • Individual options pool + Kelly-criterion math = Potion
  • Pooled funds (multiple pools, not just 1) + Black-scholes pricing = Auctus

Conclusion

The current state of on-chain options is still very nascent, and many teams are innovating along the two major axes that I mentioned above. In my perspective, the “Golden Mean” of an on-chain options protocol should have the following features:

  • Pooled funds go into an on-chain options automated market maker
  • Simple mechanism for liquidity providers to park assets passively into this AMM. Must be able to automatically hedge their exposure, so that they are delta-neutral.
  • The “on-chain market maker” must be able to quote me a price instantly for any option that I want to buy or sell, and the market maker should be able to price any option
  • Simple way for me to trade against this market-maker, ideally through some token transfer that represents my position against the smart contract, so I can bring the option contract off the platform.

This will be a drastically better experience than trading on a CEX or on any of the current options protocols today. In theory, you should be able to long/short any option with any strike & expiry, just like how you can get most OTC desks to give you a price for (almost) any option. Pair this with a fast and cheap settlement system (Layer 2) + a mobile app, and you have the next decentralized Robinhood.