Skip to content

Commit

Permalink
formatting
Browse files Browse the repository at this point in the history
  • Loading branch information
1e-18 committed Jul 1, 2024
1 parent 23a0162 commit 4217450
Showing 1 changed file with 67 additions and 49 deletions.
116 changes: 67 additions & 49 deletions _posts/2024-02-04-panoptic.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,8 +26,8 @@ Options are based on relocating liquidity within Uni v3 \
`Long:` moving liquidity away from $S_{p}$

#### Oracle-less Black-Scholes pricing
Streaming premium $(p)$, where $p_{i}=0$ and $p_{t} < p_{t'}$ \
> according to a path-dependent [pricing formula](#streaming-premium-model) that converges to BS
Streaming premium $(p)$, where $p_{i}=0$ and $p_{t} < p_{t'}$
> path-dependent [pricing formula](#streaming-premium-model) that converges to BS
#### Trustless
Options buyers/sellers mint long/short options through Panoptic contracts \
Expand Down Expand Up @@ -100,7 +100,7 @@ $S_{p} < K$ = ITM \

### Call Options

> In theory, 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](https://lambert-guillaume.medium.com/synthetic-options-and-short-calls-in-uniswap-v3-a3aea5e4e273).
> 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](https://lambert-guillaume.medium.com/synthetic-options-and-short-calls-in-uniswap-v3-a3aea5e4e273).
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.**

Expand All @@ -122,12 +122,15 @@ $S_{p} > K$ = ITM

### Limiting Gamma Exposure

Create options with a fixed range, resulting in options with a fixed Gamma.
Creating options with a fixed range results in options with a fixed Gamma.

The Gamma of an option can be capped by widening the range of an options position. Specifically, options traders can utilize the relationship between the range factor
> 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{\frac{priceUpper}{priceLower}}
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:
Expand All @@ -142,31 +145,32 @@ $$
\frac{2}{(K \times π \times ln(r))}
$$

Since $r > 1$, Gamma will never diverge to infinity as the position approaches expiration.

This will eliminate pin risk, which manifests itself in TradFi when options approach expiration and rapidly shift between being ITM and OTM if the price is near the strike price.
> 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 options collateral requirements by combining them into a ERC1155 token to create defined-risk positions.
- 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 the deployment of vault-like instruments which could, for instance, allow users to participate in vault based on short 16∆ strangles, 30∆ Jade Lizards, or synthetic equity positions.
>
> 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

Instead of requiring the users to pay for options upfront, the pricing of an option is path-dependent and will grow at each block according to the proximity of $S_{p}$ to $K$.
**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.

Expand Down Expand Up @@ -210,31 +214,32 @@ $$

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 will increase according to the time it spends close to $K$.
*i.e. option costs several times larger than Black-Scholes.*
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.
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.

The coefficient of variation, defined as the ratio of the standard deviation of the option price to its mean, `approaches 82% when held for more than ten days`.

#### Option pricing and implied volatility

Option premium is computed by integrating theta over time.

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

As the time interval $∆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.
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.

Expand All @@ -248,26 +253,36 @@ If we assume that the width $(W)$ of the \delta function is the tick spacing of
** As prescribed by the tickSpacing $(tS)$.

This corresponds to a cumulative premium of $\frac{k2σ2}{2tS}·(time spent in range)$.
This corresponds to a cumulative premium of

$$
(k2σ2/2tS)·(timeSpentInRange)
$$

By comparing the premium to fees collected by Uni v3 per unit time (i.e., feeRate · (Volume · Time)/tickLiquidity), the implied volatility (IV), σ, can be derived as:
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}}
$$

Interestingly, this value for IV is in perfect agreement with the one derived using a completely different approach (Lambert, 2021d).
> 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 liquidity in the form of single assets that can be borrowed and relocated to a Uni v3 pool
2. At $t_{0}$ the liquidity deposited is recorded into the smart contract and emitted as an ERC20 LP token
3. As buyers/sellers mint options, LP liquidity is deployed to Uniswap
4. Fees collected, composed of $token0$ and $token1$, are distributed to the option seller minus a spread that depends on the amount of available liquidity in the Uniswap pool.
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:**
Expand Down Expand Up @@ -323,38 +338,41 @@ Since ITM options involve the transfer of both tokens in a single transaction, t

Liquidity in Panoptic pools is tracked using three storage variables:

- `totalLiquidity`:
Tracks the total amount of liquidity deposited by LPs.
Deposits are tracked using `userLiquidity(userAddress)`.
- `totalNotionalValue`:
Tracks liquidity moved to Uniswap, equal to the notional value of all the sold options.
Notional value is reported using `userNotionalValue(userAddress, positionList)`.
*The function requires the list of positions as an input.*
- `totalLockedLiquidity`:
Tracks liquidity relocated from Uniswap to Panoptic by option buyers.
Locked liquidity is computed using the call function `userLockedLiquidity(userAddress, positionList)`.
*Liquidity needs to be “locked” because, when liquidity is moved back, it needs to be available when the option is exercised.*
- **`totalLiquidity:`** \
-- Total liquidity deposited by LPs \
`userLiquidity(userAddress)`

> **Note:**
- **`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

Fees are proportional to liquidity in Uniswap, therefore Panoptic considers liquidity at a given tick to calculate the premium/cost 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 given by:
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`
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:
Expand Down

0 comments on commit 4217450

Please sign in to comment.