[Discussion] A Self-Underwriting Hedge Against ETH Price Drops


There are very few ways to hedge against rapid price drops in ETH without going outside the blockchain (and even then, probably not many). This instrument would provide users a native crypto instrument that is negatively correlated with the price of ETH.

ETA: As has been pointed out, this structure could also work with X being a strike above the current price level.

ETA-2 This has been revised to provide significant revenues for MakerDAO.


Users deposit into a risk pool, which pays out should the price of ETH drop below strike price X.

I propose that MakerDAO provide smart contracts to administer a way to pool risk. Users would deposit capital in the form of DAI (denoted as K) into the pool. At any time, they may withdraw their proportional share of the risk pool according to the formula of K * r. The variable r is the rate set by the pool’s contract that is <1. This would allow unrestricted retrieval of capital up to r at any time for any reason. As an example, if a user had deposited 1000 DAI and r was .9 then they could on demand withdraw 900 DAI.

Should the price of ETH drop to or below X, then users may withdraw 100% of their proportional share of the risk pool.

After an early withdrawal from the risk pool, a user’s remainder capital (1- K * r) is forfeited to the pool. This raises the payout both at the strike price and for early withdrawal for all remaining users. A portion of the forfeited capital would become equity for MakerDAO within the pool. Example: A user who deposited 100 DAI into the risk pool withdraws, taking 90 DAI with them and leaving 10 DAI in the pool – 9 DAI distributed proportionately to other participants and 1 DAI distributed to Maker’s share within the pool. If Maker had not had a share yet, it would then receive it. I envision Maker partaking in both the proportionate gains and this fee.

Expected Behavior Of Instrument

As the price of ETH rises, fewer users will be incentivized to seek protection from ETH falling to any given strike X and may even result in a net exit of users who decide to use their capital elsewhere. While the intrinsic value of a position in the risk pool becomes less valuable due to distance from X it increases over time as other users exit the pool. The longer the pool is in existence, the more valuable a position in it will become, making it a tool for speculation activity as well as those actually seeking protection against drop below a certain strike.

As the price of ETH falls, more users will be incentivized to seek protection by entering the pool. If strike X is met, then this slowly dilutes older risk pool participants while keeping their returns positive relative to initial investment. It also in some circumstances may allow users to exit early with K * r that is > than initial K, thereby receiving both a profit and increasing the available K within the pool to remaining users.

This would be structured as a semi-perpetual risk pool. It would hold no expiration, meaning its value would be quite high for sideways or slightly down markets over long periods of time, as the underlying share of each user rises with each exit. Even for the first user to exit, (1- K * r) can be thought of as the premium paid for the protection enjoyed for the length of time participating in the pool. So there is value even to the first user to exit the pool.

The pool would wind down in one of two ways: The first is if the strike price X is met according to our oracle OSM feed. The pool would allow all participants to withdraw a share proportional to their initial contribution (adjusted for users that exited and forfeited a portion of their capital)

The second way would be if the pool’s participation dropped below a certain number. If all users exited the pool – perhaps X is now astronomically below the current price of ETH – then there would be a remainder of funds, and could be rolled into the Surplus Buffer. In order to speed up the wind-down of obviously low-value, illiquid pools, it may be worth preventing exits from accruing to remaining users at a certain threshold – 20% of maximum number of participants, for example.

ETA: The pool could also have an expiration on a predetermined time and day, similar to options contracts. Any funds remaining could revert to the DAO. I fear there’s some way to game this I haven’t thought of, but would give us recurring revenue instead of irregular windfalls.

Why Maker Should Do This

There is definitely room to structure fees in this product. But I don’t think Maker needs to. Because all DAI originates with our protocol, denominating these pools in DAI will both increase the number of use cases within finance for DAI and make any DAI in the pool somewhat locked in place – meaning that most of those DAI are probably minted in a way that generates fees for us every moment they exist.

This gives us both a comparative cost advantage over, say, Uniswap, and also moves us into a use case for DAI that USDC and Tether simply cannot do unless someone else mimics the market.

There should be network effects to this becoming a deep, liquid market. Because strikes are at static, nominal points, as demand dictates and prices move, new pools can be created at higher/lower strikes.

Should we choose to do so, this is also a tool that we could use to hedge our exposure to ETH – which is considerable right now. The DAO as an institutional actor would also be well-positioned to wait out participants that prefer to actively put their funds to work and churn into and out of any given pool. But the contract should be structured such that the DAO receives any remainder funds in risk pools that become defunct without being exercised.

ETA-2 After input form others and further thought, I think this can generate significant revenues for MakerDAO. As outlined in the Summary section above, the DAO would gain some small amount of proportional share of each pool through exits. This could either be kept until a risk pool winds down from lack of participation, or even withdrawn from the pool (leaving behind 10% or whatever r we choose) at any time.

Risks To The DAO

The main ones I see are reputational and opportunity cost. The DAO would not need to underwrite the pools itself, though it may wish to participate. The main cost I see is the diversion of resources in both technical and marketing implementation vs our core lending business. Perhaps we could even contract out parts of the work, though that’s beyond my expertise to comment on.

How To Do This

I am not knowledgeable about smart contract technical details. But this seems like it would be a fairly simple structure and easily repeatable. It would require minimal tie-in to anything other than our oracle feed and depositing excess funds from defunct pools into the SB.

The initial challenge would be getting the word out, but I suspect an initial pool would be easy to populate with participants already familiar with DeFi and looking for yield and hedges. From there, if the initial pool(s) prove popular, new strikes can be added and perhaps even other assets. Note that it would require only a price feed and not that the actual asset be on-chain with Ethereum.

Feedback Requested!

Please leave your thoughts both technical and financial below.

Attn: @prose11 @iammeeoh @ElProgreso etc etc


Very nice protocol @PaperImperium !

I have some minor comments:

  1. The same identical protocol could be used upward to protect against price increases (e.g., of a gas cost index).
  2. Regarding “Why Maker Should Do This”, While such a protocol would indeed be beneficial to Maker, it seems to me that it does not leverage in any way our ability to print DAI. In this sense, we don’t have a strategical advantage when implementing this.

True but anybody could fork the project and denominate the pools in ETH, USDC or whatever. In fact it seems more reasonable to me to denominate it in ETH directly?

This seems a bit inefficient, perhaps, as it it dilutes the available liquidity across several pools? But perhaps it’s OK.
Another option might be to have several r-pool-tokens, representing share in the same pool but with a different exit value r<1.

  1. This is a rather clear and specific protocol description and I think it might indeed be useful for MakerDAO but, at the same time, I don’t think it can be currently considered as a primary objective. My feeling is that this could be a perfect thing to delegate to some 3rd-party developers using the incubator/grant system that the future SES core unit is developing (@juanjuan ?).

True, it doesn’t directly get DAI printed. I think, though, that we see how yield farming creates demand for DAI. The true synergy is just in getting DAI more steps removed from their origination. We are long time, so anything that provides a long-term incentive to keep DAI parked anywhere ultimately accrues to our bottom line unless that DAI came from a 0% SF vault.

They absolutely could. Or we could do that. But then we’d need to tie in liquidations to any remainder assets we were given. Presumably doable, but why not start with DAI?

As for doing it in ETH, I don’t think you’d want to do that for a pool hedging ETH exposure, though.

This is an issue in options markets. Whomever is running the exchange just has to do the best they can. Perhaps someone else has some special expertise here.

1 Like

Nice write-up and easy to understand your vision–which is pretty cool that you are thinking about hedging risk. I guess I will ask, why not just setup a Smart Contract that deposits DAI into Compound–take the interest earned + COMP token reward and uses that interest earn it to purchase Reinsurance via a Delaware Trust from Munich Re? Might be difficult as some of these reinsurance companies might not yet take crypto serious.

What about taking the interest earn and do some derivatives hedging via CME eth futures? You would probably need to setup a Trust as well.

What you describe in this write-up sort of reminds me of a CAT Bond–but maybe I misunderstood. But if similar to a CAT bond, should the self-underwriting hedge have a maturity of less than 24 months?


Good questions. Mostly I wanted less complexity in hopes people from Smart Contracts would be like, “yeah, we can make, test, and audit that in a week.” I’m a fan of minimum viable product + the fail fast/fail cheap mentality.

That said, I also wanted to keep us from being any interpretation of custodial or carrying a float of other people’s money on our balance sheet for fear of regulatory risk.

But lots of iterations could grow out of this kind of structure. A float that earned yield would make it a positive sum game, which would be nice.

To me, the benefit of @PaperImperium’s proposal is that the whole thing takes place on-chain trustlessly. The on-chain options market is currently lop-sided. It’s relatively easy to leverage long using Maker vaults, but there isn’t an obvious way to leverage short or build a put option. Opyn | Trade Options on Ethereum is one attempt, but I like the idea of non-expiring options. By making the option non-expiring, you save on lots of transaction fees and there should be more liquidity at various strikes.


I have revised the structure slightly to structure the risk pools such that they can generate significant revenue to MakerDAO without charging fees to participants who remain in the pool (under the “ETA-2” label in the text).

I also agree after more thought that non-expiring, perpetual contracts make more sense, to ensure liquidity in a sideways market where new strikes wouldn’t be needed, and to provide a better user experience. I fear an expiration similar to an options contract would make some users feel there was a rug pull, even if that was clearly communicated from the beginning. Also, an expiration would reduce the value of joining a pool over time, while a perpetual risk pool provides negative theta exposure, which should be attractive to participants who only want to worry about price of the asset.

Agreed also that this can/should be used for upward strike prices as well. But getting the short-hedged version out first would probably be easier to market until the product was up and running.

Aaaaaand… maybe we can use some of our newfound windfall to finance the development of this? Pretty please!

I would also like some input from someone with knowledge of smart contracts on how many person-weeks it would take (ballpark) to pursue this product. It’s easy to lay out the possible benefits, but I don’t have a good handle on even an estimation of the resources that would need to be diverted (@hexonaut et al).

1 Like

The mathematical notation could be improved. The variable K seems to mean at least three things: initial capital, current pool share as a proportion, and the notional withdrawal amount (pool share proportion times total value in pool).

1 Like

For sure. I typed it on my phone while chasing a toddler. Will clean it up when I have a chance.

1 Like

Moving tokens from the Foundation to the DAO doesn’t really do anything except settle a lot of political uncertainty. We had the money before and we still have it.

I wonder if dydx would be interested in a joint venture or just doing the whole project. dydx seems best positioned to take this project on given their Starkware collaboration for leveraged perpetuals. Or maybe there is room for both a L1 and L2 options market.