AMPO: Minimal trust options
Devcon 8 · 3 Nov 2026 · 8:02
ScopeLift smart contract engineer Alexander Keating introduces AMPO, a perpetual-options design that removes the need for an external price oracle. He explains how predictable decay and a fixed exchange of assets at exercise time reduce trusted dependencies, exploring the implications for DeFi security and censorship resistance.
Speakers
Topics
From Devcon 8, hosted by Ethereum Foundation.
Transcript
All right. Hi, I'm Alex. I'm going to give a presentation on Ampose amortitizing perpetual options, a new DeFi prim primitive that minimizes trough trust and is based on the work of Maxim Bichuk and Zachary Feinstein. Before diving into Ampose, I want to take a brief look at how existing perpetual option protocols introduce trust and the main mechanism is through onchain price oracles or price oracles in general. These are used to inform funding rates, cash settlement, margin and liquidation rules. AMO makes a couple design decisions to help eliminate the need for price oracles. The two main design
decisions is the amortization. So the uh underlying that the option can claim uh amortitizes over time or decreases. This removes the need for funding payments. And uh the other design decision is physical settlement and full backing. So at exercise time you're actually exchanging the assets and the protocol is always backing the underlying option. We also don't need a price oracle for determining the premium for the options because that's determined by the utilization of the pool.
And uh taking a look at like the life cycle from LP to exercise. LPS provide the liquidity into the uh option pool. For this example, ETH for calls, USDC for puts. A prospective holder pays a premium like I mentioned determined by the utilization. So outstanding options over the collateral of the pool. A holder can exit through exercising their option or they can sell their claim back to the pool based on the utilization.
Uh LPS are compensated via the premium uh with some uh premium curve that's determined also by the utilization. And so let's take a look at like a call and a put to get a sense of how the payoffs work uh with this type of option. So imagine I want to purchase a option for Ethereum with a 2,000 USDC strike price. Let's say the premium I have to pay is 100 USDC for this example.
On day one of that option, I have a claim to one Ethereum for 2,000 USDC. after one halflife. A half life is basically the amount of time uh for the underlying to become worth half. So now I can claim half an ETH for a,000 USDC. Let's imagine the price of Ethereum at that halflife is 3,000 USDC. I will pay a,000 USDC for my half an ETH and then immediately sell it for 1500 USDC and then I would realize a profit of 400 USDC after taking into account the premium I paid.
So in this example, you can see that I didn't need a price for the underlying protocol. the the price is just used for the option holder to make the decision of when to exercise and totally external. So, let's take a look at a put option. It's very similar. Uh I buying an option for uh well, I'm selling uh an option for uh one ETH for 2,000 USDC. After one halfife, I can sell half an ETH for a,000 USDC. Let's imagine the price of ETH at that halflife is 1500 USDC.
I realize a profit of 150 USDC after taking into account the premium. So hopefully from this talk you can see that through protocol design we can eliminate the need for external dependencies. And my call to action to anyone in the room right now is to take a look at your own protocols. Can you remove a dependency with an existing mechanism? If you can't, as a community, we should look for different ways to eliminate those dependencies. Thank you.
Any questions? >> Yeah. Um, multiple questions. >> Hi there. Uh, how do you set the premium and then how do you set the decay rate? Are those like market parameters? >> Yeah. Yeah. So, the decay rate, the paper suggests setting a fixed decay rate and it's up to the market creator. So, it could be like three bips, five bips or something along those lines. And the premium is determined by the utilization. So, uh, the amount of open interest over the collateral.
Uh any more questions? Yeah. Yeah. >> What was the title of the paper? >> Uh designing onchain options amortitizing perpetual options by uh Maxim Bichuk and Zachary Feinstein. Uh there's another paper too amortizing perpetual options by Zachary Feinstein which is less of the market design but just talks about the amortization piece a little bit more in depth. So yeah, highly recommend taking a look at those to get a better understanding. The next question.
>> Yeah. So, uh I wanted to ask uh you said halflife, right? So, is that like days to expire like by half or is like the premium or the price goes half like that? >> Yeah. Halflife. So, they're perpetual options so the time is infinite. Uh so halflight is is really how long it is really when the uh underlying hits. So that's why my examples you start with one ETH halfife it hits half an ETH. So the determination of that amortization depends on whatever curve the market picks. Um the paper recommends a fixed curve like I like I mentioned earlier.
>> Got it. Thank you. >> More questions. Um actually I got one. Um what's the main tradeoff for users when this option mechanum re removes its price or >> wait what what was your question? What was the first part? like like tradeoff for users when like sort of the users uh when the like option mechanism re removes a surprise oracle >> what is the sorry the first part the the user piece >> the like like basically uh for the users right when they uh opt into this kind of product yeah uh if they sort of opt out what's the sort of the >> if they opt out of the
>> yeah remove the price oracle >> well the user doesn't get to choose whether the oracles included or not, right? Uh or like what is the benefit to the user if they Okay, so the benefit of not having a price oracle is you kind of uh remove those security vulnerabilities from the oracle. So price manipulation. Um the oracle if it becomes unavailable is another thing that can cause a cat catastrophic incident for whatever protocol relies on it. Um so I think it it basically adds a little it adds security um by removing the need for a price oracle and it's more it's more um trust minimized. You don't have to uh trust
that this third party system is always on and giving you accurate information. >> Yeah.