Panoptic / panoptic-core
Panoptic is a decentralized and permissionless options trading protocol built on Uniswap V3 and V4. We’ve taken a new and innovative approach that allows us to adapt a novel form of perpetual options into a DeFi protocol with oracle-free settlement. Instead of relying on thin and centralized order books, Panoptic takes the form of an advanced lending market for Uniswap positions.
Uniswap V3 and V4 LP positions have payoff curves that are strikingly similar to those of traditional sold (short) puts. Fees collected by positions are essentially a streaming options premium (which Panoptic calls streamia) that compensate Uniswap LPs for the risks their positions carry.
The Panoptic protocol leverages this unique property of Uniswap LP positions to offer a full spectrum of options exposure to every Uniswap V3 pool in existence and many Uniswap V4 pools. Because Uniswap LPs have payoffs similar to selling options, we can create a payoff similar to buying an option by enabling traders to borrow Uniswap V3/V4 positions from LPs and short them by removing that liquidity — compensating those LPs with the fees (streamia) that would have been collected.
Similarly, options sellers can create both calls and puts by borrowing one of the tokens in a Uniswap pool and swapping them into the constituent tokens of their position. These strategies are time-tested and have been employed by savvy retail and professional traders alike.
Panoptic takes these options strategies to the next level. We created integrated, undercollateralized, and capital-efficient lending infrastructure for both ordinary tokens and Uniswap V3/V4 LPs. This infrastructure supports the management of highly advanced multi-leg positions.
This enables several firsts in the DeFi space:
- Leveraged options selling and Uniswap liquidity provision
- Leveraged options buying
- A unique commission-based fee structure that options traders will find refreshingly familiar
Prize distribution and scoring
-
Total Prize Pool: $80,000
-
Primary Prize Pool: $75,000
-
The prize distribution has 2 possible triggers:
- If one or more valid medium severity findings are found, the total pot size is $50,000
- If one or more valid high severity findings are found, the total pot size is $80,000
-
$5,000 of the total prize pot is reserved for Low Severity findings. These reports are judged based on quality and reviewers are then ranked from 1st to 5th for the purpose of prize allocation.
- 1st: $2.5k
- 2nd: $1.5k
- 3rd: $750
- 4th: $375
- 5th: $375
-
Scoring described in the competition scoring page.
-
Findings Severities described in detail on our docs page.
Severity conditions
The following conditions apply for High/Medium severity findings:
- Findings must be executable on one of the top 100 Ethereum Mainnet Uniswap V3 pools by TVL (assuming a V4 pool (meeting the hook criteria outlined in the scoping section) with the same tokens, any fee tier or tick spacing, and an identical liquidity distribution (rounded to the nearest tickSpacing) exists. While PoCs do not have to recreate these conditions exactly, a realistic description of the conditions should be provided that the finding is valid on a pool meeting the above criteria.
Follow-up competition
- Researchers who submit valid H/M findings in this competition will be invited to another Panoptic private competition of a prize pool of $20,000
Documentation
Scope
- Repository: https://github.com/panoptic-labs/panoptic-v1-core
- Commit: 58bc7f2a73a1c6df43daf043b2ad59dae776127b
- Total LOC: 4707
- Files:
- Everything in the
contractsfolder - Partially In-scope:
FactoryNFT.sol(inherited by PanopticFactory),MetadataStore.sol(inherited by PanopticFactory)Pointer.sol(a library). NONE of the functionality in these 3 contracts or the factory's NFT/ERC721 implementation/issuance is in scope. However, the contracts themselves must technically be included in the scope because of their usage in the core contracts, so issues involving any core PanopticFactory functionality being compromised due to the introduction of those contracts are valid.
- Everything in the
Build Instructions
-
Note that you will need bun.sh and getfoundry.sh installed
-
git clone https://github.com/panoptic-labs/panoptic-v1-core.git \--recurse-submodules -
git checkout v1.1.x -
npm i -
bun run ./metadata/compiler.js -
forge build
Basic POC Test
Out of scope
- Report 1
- Report 2
- Report 3
- Report 4
- Transfers of ERC1155 SFPM tokens are disabled.
- Construction helper functions (prefixed with add) in the TokenId library and other types do not perform extensive input validation. Passing invalid or nonsensical inputs into these functions or attempting to overwrite already filled slots may yield unexpected or invalid results. This is by design, so it is expected that users of these functions will validate the inputs beforehand.
- Tokens with a supply exceeding 2^127 - 1 are not supported.
- If one token on a pool is broken/does not meet listed criteria/is malicious there are no guarantees as to the security of the other token in that pool, as long as other pools with two legitimate and compliant tokens are not affected.
- Price/oracle manipulation that is not atomic or requires attackers to hold a price across more than one block (i.e., to manipulate a Uniswap observation, you need to set the manipulated price at the end of one block, and then keep it there until the next block) is not in scope
- Attacks that stem from the TWAP being extremely stale compared to the market price within its period (currently 10 minutes)
- As a general rule, only price manipulation issues that can be triggered by manipulating the price atomically from a normal pool/oracle state are valid
- Given a small enough pool and low seller diversity, premium manipulation by swapping back and forth in Uniswap is a known risk. As long as it's not possible to do it between two of your own accounts profitably and doesn't cause protocol loss, that's acceptable
- Front-running via insufficient slippage specification is not in scope
- It's known that liquidators sometimes have a limited capacity to force liquidations to execute at a less favorable price and extract some additional profit from that. This is acceptable even if it causes some amount of unnecessary protocol loss.
- It's possible to leverage the rounding direction to artificially inflate the total gross premium and significantly decrease the rate of premium option sellers earn/are able to withdraw (but not the premium buyers pay) in the future (only significant for very-low-decimal pools, since this must be done one token at a time).
- It's also possible for options buyers to avoid paying premium by calling settleLongPremium if the amount of premium owed is sufficiently small.
- Premium accumulation can become permanently capped if the accumulator exceeds the maximum value; this can happen if a low amount of liquidity earns a large amount of (token) fees
- The liquidator may not be able to execute a liquidation if MAX_POSITIONS is too high for the deployed chain due to an insufficient gas limit. This parameter is not final and will be adjusted by deployed chain such that the most expensive liquidation is well within a safe margin of the gas limit.
- It's expected that liquidators may have to sell options, perform force exercises, and deposit collateral to perform some liquidations. In some situations, the liquidation may not be profitable.
- In some situations (stale TWAP tick), force exercised users will be worse off than if they had burnt their position.
- For the purposes of this competition, assume the constructor arguments to the CollateralTracker are: 20, 2_000, 1_000, -128, 5_000, 9_000, 20, manager_address
- Depending on the token, the amount of funds required for the initial factory deployment may be high or unrealistic
- It is feasible for the share supply of the CollateralTracker to approach 2**256 - 1 (given the token supply constraints, this can happen through repeated protocol-loss-causing liquidations), which can cause various reverts and overflows. Generally, issues with an extremely high share supply as a precondition (delegation reverts due to user's balance being too high, other DoS caused by overflows in calculations with share supply or balances, etc.) are not valid unless that share supply can be created through means other than repeated liquidations/high protocol loss.
- Only pools with hooks that have the permissions `before/afterInitialize`, `before/afterDonate`, and `before/afterSwap/returnDelta` are in scope. Hooks with additional permissions can only be considered to the extent of their effects on the operation of non-hook pools and pools with approved permissions.
- Issues where losses (to a user undertaking a given action) can be avoided by setting the ITM swap flag to false (tickLimitLow < tickLimitHigh) are out of scope.
- For any PanopticPool, it should be assumed that a Uniswap V3 pool with the same tokens is used as the external oracle contract. High and Medium submissions meeting the top-100 pool criteria should use the corresponding top 100 V3 pool as the oracle contract.
- If an insolvent account wants to prevent themselves from being liquidated or prevent an account with long positions near MIN/MAX tick from being closed or prevent the full-range liquidity add during a factory deployment, they can sell tickSpacing-wide positions from another account, buy them from an insolvent account, then add more liquidity (outside the protocol) such that the maxLiquidityPerTick would be exceeded if the removed liquidity from the long positions was added back (the capital requirements for this are very low near MIN_TICK/MAX_TICK). See L-02 on Uniswap's Certora audit.
- Pausing, Upgradabilty, or enabling of fees of any of the external integrations are out of scope.
-
Weird ERC20 Checklist
- Automated findings by Lightchaser
Contact Us
For any issues or concerns regarding this competition, please reach out to the Cantina core team through the Cantina Discord.
Summary
Status
CompletedTotal reward:
$80,000
Findings submitted:
55
Start date:
11 Oct 2024 2:00pm (local time)
End date:
25 Oct 2024 8:00pm (local time)