Panoptic Overview
This is an introductory summary of the Panoptic Protocol.
What are Options?
Options provide options traders with a versatile tool for managing risk and generating profits. By buying or selling options, traders can speculate in a capital efficient manner on the price movement of a security. This is done by taking a long or short position without having to own the underlying asset. Options can also be used to manage portfolio risk, by hedging against potential losses in other investments. In addition, options can be used to generate income, through the writing of options contracts. Because options allow traders to take on different levels of risk, and also defined-risk positions, they are a useful tool for managing financial portfolios.
Options are an agreement between two parties to buy (or sell) an asset for a fixed price at a pre-determined time. Hence, each option has a
- Strike: the agreed-upon price the asset has to be bought/sold
- Expiry: a time in the future when the transaction has to occur
- Premium: the value of the option, or how much does the buyer pays for the right to buy/sell the asset
(figure here)
The value of an option—called the premium—used to be difficult to determine. Following the development of Nobel-prize winning mathematical models by Black, Scholes, and Merton, an optimal price can be derived in a way that buyers and sellers both agree on the option contract's price.
How do Panoptic Options differ from traditional options?
Options in Panoptic, however, differ slightly from conventional options.
The Panoptic protocol uses Liquidity Provider (LP) positions in Uniswap v3 as a fundamental building block for trading long and short options. Specifically, this means that with Panoptic you get access to new and improved features when options trading:
- Panoptic Options never expire and are perpetual
- Anybody can deploy an options market on any asset in a permissionless manner
- Panoptic enables anyone to lend their capital to options traders as a liquidity provider
- Options have unique properties: width, new concept of moneyness, user-defined numeraire, etc.
- Pricing does not involved counterparties (like market makers) and is path-dependent
- There is no concept of vega, which means premium for open positions will be affected by volatility expansion
- Collateralization requirements and buying power reduction respond to market activity
- Commissions are paid only once, when the position is created
- Users can delegate funds to another account
- Distressed accounts will be liquidated by external users
- External users may forcefully exercise far out-of-the-money long positions
(figure here)
Protocol Design
Manipulation Protections
The objective of many flash-loan-based attacks is to manipulate the price of an asset or token balance in a smart contract by borrowing a large amount of funds (sometimes for free!). Importantly, all funds must be returned in the same block for flash-loan attacks.
The Panoptic Protocol seeks to prevent pool manipulation attacks by prohibiting the withdrawal of funds from the same block in which they were deposited. Similarly, when funds are delegated to an account, both the delegator and delegatee accounts are locked for that block.
Computed quantities
Several computed quantities are derived from the token balance in the Panoptic and Uniswap v3 pools.
Total Balance
The totalBalance() value is the amount of tokens that
- can be sold and moved to the Uniswap v3 pool, or
- have already moved to the Uniswap v3 pool
This balance is computed using the total token balance inside the Panoptic pool (obtained via IERC20(token0).balanceOf(panopticPool)), the amount of tokens moved into the Uniswap v3 pool, and the amount of tokens collected.
This derived quantity is used to compute the collateral shares.
>pp = IPanopticPool
>univ3pool = IUniswapV3Pool
>token0 = ERC20 interface of collateral token | token0.balanceOf(pp) =
_--| amount of token0 owned
/ | by the Panoptic Pool
_----------------pp.totalBalance()---------------_ /
/ \ /
| _----pp.inAMM0()---_ _--------------token0.balanceOf(pp)---------------_
| / \ / | _---pp.collected0()--_ \
| | amount of token0 | | amount of `free` token | / \ |
| | moved from Panoptic | | that can be withdrawn || collected token0, | |
| | to UniswapV3 | | or used to sell || reserved to be | |
| | | | undercollateralized | \ paid to sellers / |
| \ / \ options | ¯--------------------¯ /
| ¯------------------¯ ¯-----------------------+-------------------------¯
\ /
¯------------------------------------------------¯
The pp.collected0() is the amount of tokens that are reserved to be paid to the sellers. Recall that, when you buy an option in Panoptic, you remove a seller's liquidity from a Uniswap v3 pool.
When trading activity happens in the pool, fees accumulate that the sellers would have earned had the buyer not moved the liquidity out of the pool to Panoptic.
These fees are incidentally also what makes up the cost of the option for the buyer, and we cover that topic elsewhere. The point is that the Panoptic Pool manages and collects these to-be-paid tokens and stores in pp.collected0().
If the buyer has more collateral than what they owe the seller (and more by some margin of course), they can use their remaining free capital to do whatever they want.
They can sell options, e.g., by deploying this capital as LPs into the Uniswap v3 pool. This is what token0.balanceOf(pp) - pp.collected0() represents.
Pool Utilization
The pool utilization is a measure of the fraction of the totalBalance() which belongs to the Uniswap v3 pool.
This parameter is computed whenever a position is minted to set the collateralization ratio and commission rate of the position:
poolUtilization = pp.inAMM0() / pp.totalBalance();
= pp.inAMM0() / (pp.inAMM0() + `free` token0)
= pp.inAMM0() / (pp.inAMM0() + token0.balanceOf(pp) - pp.collected0())
-Example 1: poolUtilization = 50% (targeted equilibrium)
_------pp.totalBalance()--+-------------------------_
/ | \ COMMISSION_RATE = 20bps
| pp.inAMM0() (inAMM0) | `free` token0 (fT0) | BUY_COLLATERAL_RATIO = 10%
\ | / SELL_COLLATERAL_RATIO = 20%
¯-------------------------+-------------------------¯
-Example 2: poolUtilization = 90% (favors buying)
_------pp.totalBalance()---------------------+------_
/ | \ COMMISSION_RATE = 20bps
| pp.inAMM0() | fT0 | BUY_COLLATERAL_RATIO = 5%
\ | / SELL_COLLATERAL_RATIO = 100%
¯--------------------------------------------+------¯
-Example 3: poolUtilization = 10% (favors selling)
_-----+-----pp.totalBalance()-----------------------_
/ | \ COMMISSION_RATE = 60bps
| inAMM0| `free` token0 | BUY_COLLATERAL_RATIO = 10%
\ | / SELL_COLLATERAL_RATIO = 20%
¯-----+---------------------------------------------¯
Commission and Collateral Requirements
The commission and the collateralization ratios are computed after all funds have moved in/out of the Panoptic pool.
Commission Fees
The commission rate is computed from the pool utilization and is paid whenever an option is minted.
The value of the commission to be paid is the notional value of the options multiplied by the commission rate.
The comission is set to 20bps at % pool utilization and linearly increases to 60bps for pool utilizations %.
COMMISSION_RATE
^
| max commission = 60bps
60bps _ |_____
| .¯¯---__
| . ¯¯---__ min commission = 20bps
20bps _ | . ¯¯---____________________________
| . . .
+----+-------------------+------------------------+---> POOL_UTILIZATION
10% 50% 100%
Collateralization ratio (buying)
When buying an option, collateral is necessary in order to ensure that the buyer can pay the seller the cost of the option which starts at zero and can increase based on trading activity. The collateralization ratio for buying an option is set at 10% for pool utilization % and decreases linearly to 5% at a utilization of %.
BUY_COLLATERAL_RATIO
^
| max ratio = 10%
10% _ |_________________________
| ¯¯---__
| . ¯¯---__ min ratio = 5%
5% - | . ¯¯---________
| . . .
+------------------------+-------------------+----+---> POOL_UTILIZATION
50% 90% 100%
Collateralization ratio (selling)
The collateralization ratio for selling an option is set at a fixed 20% for pool utilization less than 50% and increases to 100% at 90% or more.
SELL_COLLATERAL_RATIO
^ max ratio = 100%
100% - | _________
| __-¯¯. .
| __-¯¯ . .
| min ratio = 20% __-¯¯ . .
20% _ |_________________________--¯¯ . .
| . . .
+------------------------+-------------------+----+---> POOL_UTILIZATION
50% 90% 100%
Buying Power Requirement (buying)
The buying power requirement for buying an option is simply: BPR = BUY_COLLATERAL_RATIO * NOTIONAL_VALUE + ACCUMULATED_LONG_PREMIUM
Buying Power Requirement (selling)
The buying power requirement (BPR) for selling an option is :
BPR for puts (with collateral denominated in numeraire):
.
BUYING .
_POWER <- ITM . OTM ->
_REQUIREMENT .
^ .
100% - |-__ BPR = 100% - (100% - SCR)*(price/strike)
| ¯¯--__ .
| ¯¯--__ .
| ¯¯--__ . min BRP = SELL_COLLATERAL_RATIO
SCR - | ¯¯--________________________________
| .
+-------------------------+---------------------------> current price
0 strike
BPR for calls (with collateral denominated in numeraire):
BUYING . __-- >100%
_POWER . __--¯¯
_REQUIREMENT <- OTM . ITM -> __--¯¯
^ . __--¯¯
100% - | - - - . - - - - - -__--¯¯ - - - - - - 100%
| . __--¯¯ .
| . __--¯¯ .
| min BRP . __--¯¯ BPR = SCR + (100% - SCR)*(price/strike - 1)
SELL_RATIO _ |_____________--¯¯ .
| . .
+------------+------------------------+---------------> current price
0 strike 2 * strike
The buying power requirement of a call can exceed the notional value of the minted option. However, users can deposit the asset as collateral in order to mitigate those risks.
BPR for calls (with collateral denominated in asset):
BUYING .
_POWER .
_REQUIREMENT <- OTM . ITM ->
^ .
100% - | - - - . - - - - - - - - - -___----- 100%
| . ______-------¯¯¯¯¯¯¯¯¯¯
| . ___----¯¯¯¯¯
| min BRP . -- BPR = 100% - (100% - SCR)*(strike/price)
SELL_RATIO _ |_____________¯
| .
+------------+----------------------------------------> current price
0 strike
Liquidation and forced exercise costs.
Liquidation Bonus
LIQUIDATION
_BONUS ^ max bonus = 100%
100% _ |___________
| .¯-_
| . ¯-_ no cost at 100% capitalization
| . ¯-_ /
| . ¯-_ /
| . ¯-_ /
0% - +----------+---------------+---------------+----------> MIN_CAPITAL_REQUIREMENT
| 50% 100% ¯-_ 150%
| ¯-_ .
| ¯-_ .
| ¯-_ . min bonus = -100%
-100% - | ¯-_______________
|
Force exercise cost
EXERCISE
_COST ^ max cost = 10.24%
1024bps _ |____
512bps _ | |____
256bps _ | . |____
128bps _ | . . |____
64bps _ | . . . |____
32bps _ | . . . . |____
16bps _ | . . . . . |____
8bps _ | . . . . . . |____
4bps _ | . . . . . . . |____
2bps _ | . . . . . . . . |____ min cost = 0.01%
1bps _ | . . . . . . . . . |____
+----+----+----+----+----+----+----+----+----+----+--->
1x 2x 3x 4x 5x 6x 7x 8x 9x 10x DISTANCE_FROM_STRIKE
(number of "widths")