Permissionless Perpetuals

Trading of options on top of any asset pool in Uni v3
i.e., do for decentralized options what x·y=k did for spot trading.

Overview

Perpetual

Options are based on relocating liquidity within Uni v3
Short: moving liquidity closer to $S_{p}$
Long: moving liquidity away from $S_{p}$

Oracle-less Black-Scholes pricing

Streaming premium $(p)$, where $p_{i}=0$ and $p_{t} < p_{t’}$

path-dependent pricing formula that converges to BS

Trustless

Options buyers/sellers mint long/short options through Panoptic contracts
LPs provide liquidity to the Panoptic pool without risking their capital

Composability

Multi-legged options with user-defined payoffs as ERC1155 tokens, tradable and composable.

Disentanglement of trading fees and LP rewards

LPs “lend” liquidity to options sellers/buyers for a fee
Options buyers/sellers pay/receive premium proportional to fees generated by their UniV3 LP

Risk Management

Options sellers able to sell undercollateralized options (up to 5x capital efficiency).
Multi-leg options with up to four puts/calls can be deployed in a single tx.

Panoptic Option Instruments

No expiration, deployed at any strike $(K)$, and their value does not decay over time.

Uni v3 liquidity positions behave as cash-secured puts and covered calls
(Kristensen et al., 2022), as outlined by Lambert (Lambert, 2021b)

DAI-ETH single tick

Payoff identical to a covered call option.
However, LP tokens do not expire and Uni v3 options are reversible.

At every $S_{p} = K$

• Token composition will shift
• Fees will be accumulated

Fees are considered a short option premium, where $p_{t} < p_{t’}$.

Problem: Shorting LP positions yield the same payoff as buying long options. However, lending for v3 LP positions is “challenging because each LP is unique and nonfungible” [sic].

Solution: Panoptic facilitates minting/lending of liquidity from LP to option seller, enabling long/short options based on tokenized concentrated liquidity positions.

Put Options

Mechanism

Short put: locking K numeraire at a strike price $K$.
Long put: removing K numeraire of liquidity at price $K$.

Users create a long option by “borrowing” a short option.

DAI-ETH

$S_{p} > K$ = OTM
K DAI initially relocated to the $K$ price tick is still worth K DAI.
Option may be closed by moving K DAI to the DAI liquidity pool with no cost.

$S_{p} < K$ = ITM
Long put: user must supply 1 ETH to get K numeraire
i.e. option guarantees the buyer can sell 1 ETH for K DAI

Short put: user must remove 1 ETH at strike price $K$ and supply K DAI i.e. option seller is obligated to purchase 1 ETH for K DAI

Exercising Options

Deploying: writer/seller relocate liquidity owned by the Panoptic liquidity pool, not their own Purchasing: protocol will lock relocated liquidity to the Panoptic liquidity pool

This ensures the protocol can access relocated funds and enables undercollateralized options.

Call Options

Long calls can be synthetically created by leveraging the put-call parity and combining a long put with a long asset position. More details about synthetic calls in Lambert, 2021c.

Panoptic avoids the creation of a short stock position because a call at strike $K$ in an ETH-DAI pool is identical to a put at strike $1/K$ in a DAI-ETH pool.

Minting Options

Short call: a user would need to remove 1/K ETH and lock it at strike price $K$
Long call: remove 1/K ETH at a strike price $K$ and lock it in the ETH liquidity pool

DAI ETH

$S_{p} < K$ = OTM
$S_{p} > K$ = ITM

Long call: close position by collecting 1/K ETH by depositing 1 DAI at strike $K$
i.e. guarantees buyer can purchase ETH for K DAI/ETH

Short call: supply 1/K ETH and get 1 DAI back from strike $K$
i.e. owner is obligated to sell ETH for K DAI/ETH

Limiting Gamma Exposure

Creating options with a fixed range results in options with a fixed Gamma.

Given: Gamma of an option can be capped by widening the range of an options position.

Options traders can utilize the relationship between the range factor

\[r=\sqrt{priceUpper/priceLower}\]

of a position and its effective days-to-expiration $(T_{r})$ and an asset volatility $(σ)$ derived in (Lambert, 2021a) and given by:

\[T_{r}=\frac{2π}{σ^2}(\frac{\sqrt{r}-1}{\sqrt{r}+1})^2\]

Controlling $r$ prevents options from reaching “expiration” and capping its Gamma to

\[\frac{2}{(K \times π \times ln(r))}\]

Since $r > 1$ Gamma will never diverge to infinity as the position approaches expiration. Eliminates pin risk from TradFi, when options approach expiration and rapidly shift between being ITM and OTM if the price is near the strike price.

Additionally Panoptic options rely on a path-dependent mechanism, widening options also smooths out how quickly the price of an option increases over time.

Panoptic ERC-1155 composite option token

A core element of the protocol is users can sell undercollateralized options by using margin requirements.

• Reduces collateral requirements by combining them into a ERC1155 token to create defined-risk positions.
• Uses the 256-bit ID of an ERC1155 to encode information about up to four different options within the same pool.
• Combining options into a single token allows the protocol to calculate margin requirements of interlinked options.

Important when creating multi-legged options positions that may have a risk-defined profile even though each individual option may theoretically be exposed to infinite losses. e.g., a call spread’s max loss is capped at the distance between the long and short call even though the short leg has infinite risk.

Tokenizing complex option strategies could facilitate vault-like instruments
e.g.: vault based on shorts 16∆ strangles, 30∆ Jade Lizards, or synthetic equity positions.

Oracle-less Black-Scholes Pricing

Streaming premium model

No upfront options cost:
Pricing is path-dependent and grows at each block according to the proximity of $S_{p}$ to $K$.

Formally, this corresponds to continuously integrating the theta $(\theta)$ of the option.

\[\int\theta d\theta\]

Note that:

\[\theta = \frac{\partial V}{\partial t}\]

Assuming a zero risk-free interest rate, $\theta$ is defined as:

\[\theta = \frac{dV(S,t)}{dt} = \frac{Sσ}{\sqrt{8πt}} exp \left(-\frac{ \left[ ln \{ \frac{S_{o}}{K} \} + \frac{σ^2 t}{2} \right] ^2}{2σ^2 t} \right)\]

Where: $S$ is asset spot price $σ$ is asset volatility $K$ is strike price $t$ is time to expiration

Recover the option’s value by integrating theta over time and assuming that the price remains constant $(S_{0})$

\[V(S_{0} = constant, t) = \int_{0}^{T} \theta(S_{0},t),dt\] \[= \text{Call option price C}(S_{0},K,T)\]

If $S_{0}$ is not constant, however, one could ask where it is possible to recover the call option price via integrating over the asset spot price history $S_{t}$, i.e.:

\[Premium = \int_{S(t)} \theta(S_{t},K,σ)dt\]

This corresponds to integrating $\theta$ over the stochastic price path $S(t)$.

Computing the premium using this formula may result in:
A: $S(t)$ never comes inside the defined price range
i.e. option costs nothing.
B: $S(t)$ approximates $K$, premium increases according to the time it spends close to $K$.
i.e. option costs several times larger than Black-Scholes.

Convergence to Black-Scholes pricing model

Approximately:
33% of call option premium held for 7 days would cost zero.
16% of call option premium would be twice as large.

The coefficient of variation, the ratio of the standard deviation ($\sigma_X$) of the option price to its mean ($\mu_X$), $\frac{\sigma_X}{\mu_X}$ approaches 82% when held for more than ten days.

Simulation results indicate that the price of an option will heavily depend on the history of the asset price.

Option pricing and implied volatility

Option premium is computed by integrating theta over time.

Streaming premium pricing model:
a series of continuously expiring options that accumulate a premium $θ∆t$ at every time step $∆t$.

As $∆t$ approaches zero, the option’s $\theta$ starts looking like a Dirac delta function with a fixed width given by the full-width half max.

If we assume that the width $(W)$ of the \delta function is the tick spacing of a Uni v3 pool (i.e., tickSpacing tS = 0.02 for 1%, 0.006 for 0.3%, 0.001 for 0.05%), then the value of theta can be approximated as the time spent inside the range multiplied by the height of the delta function.

Given:

• Area under $\theta = \frac{k^2 σ^2}{2}$
• Width $= k·tS$

$\therefore$ Height $= kσ2/2tS$

** As prescribed by the tickSpacing $(tS)$.

This corresponds to a cumulative premium of

\[(k2σ2/2tS)·(timeSpentInRange)\]

By comparing the premium to fees collected by Uni v3 per unit time

\[feeRate · (Volume · Time)/tickLiquidity\]

the implied volatility (IV), σ, can be derived as:

\[IV ≡ σ = 2 * feeRate * \sqrt{\frac{Volume}{tickLiquidity}}\]

This IV value is in perfect agreement with the one derived using a completely different approach (Lambert, 2021d).

Using fees collected as a measure of the option premium results in IV that depends on the traded volume and liquidity at the position’s tick.

Panoptic Ecosystem

Liquidity Provider

1. Provide fungible single asset liquidity to be borrowed and relocated to a Uni v3 pool
2. Liquidity deposited at $t_{0}$ is recorded into the smart contract and emitted as an ERC20 LP token
3. LP liquidity is deployed to UniV3 as buyers/sellers mint options
4. Fees are distributed to the option seller minus a spread that depends on liquidity available in the pool, in $token0$ and $token1$.
5. LPs collect commission based on the notional value of all relocated liquidity (initially set to 0.1%).

Note: LPs would anticipate that option sellers are savvy market participants that will optimize liquidity allocation to their benefits. LPs with c-ratio > 100% are able to sell option at zero commission.

Removing Liquidity

1. LP requests their liquidity from the option pool
2. ERC20 LP tokens are burned
3. LP receives their share of the options pool, including fees

Note: Depending on the locked liquidity for open options, some liquidity might be unavailable until: i) the long positions are closed; or ii) LPs force the exercise of far OTM long options.

Option Sellers

1. Borrows liquidity for a fixed commission fee to create short options (initially set at 0.1% of notional value)
2. Relocates liquidity to a Uni v3 pool.
3. Sellers may mint several option positions in a single transaction, and the combination of up to four options will be stored inside the smart contract as a single ERC1155 as an int256 bit.
4. Deposit collateral and can sell options larger than their collateral balance (20% of exercise value plus option’s ITM amount).

Closing Options

1. When closing a short option, the user will have to repay the exact amount of tokens that was borrowed to the liquidity pool.
2. Options sellers receive an option premium from the liquidity pool (corresponds to the amount of fees that was collected by the deployed liquidity).

Option Buyers

1. Remove liquidity from Uni v3 back to Panoptic smart contract for a fixed commission fee (0.1% of notional value).
2. Deposits collateral to cover the potential premium to be paid to the sellers (10% of the notional value of the option).
3. May mint several option positions in a single tx, stored inside the smart contract as a single int256 bit.

Note: Options can only be bought if option sellers/writers have already minted/sold them, hence make the options sellers an essential actor in the Panoptic ecosystem whose role may need to be incentivized. The collateral amount equal to 10% of notional corresponds to the maximum price that would be paid for a 45 DTE option with IV equal to 75%.

Exercising options

1. When exercising a long option, the user will have to repay the borrowed tokens to the liquidity pool.
2. In addition, they will have to pay an option premium to the liquidity pool as a single asset, which corresponds to the amount of fees collected by the deployed liquidity plus a spread that depends on the liquidity in the Uniswap pool when the option was created.

Note: Since ITM options involve the transfer of both tokens in a single transaction, the amount of premium paid will be deducted from the option’s exercise amount (eg. deducted from the num ́eraire for puts and from the asset for calls)

Total, Notional, and Locked Liquidity

Liquidity in Panoptic pools is tracked using three storage variables:

• totalLiquidity:
  – Total liquidity deposited by LPs
  userLiquidity(userAddress)

• totalNotionalValue:
  – Liquidity moved to AMM, equal to notional value of sold options.
  – Requires the list of positions as an input.
  userNotionalValue(userAddress, positionList)

• totalLockedLiquidity:
  – Liquidity relocated from AMM to Panoptic by buyers.
  – Locked to ensure availability when the option is exercised.
  userLockedLiquidity(userAddress, positionList)

Note:
Since a user account may own hundreds of options positions, it is computationally difficult to manipulate an array of positions if it were stored in the smart contracts. It is easier to require the user to always supply the positionList as computed off-chain and have the smart contract loop through the provided list to check that

1. the user indeed owns each position, and
2. the number of positions matches optionBalance(userAddress).

Framework for cost calculation of options

Panoptic considers liquidity on Uniswap at a given tick to calculate the premium/cost of options.

Assuming the position is not in-range when fees are collected, total fees for all positions at a specific $r$ is:

\[totalFees = (fg_{upper} − fg_{lower} − fg_{insideLast}) · liquidity\]

where:
$fg_{upper}$ = feeGrowthOutside0X128 of the upper tick
$fg_{lower}$ = feeGrowthOutside0X128 of the lower tick
$fg_{insideLast}$ = feeGrowthInside0LastX128
$liquidity$ = liquidity owned by the protocol.

Option buyer premium paid to seller:

\[totalFees · \frac{positionSize}{liquidity}\]

Threat model

Problem: An options buyer could purchase all the options available and drain the liquidity at a specific tick.

In that case, the liquidity owned by the Panoptic protocol is zero (liquidity = 0), no fees will be collected (totalFees = 0), and the option premium will also be zero.

Solution: Track effectiveLiquidity for each position.

Specifically, instead of using $\frac{positionSize}{liquidity}$, the protocol computes fees based on the actual amount of liquidity deposited there by the option sellers before any option is purchased.

Example: If 10 ETH was sold at a given tick and a call option worth 9.9 ETH was purchased, only 0.1 ETH of liquidity remains in the Uniswap pool.

However, the Panoptic smart contract base the premium calculation as if 10 ETH of liquidity was present even though only 0.1 ETH of liquidity is actually deployed.

Using this argument, the cost of an option can be derived using $effectiveLiquidity$, which means that the premium will be given by:

\[Premium = totalFees · \frac{positionSize}{baseLiquidity − positionSize} effectiveLiquidity\]

where baseLiquidity = liquidity initially present before the options are created.

In the example above, the amount of fees paid will depend on effectiveLiquidity = 9.9/(10−9.9) = 99 ETH instead of positionSize/liquidity = 9.9/10 = 0.99 ETH.

The same argument can be made for short options (i.e., selling a new option should not consider the extra liquidity added to the pool at the time of deployment), meaning that the effective liquidity of a short option position is

\[effectiveLiquidity = \frac{positionSize}{baseLiquidity + positionSize}\]

The effectiveLiquidity should not differ much from the actual liquidity present when the positionSize is small relative to the amount of baseLiquidity owned by the Panoptic pool.

This slight difference could be seen as a spread that is calculated for each option and increases for larger orders according to:

\[spread = ±positionSize/baseLiquidity\]

Hence, Panoptic will store, for each option, a record of the feeGrowthInside0LastX128 and feeGrowthInside1LastX128 parameters and the amount of baseLiquidity initially owned by LPs.

In addition, Panoptic will take special consideration for situations when a user purchases several small options rather than a large one. e.g: purchasing ten options each valued at 1 ETH should result in the same amount of premium as one option valued at 10 ETH.

Therefore, if a user has already purchased N1 options when the liquidity was L1 and the user wants to deploy an additional N2 options at a later time, then the effectiveLiquidity amount will be based on baseLiquidity -= N2, which results in and effective liquidity equal to (N1 + N2)/(L1 − N1 − N2) for the combined options, and not N1/(L1 − N1) for the first option and N2/(L2 − N1) for the second one.