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.