Options autohedging for Hegic LPs (Part 3):

10 min readApr 12, 2021


In February 2021 I spent some time thinking about: “How could Hegic Liquidity Providers (LPs) automatically hedge themselves in a centralized exchange (CEX)?” Now I’m back to finish what I started :)

Back then I decided to share with the Hegic community my notes about how to hedge Hegic LPs option risk profiles either by: (i) Hedging by trading the same option in the opposite direction (what I called “The Mirror Approach”) or (ii) Hedging by synthetically replicating the risk factors of the original position (what I called “The Aggregated Risk Factors Approach” or “ARFs Approach”). If you haven’t already read these 2 Medium posts, you can find them below:



The Mirror Approach has some important limitations (read Part 2 of my analysis, you lazy dog :)), which are the reason why I think the ARFs Approach would be more viable as a consistent long-term solution for all size of trades.

After writing Part 1 and 2, someone asked me: “Is The Mirror your favourite way to hedge Hegic LPs?” …No, it isn’t. This approach has some big limitations, most of them related to potential lack of liquidity in CEX to cover Hegic options (that is one of the reasons why Hegic is a game changer!!).

So here I am, let’s wrap this up.

Before reading this post, just note that I ran this analysis in mid February, and I’m writing a summary in April…so maybe the spot levels shown in my examples are a bit off :)

Problem to be solved: Hedge a portfolio of Hegic options using Delta 1 instruments (could be futures, but also other Delta 1s either in CEX or DEX).

Intro to ARF Approach: You aggregate your risk factors and you hedge those that you want to. In the current status of Hegic and even now that a secondary market is developing (good job, jmonteer), as far as the pool buying the options in secondary was a different one from this main pool, it would be ok to focus on hedging delta…hedging the intrinsic value of the option, ultimately.
So, in this case, you would look at the aggregated delta of the short options LPs have and hedge directly buying or selling futures.

For example, if the pool sells a call with delta 0.5 and sells a put with delta 0.3, the overall LPs delta would be -0.2 and you could just do 1 single trade, buying 0.2 futures. You could aggregate your short options by expiry and hedge each bucket with the corresponding future.

For more detail in pros and cons, go to Part 1: https://gammahamma.medium.com/options-autohedging-for-hegic-lps-part-1-fde4c7235fc7.

In my calcs, I have computed everything as if there was 1 single option in the portfolio (a call, actually) for simplicity. You can extrapolate this to a portfolio of options, as the only difference is that the greeks for the aggregated options would have to be calculated. In practice, calculating the greeks of a portfolio of options is very easy off-chain. Not so much on-chain, if you want to keep the computational work as low as possible.

Basics of the proposed solution: We will keep an “alive” dynamic hedge in the form of Delta 1 (futures, for example), that counterbalances the movements in the short options sold by LPs. Effectively, by doing this we are trying to isolate risks (think of risks as sources of return, also): we try to keep just the Implied Vol -Realized Vol spread.

In other words, we are trying that the LPs profit comes only from pricing options slightly more expensive than theoretical value, and not having that P&L subject to movements in the price of the underlying.

Now, it is important to notice that if we just hedged all the time non-stop, we would never make any money…we would be flat or most likely losing money due to: (i) being short gamma makes us buy the Delta 1 high and sell it low in each delta rebalance and (ii) transaction costs…we would just be tracking RV perfectly and paying a price for that.

I have come up with 2 simple ways of hedging using Delta 1. There are almost infinite ways to do this and I have prioritized simplicity and consistency here. The 1st way I explain is more “theoretical”, the 2nd one is how I would do this in practice.

Some important common points to both Way 1 and 2, and to the methodology for the simulations I will show later:

  • I built a model that takes into account Hegic pricing to know how much capital LPs receive from selling options (as that is the maximum amount they can use to hedge at t0)
  • The model also takes into account current spot, option strike, expiry
  • After several calcs, the model returns mark-to-market, total P&L and some other relevant outputs for the ARFs approach (buying/selling the Delta 1 and being short X option)
  • I used Black-Scholes greeks. I have worked a bit in some alternative greeks that are useful for Hegic as Hegic options don’t follow Black-Scholes, plus Black-Scholes is heavy computationally speaking. This could be pretty relevant for things such as jmonteer H2M at a portfolio valuation level, so I may put some more work on it…or may not.
    However, for the purpose of this analysis, it is ok to use Black-Scholes due to the fact that — as said before — In the current status of Hegic and even when a secondary market develops, as far as the pool buying the options
    in secondary was a different one from this main pool we are trying to hedge here, it would be ok to focus on hedging the “intrinsic value” of the option
Sneak peek: Hegic Call Delta for given days to maturity (Strike 1850)
  • I have built some big (these are actually quite huge) sensitivity tables for delta, gamma and theta where to check what those greeks are for different times to expiries and underlying prices
  • This works both for ETH and WBTC, I just change the spot ref and IV inputs and that’s it
  • I take the whole time to expiry and divide it in periods of X hours. In this way you can play around with “observation windows” (more on this later)
  • I calculate the Implied move in underlying (calculated from the IV vol) for the respective observation window and I also include a factor of “Potential realized move excess vs Expected move from Implied (x Times)” for anyone to able to check different scenarios in terms of realized vol vs implied vol
  • With that, I randomize the spot moves until expiry for each period
  • Once I have that, it is easy to know the option’s greeks for each period (or observation in each period, more precisely): I just go back to the sensitivity table and take delta, gamma, theta for that spot and time to expiry

Way 1 of hedging a portfolio of Hegic options buying or selling futures:

With this first way I hedge my delta at t0 and then at each observation window I check the option delta and my aggregated futures delta and rebalance always unless both deltas are exactly the same. In this way, we
manage to be most of the time very close to Delta 0 when aggregating the short option and the Delta 1.

What we achieve with this:
1. Expected return of the hedged portfolio is way more consistent than the expected return of the naked short option. Example in the first figure below.
2. The risk-adjusted returns are way better with the hedged portfolio, especially in times when realized volatility spikes (you can play around with vol levels in my model). With the hedged portfolio it is way more unlikely to lose money.
3. However, in low realized volatility environments the absolute “final realized P&L” will be most likely higher for the naked options (as most likely LPs have received a premium accounting for higher vol than
it actually realized). Example in the second figure below.

Figure 1: Mark-to-Market Comparison: Naked Calls Sold vs Hedged Portflio of Calls and Futures
Final realised P&L: Naked Calls Sold vs Hedged Portflio of Calls and Futures

Way 2 of hedging a portfolio of Hegic options buying or selling futures:

All the good points of Way 1 are qualitatively equal in Way 2. (Quantitatively, there are some differences though).
This second way is based on the same method, however, just as a traditional market maker would do, we will try to optimize (reduce in this case) the number of delta rebalances we make.

In practice this translates into: (i) lower number of transactions, more simplicity and above all, less transaction costs and (ii) we allow for some room for spot to go up and down and not “chase” every single movement.

Remember that when we delta rebalance we are getting more “flat” in terms or delta risk for the next observation window, BUT we are realising the loss (it could happen that if we don’t hedge just yet, spot went back to its previous level and delta hedging wouldn’t be necessary). Also remember that, on the other hand, you don’t want to leave your delta too “unhedged”, as a sudden move in spot could fuck your portfolio.

So the first obvious way to reduce the number of rebalances is to set up “broader” observation windows. Let’s say that instead of delta rebalancing every single time, we just evaluate if delta rebalancing every 6, 12 or even 24 hours. That’s the first decision to be made (for which it’s important to understand the trade-off explained in the previous paragraph).

Now, second way to reduce the number of rebalances, which is not so obvious: when you have a portfolio with a delta, gamma, and theta; your theta expected P&L can offset the delta and gamma P&L.

So, in plain words, if in an observation window the underlying moves just a bit, it is likely that the theta profit offsets the delta and gamma loss (remember, LPs are short options).

This is based on the formula decomposing an option’s expected price change = ΔS*Delta + ½*Gamma*ΔS² — Δt*Theta. Therefore, it could happen that if the delta is not perfectly hedged at the observation window (but it is pretty close) you decide not to rebalance your delta.

In order to model this, I make the delta rebalancing contingent on (Mark-to Market Naked Option + Mark-to-Market Delta 1) <0 for the given spot move and time passage. The mark too market of the naked option takes into account Delta, Gamma and Theta P&L. By doing this, we reduce the number of rebalancings by c.75% vs Way 1.

This has a positive effect in both factors previously discussed: (i) lower number of transactions, more simplicity and above all, less transaction costs and (ii) we allow for some room for spot to go up and down and not “chase” every single movement. See below the diference in the number of transactions:

Number of new futures bought in each observation window: Way 1
Number of new futures bought in each observation window: Way 2

Then, after all this, what I would do?

I would hedge using the ARFs approach, at least in the medium-long term (as we have already discussed, in the short term, we could use The Mirror Approach and it would work very well…but you already know my long term concerns about it if you have read Part 2).

Use the ARFs approach in Way 2, using observation windows of 6 hours. This provides, in my opinion, a good balance between checking quite frequently for changes in delta while avoiding rebalancing too much. It is like you “check frequently” how your risk is, but you don’t necessarily rebalance so frequently.

6 hours observation windows can perform worse than larger observation windows when realized vols are low (again, this is easily checkable in my model by playing with the observation windows and volatity levels), but it provides (i) very good consistency of results, (ii) better performance when vol spikes.

Lastly, one fancy tweak that can be done in addition to all this: when doing a delta rebalancing you could buy or sell c.75% of the Delta 1 amount necessary to rebalance in that precise moment, and do the rest in the following 3 hours (just taking the market’s price). This can help when the underlying is moving in a “revert to the mean” way, as you try to reduce the “buy high, sell low” effect of being short gamma + rebalancing.

I hope you find this useful. I’m happy to help anyone interested in hedging a portfolio of Hegic options. I’m also open to feedback, as nothing is perfect and I don’t expect my model nor this post to be perfect.

I will be back with some more interesting stuff around options and DeFi in general.





Ex-derivs sell-side @ IB. Derivs enthusiast. Crypto learner.