Building index-tracking assets on top of options instead of debt

Special thanks to Vladimir Novakovski, Curve developers, and others for feedback and review.

Suppose that you have some ticker T, which represents a price index denominated in ETH. For example, T could equal the USD/ETH price (ie. inverse of ETH/USD). Or CPI/ETH (aka CPI/USD * USD/ETH). Or the same for any other commodity. Or more exotic indices (eg. average rent prices in a city). You want to give users the ability to have exposure to T.

In simpler terms, your goal is to create something like a synthetic asset that tracks T , without relying on centralized issuers, on top of an ecosystem where the only “trustless” asset is ETH (or this could be applied to other trustless assets). The only trust dependency is an oracle, but oracles can be trust-minimized in a way that issuers cannot.

If you take T to be the USD/ETH price, this is basically the same problem as “algorithmic stablecoins”. But more generally, it’s perpetual futures.

All attempts at providing this functionality have to deal with a fundamental issue. The system as a whole can only hold ETH. Its assets and liabilities in T must add up to zero. So for every holder of positive-T, there must be a holder of the same quantity of negative-T. What happens if T rises so high that a holder of negative-T goes “bankrupt"?

In traditional algorithmic stablecoins, this is handled through forced liquidation.

For example, imagine that ETH is at $2500, and a user holds a position of (1 ETH, -2000 USD).

If the ETH price drops to 2000 (or realistically somewhat higher, to add a safety margin), the system must be able to “force-liquidate” the user: give anyone else the opportunity to send in 2000 USD, and collect the underlying 1 ETH, so that the system as a whole is not stuck hanging with an unbalanced debt of 2000 USD that is not sufficiently covered by collateral.

The problem with relying on liquidations is that liquidations depend on real-time oracles. You need a price oracle that is capable of giving a binding value for the ETH/USD price, and doing so in real time.

Real-time oracles are very hard to make safe. You can only rely on a limited number of actors, who are watching real-time signals in an automated way. You cannot use mechanisms that incorporate any notion of recourse. You cannot use what is by far the most effective technique to make a safe and cheap oracle: put a prediction market in front of a safe but expensive oracle, and only use that oracle in case of serious disagreement.

This post proposes to make synthetics rely only on “slow” oracles by flipping the problem on its head: we remove the entire concept of liquidations by making the “base building block” of the system options rather than debt. On top of that building block, you can then either build an index-tracking asset as a higher-level construct, or not bother with that at all, instead relying on users to re-balance on their own. Decoupling these two mechanics leads to much more stability and flexibility.

Synthetic options

Let us define two assets: P and N .

The parameters are: (i) ticker T , (ii) strike price S , (iii) maturity date M

A (P, N) pair can be generated at any time by splitting 1 ETH. Similarly, at any time you can combine P and N to get back 1 ETH.

At time M, the oracle is called, to determine the value of T. Let that value be x. Whenever the oracle resolves:

  • P receives min(1, S / x) ETH
  • N receives max(0, 1 - S / x) ETH

Notice that P + N = 1. Hence, there is no possibility of liquidation.

Also, for convenience, this is the same chart but denominated in USD:

One interesting property of this design is that it literally is “just” a prediction market, of a type that already exists and has been traded for years. See: scalar markets Scalar Markets | Seer

This means that this design will be able to share an oracle with prediction market systems, increasing its security.

How to use synthetic options

Imagine that the current price is 2500, and you, as a user, want to have a portfolio that has some level of exposure to USD. You buy some quantity of P1500, a P-asset whose strike price is far below 2500 (in this case, 1500). Is that sufficient?

Not quite. Even though today the price is far above 1500, there is a possibility that by the time the maturity date hits, the price will fall below 1500. The greater that risk gets, the further the USD-denominated value of P1500 drops below its maximum. In fact, it starts to diverge quadratically from 1 USD.

The graph looks something like this:

Notice that this is “just” a smoothed-out version of the above curve. How much smoothing there is depends on both how far the current price is from 1500, and on expectations of how much the price will move.

To see how this works, imagine that M is two weeks from now, and the current price is 1499. What is P1500 worth? it’s worth the possibility that the ETH/USD price will be above 1500 in two weeks. ETH is sometimes volatile; this could be quite a lot, or it could be little. eg. it could be $50. What if the current price goes down to 1399? The price of P would go down, but still it would not quite be zero, because there’s still a chance that it would go back above 1500 by the time M hits.

As ETH/USD goes far below 1500, the value of N approaches zero. As ETH/USD goes far above 1500, it approaches price - 1500 . And in the middle, it’s a smooth curve transitioning from one mode to the other.

The Black-Scholes equation is a formalization that attempts to estimate the correct price for P1500 (at least, in situations were the index T represents something that actually is some kind of price, and not something more exotic like, say, weather). However, since 2008, the Black-Scholes equation has become a byword for over-confidence in mathematical models leading to ruinous fragility, for good reason; so we should be careful to put too much faith in the details of the curve - at the very least because we don’t want to have yet another oracle that measures expected volatility, or skewness or kurtosis.

Instead, we should remember the following graph, which is the derivative of the last graph above. This tells you: at current price levels, how much ETH exposure do you have per unit of P1500?

Remember, as a P1500 holder, your goal is to “hold” USD and have no exposure to ETH. What this graph tells you is: the safe bet is to hold deep “in-the-money” options, and then rotate them into options with a lower strike price as soon as the price gets anywhere remotely close to the the strike price.

For example, you might follow an algorithm: if the current price is X, buy PS with S < X/2 and M 1-2 months in the future. If the price drops to below S * 1.5, then rotate out into PS’ with S’ < X/4 . Don’t hold anything to maturity, as that would give you exposure to ETH while the oracle resolves.

Rely on speculators and market makers to hold N and provide liquidity for you.

We can compare the properties of options-based synthetics and liquidation-based synthetics as follows:


Liquidation-based synthetics Options-based synthetics
Normal-case behavior Holding synthetic {asset}, no exposure to ETH Holding synthetic {asset}, no exposure to ETH
Extreme-case behavior Nothing, until you suddenly get liquidated Slow quadratically-growing deviation from your preferred exposure
Oracle dependence Real-time (greatly weakens achievable security) Long delays are acceptable
Vulnerability to temporary price spikes / drops Present by default, avoidable by being conservative on capital Less severe by default; depends on your personal rebalancing strategy

In both systems, there is some action that needs to happen in response to large price movements: in one case the protocol liquidating, in the other case users rebalancing. The key difference with options-based synthetics is that the user gets a choice of how do do this.

Rebalancing could be done via a fully-automated onchain DAO (note: fully-automated. All rules, no voting, no AI either). Such a DAO would be a “wrapper” around the options system, and that would provide the “stablecoin”. Alternatively, users could choose when to rebalance locally, using a daemon on their own device to do this.

By moving the decision point of “when to {liquidate / rebalance}” from an onchain gadget to the user, we get two advantages:

  1. Reduce the user’s MEV risks, because the transaction is not visible ahead of time
  2. Remove dependence on a global canonical oracle. Users would still have to depend on oracles that have faster response time than eg. two weeks, but the user could hide which oracle they use (eg. their locally running agent queries a dozen financial news sites, no one else knows which ones, and takes the median). This helps protect the system from oracle attack

The main choice that the user has is over timing and thresholds. If the user rebalances frequently, they become more vulnerable to adversarial short-term price movements. If a user rebalances conservatively, they get more quadratic drift.

I would argue that simply accepting a medium amount of quadratic drift (eg. standev ~1-4% per year) is underrated. The cost is definitely significant. It’s unintuitive, and it makes this design unusable as an “accounting stablecoin” (ie. being able to “pretend it’s USD” to people you send and receive it from, or capital gains tax authorities).

However, it makes much more sense, if you view it not in the context of “I want simulated USD”, but rather in the context of “I want price stability” (ie. ability to pay a known quantity of one’s own future expenses). Fiat currencies move much more than 1-4% per year against each other. Each individual person or business’s expected future expenditure has much more than 1-4% per year volatility denominated in their local fiat. Also, the equilibrium return rate of an algorithmic stablecoin (eg. RAI) also regularly moves by roughly as much.

An important decision to make is: even if you rebalance conservatively, what is the market mechanism by which rebalancing happens? It is very easy to lose 2% per year or more from multiple rounds of slippage, and this is the largest risk by which this whole scheme might become uncompetitive.

Fortunately, a user’s time preference will almost always be very low. Users do not care if they rebalance today or tomorrow or three days from now. We should take advantage of this to figure out an ideal market structure that minimizes slippage far more than traditional AMMs do. Rebalancing would be more like one-sided market making than like making an instant sell.

16 Likes

Very interesting post, thank you!

I have some thoughts:

Options versus Debt:

I would argue that simply accepting a medium amount of quadratic drift (eg. standev ~1-4% per year) is underrated. The cost is definitely significant. It’s unintuitive, and it makes this design unusable as an “accounting stablecoin” (ie. being able to “pretend it’s USD” to people you send and receive it from, or capital gains tax authorities).

I think the main difference you were pointing towards regarding the liquidation-based model compared to the options-based model is the fact that, at least in the context of exposure to the underlying asset, debt has this property of giving you “simulated USD” (100% exposure) right up until liquidation, whereas options’ underlying exposure drifts quadratically from 100% (which is unachievable) exposure. The underlying problem though is that the synthetic tracking the underlying asset in the options case will still be “liquidated” metaphorically as the exposure trends towards 0; the question then becomes whether the market for options could ever be deep enough that the strike prices fall to a point where the risk of quadratic drift is actually lower than the risk of liquidation in the debt model.

All attempts at providing this functionality have to deal with a fundamental issue. The system as a whole can only hold ETH. Its assets and liabilities in T must add up to zero. So for every holder of positive-T, there must be a holder of the same quantity of negative-T. What happens if T rises so high that a holder of negative-T goes “bankrupt"?

Generally being on the sell-side of a perpetual will always have this requirement of having to actually have the underlying asset at hand for future “delivery,” as in the case of futures, or similarly having to actually buy back a security later in a short sale. In DeFi since we can’t rely on institutional trust we basically end up constantly forcing the user to “buy back” the value of the underlying asset in real time; really options have this same property, except that instead of having the user post realtime collateral to ensure 100% exposure, you decrease their exposure quadratically to obviate the need to rebalance. The user-side still incorporates this risk of a lack of exposure to the borrowed asset under extreme volatility though.

This post proposes to make synthetics rely only on “slow” oracles by flipping the problem on its head: we remove the entire concept of liquidations by making the “base building block” of the system options rather than debt.

To me the benefit of oracle security and simplicity is much more valuable than the underlying economics to the user; the fact that you can rely on “slow oracles,” as you call them, has huge benefits to security, and as you mentioned is basically analogous to a prediction market. I actually think this is extremely cool, as it lets people manage their finances as a permutation of prediction-market bets tracking underlying consumption goods, and since stable savings are really only ever ephemeral for the intelligent investor who keeps their wealth in actual assets, the quadratic drift becomes less of an issue as most users will likely be rebalancing their exposure to consumer goods every month or two to match their own market behavior anyway. Actually this idea is worth more discussion so I’ll talk about it more at the end of this post.

Potential Improvements

However, it makes much more sense, if you view it not in the context of “I want simulated USD”, but rather in the context of “I want price stability” (ie. ability to pay a known quantity of one’s own future expenses).

I do think this model is superior to the debt model for those who seek stability rather than underlying “simulation” as you called it; I’d much rather live in a world where everybody uses ether as a rule, but purchases their own basket of “stability contracts,” than live in a world where virtually nobody uses ether and holds “stability units,” as the widespread use of units of account exogenous to the protocol open it up to all kinds of unhealthy relationships with —mostly negative these days— geopolitical developments.

I also think the underlying options-based synthetics can be optimized for greater efficiency regarding exposure to the underlying asset. For example, it’s worth considering whether the strike price could be made dynamic to accommodate volatility; the irony of the current model is that actually the options are more efficient the lower the volatility (higher the stability) of the asset the user wishes to hedge against, which is precisely the opposite of the desired effect. In other words, there’s less of an incentive to hold the synthetic that gives you exposure to USD if ether is stable, but the synthetic is better at giving you exposure to USD the more stable ether is (due to the lower likelihood of drift close to the strike price).

Remember, as a P1500 holder, your goal is to “hold” USD and have no exposure to ETH. What this graph tells you is: the safe bet is to hold deep “in-the-money” options, and then rotate them into options with a lower strike price as soon as the price gets anywhere remotely close to the the strike price.

As shown by the derivative of the nominal exposure graph, the quadratic drift effect means that actually the deeper in-the-money the (P, N) option is, the more the marginal decrease in value of P corresponds to a relative increase in units of ether to offset the value lost; on the opposite end of the spectrum, an out-of-money options means that the marginal decrease in value of P actually corresponds to far less of a relative increase in units of ether to offset the loss (more exposure/less hedging). This is also true of the holder of the N-side of the option: in-the-money, a marginal increase in N corresponds to less of an increase in in units of ether (worse leverage), and out-of-the money the marginal increase in value corresponds to a relatively larger increase in units of ether. Since the P-side desires stability, they are in pursuit of the deepest in-the-money option that maximizes the offsetting of their losses; the N-side of the option, however, is the speculator who is in pursuit of leverage, so their optimal option is sufficiently out-of-the-money to the extent that each marginal increase in value actually gives them more units of ether —analogous to leverage on the upside of the underlying asset.

A dynamic strike price would allow both parties to minimize their exposure to the extreme-case of quadratic drift by trading a marginal amount of their beneficial “away-from-the-money” (either in or out) region for less drift at the extreme end (the other side of the money). For example, if the strike price was actually ± (depending on the side of the money the option is currently on) the square root of the difference between the strike price and the current price, you’d dampen out the extreme-end risk for both parties in exchange for marginally worse best-case returns.

Modular and Composable Stablecoins as Homogeneous Monetary Goods

Suppose that you have some ticker T, which represents a price index denominated in ETH. For example, T could equal the USD/ETH price (ie. inverse of ETH/USD). Or CPI/ETH (aka CPI/USD * USD/ETH). Or the same for any other commodity. Or more exotic indices (eg. average rent prices in a city). You want to give users the ability to have exposure to T.

The idea of creating a market for economic goods (through the use of derivatives) in order to simulate a set of homogeneous modular and composable stablecoins is absolutely remarkable to me. This would be the theoretically optimal form of money as it would allow individual economic agents to actually compose their own stores of value relative to their own consumption in the market. Here’s the thought experiment that led me to this conclusion:

Allow me to make an analogy from thermodynamics (thermodynamics seems to be gaining popularity as a medium to make deep philosophical analogies): it’s common knowledge that a gas will expand in volume to fill whatever container it is in; if you change the shape of the container, the gas will maneuver to fill the gaps; if you add more gas, it will spread out to reach volumetric equilibrium.

I claim that money is just monetary gas filling an N-dimensional container, where N is the number of economic goods available for purchase in the economy; if you add more money to this container (the economy) it will spread out to reach equilibrium relative to the aggregate demand of each individual good N; if you change the shape of the container (change prices/demand or add more goods), the money will move to fill the gaps to reach the same equilibrium of prices.

Note that by the efficient market hypothesis, this notion of equilibrium is only increasingly true, and never completely. In this analogy, if you take N coordinates within the container’s N-dimensional coordinate space, you have a personalized stablecoin that represents unique exposure to a set of desired economic goods. The entire container is a modular and composable stablecoin system that lets users pick their own coordinates of exposure relative to their own spending habits (i.e what is the optimal store-of-value for them) relative to their actual consumption needs into the future.

This is a vastly superior means of storing value than the current model where we use a ‘one size fits all’ catch-all unit of denomination such as the dollar, or prospectively, ether. These monies here for example would be represented by the “top right” of this N-dimensional economic container, or in other words, the aggregate of everything.

I wrote about this further in this research post if you’re interested; I really think the future of currency isn’t a currency at all, but a modular and composable market for homogenized economic goods.

I might be too smooth-brained, but I don’t really understand how this enables tracking arbitrary assets.

Working out examples given my understanding:

Let’s pick T=NVDA, the price of Nvidia stock. Let’s assume for the sake of simplicity, that 1 NVDA = 1 ETH.

Example 1: S = 1ETH (at the money option).

  • At expiry, if 1 NVDA <= 1 ETH, P = 1 ETH, N = 0.
  • At expiry, if 1 NVDA = 2ETH, P = 0.5 ETH, N = 0.5 ETH.
  • At expiry, if 1 NVDA = 4ETH, P= 0.25ETH, N = 0.75ETH.

Example 2: S = 0.5 ETH (far in the money option)

  • At expiry, if 1 NVDA <= 0.5 ETH, P = 1ETH, N = 0.
  • At expiry, if 1 NVDA = 1 ETH, P = 0.5 ETH, N = 0.5.
  • At expiry, if 1 NVDA = 2ETH, P = 0.25 ETH, N = 0.75 ETH.
  • At expiry, if 1 NVDA = 4ETH, P= 0.125 ETH, N = 0.875 ETH.

P tracks NVDA/ETH pretty well but only in reverse:

  • it is directionally short
  • it is capped on the NVDA/ETH down direction by the strike price
    - max multiplier is S/CP (CP = current price)
    - so only far out of the money (e.g S = 4 ETH for a max 4 multiplier) gives appropriate tracking

Nothing tracks NVDA/ETH close to linearly in the long direction, no matter how far out in/out the money, which I reckon is what people would be most interested in.

Am I missing something important here?

I wonder if one the main issue is that there isn’t actually any NVDA in the system, so when NVDA/ETH increases, there is no gain in the system, only redistribution of a fixed pie. (A ETH covered call option doesn’t have that issue.)

2 Likes

The examples you gave are relatively undesirable since they’re extremely “close to the money.” The person on the “sell-side” hedging against the base asset (NVDA in this case) benefits more the deeper in-the-money the option is, while the “buy-side” individual leveraging the base asset benefits more from the option being deep out-of-the-money.

This means there’s a tug-of-war in the market between a lower and higher strike price. You’d expect if ether is the base asset for most pairs, more demand for leveraged ether would mean lower strike prices and higher efficiency for hedging against ether (I think empirically it’s clear there’s plenty of demand for leveraged ether). In other words, the system is increasingly efficient depending on the demand for the base asset.

it is capped on the NVDA/ETH down direction by the strike price

It’s actually equally inefficient on both ends of the money depending on whether you’re leveraging or hedging against the base asset. It’s also worth noting that the actual real value in the market of the option will trade higher or lower to it’s redemption value at maturity since there’s still uncertainty surrounding which direction the underlying prices will go; this uncertainty decreases as the maturity date approaches, but if you’re holding an option with a maturity date far in the future you could reasonably expect the option to trade higher than 0 ETH even if the price of the base asset is below the strike price, since the price of the option would incorporate the fact that it could potentially rise above it before the maturity date.

Nothing tracks NVDA/ETH close to linearly in the long direction, no matter how far out in/out the money, which I reckon is what people would be most interested in.

The utility of something like this is that it provides cheap (in the sense of actually securing and operating the system) hedging against ether without needing to use actual reserve-backed stablecoins. Even if the system is relatively inefficient, as an aggregate it could still find its use-case as a means of targeting the stability of a basket of goods at a reasonable correlation.

To summarize: you are correct in the examples you gave but it’s worth debating where exactly the strike price might land in the market, but also the efficiency of hedging or correlating to a base asset doesn’t necessarily need to be perfect to have value.

I almost fell off my chair reading your post on X, since I have been working on a closely related problem, with some subtle but important differences, for almost 5 years.

The way I like to frame P + N = 1 is that we change the “contract” between traders and LPs. Instead of creating a strict USD liability that has to be defended by liquidation, we let the payoff itself absorb the stress. The system stays fully collateralized because the two sides are always just splitting the same collateral.

In your construction this is done with expiring option-like claims:

P + N = 1

and at maturity:

P = min(1, S/x)

N = max(0, 1 - S/x)

That removes the need for liquidation and allows much slower oracle assumptions. But as you point out, the cost shows up elsewhere: rebalancing, slippage, expiry management, and tracking drift.

A novel approach

I would like to propose a closely related construction. It follows the same spirit as OP, but replaces expiring options with a perpetual liquidity-backed payoff.

Let x be the ETH/USD price. Let l be the target leverage, and let y be what I call the saturation price. Unlike the strike S in the option construction, y is not a price where one side expires worthless. It is the boundary between the convex zone and the saturation zone.

Define the trader side P, denominated as a share of the ETH collateral reserve, as:

P = (1/l) (x/y)^(l-1) when x <= y

P = 1 - ((l-1)/l) (y/x) when x >= y

and as before:

P + N = 1

Here P is the pooled trader side going long ETH/USD, and N is the LP side. Notice that 0 <= P <= 1. Also, neither side is wiped out at an ordinary strike. P goes to 0 only as ETH/USD goes to 0, and P goes to 1 only as ETH/USD goes to infinity.

At x = y: P = 1/l

and therefore: N = (l-1)/l

So the saturation price is the point where:

N = (l-1)P

In other words, it is the point where the LP side is exactly large enough to support leverage l.

Convex zone

For x <= y, the trader side follows a power-law payoff:

P'/P = (x'/x)^(l-1)

Since P is denominated in ETH collateral units, the USD value of the trader side scales as:

(x'/x)^l

So while the vault remains under saturation, the trader gets the path-independent payoff of constant leverage. There is no liquidation and no volatility decay in this region. Profitability depends only on the entry price, the exit price, and the upfront fee.

This is the region I call the convex zone. It is the payoff we would ideally want from constant leverage if it could be maintained perfectly without liquidations.

Saturation zone

For x >= y, the payoff becomes:

P = 1 - ((l-1)/l) (y/x)

so:

N = ((l-1)/l) (y/x)

This means the LP side is fixed in USD terms:

N * x = ((l-1)/l) y

So above saturation, LPs are no longer providing additional convexity. Their claim becomes fixed in the quote asset, and traders receive the residual ETH upside. This resembles a feeless margin trade or perp-like position.

This is where the system has run out of unused LP inventory. The position does not liquidate, but the payoff is no longer the ideal power payoff. Above saturation, returns become path-dependent and volatility decay can appear.

Oracle tradeoff

Your approach maximizes oracle safety. Because settlement happens at maturity, the oracle can be slow and dispute-friendly. The cost is that users or wrappers have to roll options and rebalance across strikes and maturities.

This construction makes a different tradeoff. It is perpetual and users can mint/burn continuously, so it needs an oracle for accounting. But because there are no liquidations, the oracle is not deciding when to forcibly close positions. It is only used for minting, burning, and reserve accounting.

That makes slower TWAPs much more acceptable, especially for deep pairs like ETH/USD. A manipulated oracle can still create bad entry or exit terms, but it does not trigger a liquidation cascade.

In the implementation I have been working on, SIR, this is done with Uniswap v3-style TWAPs, fee-tier selection by liquidity, and price truncation against multi-block manipulation.

Best-effort convexity

The protocol does not promise infinite free convexity.

As more traders enter, P grows relative to N. This pushes the saturation price y downward, which shrinks the convex zone. In other words, the more demand there is for convexity, the less convexity the vault can offer at the margin.

That is the self-balancing part. LPs are not forced to sell unlimited perpetual optionality at a fixed price. The payoff degrades when LP depth is insufficient.

So I think the two constructions are very close in spirit, but make different choices around expiry.

Your design gets the strongest slow-oracle guarantees by settling at maturity. The tradeoff is rolling, rebalancing, and expiry management.

This construction gives up some of that oracle purity in exchange for perpetual positions, continuous mint/burn, no expiry, no ongoing funding fee, and path-independent leverage as long as the vault remains below saturation.

The failure mode is also different. In the option construction, the cost shows up through tracking drift and rebalancing slippage. Here it shows up through LP-depth constraints: once the vault saturates, convexity degrades instead of pretending the system can provide unlimited constant leverage.

For context, this is live already. I can share Dune charts of our synthetic assets by DM or other information if interested.

3 Likes

Taking your example with ETH and P_1500, I think your proposal can be summarised as holding a deep out-of-the-money (OTM)[1] put option on ETH as an alternative to a stablecoin. You have analysed the delta, the sensitivity of the OTM put’s price to the price of ETH, and shown that it’s fairly low.

However, you should also analyse the derivative of the put’s price with respect to time (“theta”), which is where you’ll see that there is a problem. The theta is negative, meaning that all else equal, the value of the put option goes down over time. If you estimate it with Black-Scholes, you’ll find that it’s actually very costly to hold this put: for example a 1 year put with ETH-USD at 2500 and the strike at 1500, assuming a conservative implied volatility of 50% will lose around 0.40-0.50% per day in value, which translates to losing most of your money in the long run in most cases. Of course for the option to be fairly priced, holding the put will actually pay off very positively in some rare occasions, but in most cases goes to 0. I think this makes it a poor choice for a stable store of value.

[1] - at one point you use the term “in-the-money” but based on the context I think you meant “out-of-the-money”

1 Like

Agreed it is correlated with the assets in some way, and as pointed out does not need real-time oracle resolution.

Although I do question the appetite for it. Traditional options (which also have these characteristics for onchain assets like ETH) have not taken off (vs perps or even offchain crypto options) despite being instruments that are both simpler than this and very flexible.

1 Like

The biggest application to me is modular and composable stablecoin systems based on baskets of economic goods weighted by personalized consumer-behaviour on a person-to-person basis.

See my own post on this:

1 Like

This is a design space I’ve been exploring for a long time, very happy to see others noticing it! I have a lot of thoughts on the topic.

Benefits

Let me summarize the benefits of the “options” class of designs:

  • much safer for borrowers, immune to momentary oracle (and price!) manipulation; with very little compromise from lenders
  • soundness (the instrument is well-defined, no circular definition like in perps or “algo-stables”)
  • no assumptions about how the price moves are made –> no “instrument failure” modes like bad debt
  • the ability to express your own opinion about the price/safety (for synthetics: in the happy path)

One important note is that liquidations do NOT protect against a price breakdown. They are a mere heuristic on how to “evolve“ the strike price of a continuously-rolling short option users have on the underlying asset (note: rolling happens not for a constant number of instruments, instead number of shorts * strike price is kept constant). If the call option holders did not give sufficient collateral for an increasing number of short puts they need to underwrite, their position is wound down. The wind-down assumes some short-put-holders (P holders) are willing to close their position, which is very handwavy. Consider a case where the collateral’s price instantaneously falls to 20% of its initial value. Both options and debt respond in the same way.

Options

First of all, if the asset already exists on chain, one can replicate its payoff by creating a covered option with exactly the payoff described. The options’ notional can be orders of magnitude larger than the underlying asset, since it is only used in settlement, which doesn’t happen in the happy path (rolling is preferred). No oracle is needed in any case.

Simple sound options

Note that in covered options (from first principles), it is impossible to replicate a short call payoff. This is why I propose to call the short put payoff simply a “short option”. Note that a short option does NOT have a negative delta, “short”ing comes from selling the option.

asset = call + short

numeraire = put + short

The transition can be done both ways before expiry. This rule already implements option exercise (call-put parity on spot):

call + numeraire = call + (short + put) = (call + short) + put = asset + put


which means that the call enabled us to swap numeraire for speculative – which is the exercise. We also got an analogous put (the right to undo the call exercise before maturity).

At expiry, puts and calls turn worthless, while the remaining collateral (left from deposits + exercises) is redeemable by short option holders – their payoff says they need to be fine with either asset; receiving the wrong one can only make them happier according to their perceived price. The proof that there is enough collateral is left as a quick exercise to the reader.

I call this design “sound options”.

Sound options

The above design can be generalized to arbitrary nonnegative payoff functions, while preserving oraclelessness (every participant can have a different perception of the price and will be happy with the result).

You can see more details on my talk from ETH Warsaw 2025 (recommend setting the time 1.5x)

The point is, it’s possible to oraclelessly & efficiently implement any strategies like bull spreads, which enable risk stratification for these setups.

For synthetic setups, enabling risk stratification is trivial.

Oracleless design

There is an oracleless design alternative I played with – if untrusted assets of the desired denomination are on chain. The assumptions are as follows:

  • the collateral asset (e.g. ETH) won’t decrease in value too drastically
  • there are some handwavy versions of the “bridged” asset we want to replicate
  • at least one of these assets will hold its value for a certain short period of time (e.g. 1 day)
  • none of the bridged replicated assets will rise above the value of the replicated asset

Let’s also define the “multi-asset option“, where a certain set of assets in preset amounts are needed to mint multi-asset-call and multi-asset-short and by expiry, the multi-asset-call owners have to claim one of the assets. After expiry, multi-asset-short options are redeemable for the remaining assets.

Note that with our assumptions, the multi-asset-call replicates the synthetic’s value! But it’s incredibly inefficient – it requires all handwavy synthetic assets to be deposited for the whole duration – making the risks huge for providing security.

Now, consider typical covered call options on the collateral (e.g. ETH) as the asset and multi-asset-call as the numeraire. Let the expiry of the option be e.g. 1 day before the expiry of the underlying multi-asset option.

Short options here very well replicate the desired synthetic payoff.

Note:

  • in the happy path, calls (N holders) and shorts (P holders) agree on the price and roll the expiries or exit the positions simultaneously
  • if they don’t agree on the fair value, settlement is triggered:
    • first, calls (N holders) have the right to buy their ETH back for numeraire – multi-asset-call. Only here, for settlement, they deposit all “handwavy tokens“ to create multi-asset calls and shorts.
    • secondly, the shorts (P holders) have a short timeframe to choose which of the assets they want to receive – giving them strong guarantees, while keeping the time assets are needed low
    • lastly, the N holders claim back the remaining “handwavy tokens”

Of course, this design is still vulnerable to the price of the collateral decreasing.

Note that it can be made more efficient where the P holders choose the asset they want first, and then N holders must give it to receive their collateral back.

It’s a really cool showcase on what composability can enable, this is what I’m working on at blueprints.finance.

One-time oracle

Oracles which push values one after the other are mostly useful for answering the question “should someone be liquidated?“, rather than settling derivatives. For derivatives, only a single response is ever needed. This response doesn’t need to come at any specific time and the design should allow lazy settlement – where settlement is independent of subjective chain availability. It’s fine for oracles (or users in “pull” designs) to push the result only when it’s needed and answer a customizable query. (this is how Touchmarket positions are settled)

On function representations

As mentioned earlier, it may be useful to stratify the risk. It’s useful to generalize the function set to piecewise f(x) = ax^{-1} + b + cx. This way, one can implement tranching (solving situations like when a user seeking stability wants a $1500 strike while a speculator wants a $1750 strike) and neutrality towards price inversion (f(x^{-1}) is representable in the above format iff f(x) is representable).

Of course, the latter property may be a yacht problem in terms of actual implementations.

Things like power-derivatives can be implemented by just changing this representation or generalizing it to f(x) = \sum_{k \in K} a_k x^k, for a given choice of the set K.

The design space as perps

Perps can be seen as a basket of payoffs (futures), well defined here.

The problem with perps is that as a trader you’re forced into rolling for whatever price the market (the oracle!) determines (funding), rather than choosing whether you want to roll yourself. This makes perps depend on the price of themselves, creating a circular dependency. Traders can be forced into paying whatever others (in total) determine, which incentivizes extractive behavior/cornering. For this reason, I consider perps unsound. This design fixes it.


Now, some responses to others’ points.


Core mistake in OP rebalancing logic

In general, it doesn’t make sense to consider the function of value of the option now of the current price. If your model assumes that the price can jump -20% right after position entry, then Black-Scholes does not remotely resemble the risk you’d be considered to take as a P holder. On the other hand, if you’re assuming +/- brownian motion (Black-Scholes), then the price can’t (with reasonable probability) move that much right now. It will take a long (expected) time to have a reasonable probability of the price being down 20%. For example, for a >10% probability, it could be 25 days out of 30 days until maturity of your option. In this case of a downturn, with remaining 5 days to maturity, the analogous graph will be very flat (low delta), there will be no need to rebalance.

Side note: expected time to maturity is mentioned only to show the outline of the problem. This value is meaningless for most calculations.

For the graph you displayed [option value of current price], the only relevant part is the point at 2500 – how far below 1500 it is (assuming zero BS interest rate) shows the expected loss due to the price being below 1500 at maturity.

Delta doesn’t matter as much if you plan to hold longer – as the value of your position decreases with price decrease, the theta gets more negative, which means that you recover more as time passes. I’m not saying you’re instantaneously neutral to the price movements, I’m only saying the final payout is just a function of the final price – and you should model the EV lost directly based on the pricing at the moment of entry.


A pretty useful way is modelling such short put options by determining the BS price and the BS price at 0% interest rates and with the “current price” shifted up by the interest rate – that’s close to the EV leaked. Their ratio should be very high, meaning that the premium should be mainly coming from the interest rates (lending/leverage), not the expected value of the call option settling out of the money (optionality). It is quite easy to get these parameters so that dynamic rebalancing is never needed. What’s needed is only rolling of the expiries, which can be done very simply and efficiently.


We don’t need “rebalancing”, only predictable rolling

You can always use lower strike prices to decrease the risk further. Also, an excellent solution is decreasing the time to maturity – setting it to e.g. 3-4 days and rolling when there’s 1 day left with a strike at 60% of the current price sounds extremely safe. In the end, the shorter the timeframe, the further this design converges to “standard” lending, except liquidation happens when there’s no counterparty to roll your position, or the amount of premium you’d have to pay is too high for you to want to roll as a borrower/N holder.

Of course, users will get better effective rates (premiums) as the expiries get further in the future.

In fact, all parties are incentivized to roll very soon after entering – it’s associated with highest negative theta for P holders and best risk management for N holders.

tldr: use shorter timeframe options and roll them before expiry, the risk of a shortfall can be practically zero; no dynamic algorithms/heuristics for rebalancing are needed


I think it’s pretty easy to have ultra narrow spreads for rolling. It’s like a bond market, but where both sides really want to match to the other side. I think even a gradual auction will do – as a P holder, I’ll just decrease how much I want to earn by 0.01bp per minute, a lender will certainly match at some point within 1-2 hours. If due to a 10-day option I plan to earn 10bps, then with 1 day left I’ll probably have pocketed 9.0±0.3bps. Losing 1/30 of the yield in this example does not come close to 1-4% of the capital per year. It’s closer to 0.10%, in the worse-than-average scenario. The crux is: no dynamic rebalancing due to extremely far OTM options.


By quadratically, I think you just mean that there is concavity + small delta? If you approximate any function with the first and second derivative (in this case gamma and delta), [nearly] everything will look like a quadratic function locally.

The decrease as a function of collateral (ETH) price is sublinear.


That’s true. You fundamentally can’t replicate something of a higher value than your collateral. The point is that you should have the expiry set soon enough that the price won’t get to go that far, and you’ll be able to revise your collateralization needs. In extreme scenarios, you should customize how much protection you want (how much ETH collateral is needed for your position).


Firstly, a 1-year put is probably way too long for this design. 1-3 months tops at 50% volatility would make more sense imo.

Secondly, the P holders have a covered short put position, meaning they get paid. Your number is close to what I got when considering the ratio of the theta of a put option to the put option value. There is no put option value here – only a short put payoff and a long call. After you account for this, numbers won’t look weird anymore. It’s the call option holders (N holders) that pay this time-value (mostly interest).


Wording

“Prediction markets” are now associated with binary payoffs on arbitrary oracle’s responses. Here, we want to create a non-binary (continuous) payoff based on a scalar response of a one-time oracle. To avoid confusion, I call these instruments “oracle-based payoffs“. I think it’s cleaner and more descriptive.

2 Likes

Actually you are right. The system would benefit more in using the long asset as collateral. Your construction would be more fit for creating leverage tokens as I propose in my reply.

I think the key property here is that Vitalik was designing the system for a stablecoin and that would not work well with a USD stablecoin as collateral for obvious reasons.

2 Likes

I implemented a physically-settled version of the P/N construction and ran the full cross-party lifecycle on Base.

The variant I tested is for an on-chain pair: WETH/USDC. Since the strike asset exists on-chain, the upside leg can settle by physical exercise: pay USDC, receive WETH.

Mechanism:

  • split 1 WETH into two ERC-20 claims, P and N
  • before maturity, P + N recombine 1:1 back into WETH
  • during the exercise window, N exercises by paying the USDC strike and receiving WETH
  • after the window, P redeems the vault’s remaining balances: collected USDC plus any leftover WETH

Core settlement step:

N + strike USDC -> WETH

settle() does not ask what ETH/USD is. It distributes the assets the vault actually holds.

Live demo run:

  • vault: 0xb1E5f96C7B1eB5792c0a5E659E8917147195f7e1
  • exercise tx: 0x4e818efba541f6a3c7458a10b2e444a8ac0c36424bfdec41b0075e96a556a83e
  • A minted P + N from WETH
  • A transferred N to B
  • B exercised N by paying USDC and receiving WETH
  • C settled the vault
  • A redeemed P and claimed the collected USDC

The exercise tx is the key step: N was burned, USDC moved into the vault, and WETH moved out to the N holder atomically.

For pairs where the strike asset exists on-chain, settlement can be expressed as asset movement rather than price resolution.

The tradeoff is: removing the settlement oracle pushes work into exercise. Price discovery moves to the exerciser’s incentive, off the protocol’s critical path, but someone still has to exercise. I prototyped a keeper that auto-exercises ITM positions and settles, but that is execution infrastructure, not a protocol guarantee.

Open questions I’d value thoughts on:

  • how should P/N secondary liquidity form?
  • how should rolling/rebalancing happen with minimal slippage?
  • can exercise be made reliable at the protocol level without turning settlement back into an oracle problem?

The important part: settlement is an asset transfer, not a price lookup.

1 Like

Does the “no liquidations” property of this system come from the fact that it’s using options OR because the short side is always fully collateralized?

Another way to ask the same question - how do you get leverage in this option-based-perp while still not requiring liquidations?

The option primitive (P + N always summing to 1) that eliminates liquidation surface is impressive. The remaining surface is the oracle resolution at M. One way to make that more robust without real-time requirements is a multi-observer sequenced quorum: independent observers emit ordered observations of T near M; a gate aggregates with explicit sequence tracking, coherence/“toxicity” filters, and quorum rules, producing a single attested value (with fallback to a heavy oracle only on disagreement or low coherence, the same pattern already used in some scalar markets). This keeps everything slow and recourse-friendly while adding redundancy and ordering guarantees. Has anyone looked at sequenced multi-party attestation layers specifically for scalar settlement?

One tricky issue with options, even on tradfi markets, is that the liquidity can be limited which can influence trades significantly. A bunch of onchain option protocols faced liquidity issues which made it quite difficult for traders to really use them. People who wanted to trade crypto options mostly ended up on deribit for this reason. In theory the math works, but the ability to execute trades on a timely manner were not easy.

2 Likes

That’s why designed Sir to be option like in the sense that a user pays a one time fee, but they are not options. In my opinion strict options are not the right primitives for the reason you mention and others like it doesn’t strictly track the price of the underlying.

Why would it not be P = N + 1?

Allow me to not pretend to not understand how to read these posts nor how to cryptically leave one liners for once


What Vitalik is suggesting, is par for his course. Preach anti censorship, even though you sided with it when we all needed just 1 of the bigs to say “No; no more.” Disregard the fact that in terminal valuations actual MBA masters courses P = N + 1 is EXACTLY HOW OPTIONS ARE VALUED; ie a term is N, that’s one valuation; how do you value the option to extend 1 year? or it could be 2 whatever the 1 would stioll be 2 if it’s one option to extend.

In the real world, what happens? Principle is owed more than lessee has or could ever even access if they maxed out all methods at their disposal?

THE PRINCIPLE GETS PAID STILL. IT’S TAKEN OUT OF THE REST OF ALL OF OURS WALLET RIGHT IN FRONT OF OUR FACE & WE ARE MADE POORER, THEY RICHER, THE AMERICAN DREAM ANOTHER NTH DEGREE REMOVED FROM EVER BEING RESURRECTED TO LIFE AGAIN!!!

Put your money where YOUR MOUTH CANT FAKE BUT TRIES TO LIVE!

IF THE PRINCIPLE IS OWED MORE THAN THE COLLATERALIZED AMOUNT; THE LESSEE GETS TO PLAY AS MANY TIMES AS THEY WANT; HE’S STILL AT 0 AT THE END? SO WHAT? PRINCIPLE IS OWED. BUY IT OUT OF THE SUPPLY AND BURN IT!!!

That’s how you establish High Trust Norms 
 for real

@vbuterin this framing is very close to a design pattern we have been working on at The Risk Protocol (TRP) using fully collateralized, complementary synthetic option claims rather than debt claims.

In our case, a deposited crypto asset is split into two freely tradable tokens whose embedded option positions are equal and opposite. The options are internal to the token pair, not sourced from an external venue; recombining the two tokens cancels the option exposures and redeems the underlying collateral. So the shared primitive is very similar to what you describe here: the system is not creating an undercollateralized debt liability that must be rescued through liquidation. It is splitting a fixed collateral pool into two option-like claims.

The current TRP implementation is aimed less at arbitrary index-tracking and more at tokenizing crypto-native risk itself. One side gives up some upside in exchange for downside protection; the other side absorbs that risk and receives the upside. The tokens are intended to trade on secondary markets, so the embedded synthetic options have market prices, in addition to model-implied reference values published by us. We have automated rules-based rebalancing that resets the synthetic options and the options are designed to be a costless collar so there is no initial/rebalancing cost. We’ve used this design chassis to create different types of risk exposures not limited to price stability.

The main difference is the oracle tradeoff. Your construction maximizes oracle minimalism: settlement can happen at maturity using a slow oracle, while rolling/rebalancing can be pushed to users, wrappers, or market structure. Our current implementation makes a different choice: it uses rolling epochs, beginning- and end-of-epoch oracle prices, and a path-dependent barrier. If the barrier is hit, the epoch transitions early to avoid bankrupting the risk taking side. So it gives up some of the “slow-oracle purity” in exchange for a more explicit protected payoff and a perpetual/rolling product experience.

The question I’d be very interested in your view on is whether this kind of oracle dependence is meaningfully different from debt-liquidation oracle dependence. In TRP, the oracle is not being used to decide whether to forcibly liquidate an undercollateralized borrower; it is being used to define the lifecycle and state of a fully collateralized synthetic option pair. But because the barrier is path-dependent, it does require more oracle trust than your maturity-only construction.

So I see TRP as a nearby point in the same design space: options instead of debt, complementary claims instead of liabilities, market-traded synthetic option exposure instead of liquidation-based solvency. The key design question is where the right boundary lies between slow-oracle, maturity-only scalar claims and richer path-dependent option structures that may be more useful to end users but require more oracle involvement.

the problem is you don’t add value by reducing the options of the princple nor the client just the same.

Great add - interested to read more on TRP ! where can one become savvy? Thanks for sharing - key word is add; TRP indeed adds another option instead of taking one away.

Appreciate the detailed comparison — trps costless collar + rolling rebalance + path-dependent barrier on the same fully-collateralized split seems much more fitting, too!

It does add meaningful extra option layers (dynamic synthetic collar + barrier mechanics) beyond the base P/N maturity-only primitive. That’s inherent, or intrinsic value that helps users, but the increased oracle/path dependency is the key tradeoff you called out.

On the high-trust side: how does TRP handle principal/protocol incentives in rebalancing? If they want ongoing capture, should they be required to buy+burn supply rather than extract via parameters?

Curious on your take for keeping the primitive non-extractive. I’m not anti-mev, by any means, what is anyone trading a security of any sort trying to do, anyway, these days? Being clever is cool, doing something that’s considered primitive because no one living ever knew of it other than relic or antiquated method, but applying it to somethign that’s overcomplex today to add value for all users? Increase trust in a trustless environment?
That’s instant classic; original OG status for life