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

Scope

Smart contracts

In-Scope Targets:

• Repository: https://github.com/panoptic-labs/panoptic-v1-core
• Commit: f81567ac9b6cf1faa3c93813d1eab75c7b611ab0

• SemiFungiblePositionManager, PanopticFactory and any contracts deployed by PanopticFactory. (Contract addresses listed here)
• The contracts are only on Ethereum Mainnet and Unichain

If you discover a vulnerability in any component that is not explicitly listed but poses a risk to user funds, user data, or the integrity of the system, you may submit it for consideration. The team will review such submissions on a case-by-case basis.

Out-of-Scope

Smart contract

• Report 1

• Report 2

• Report 3

• Report 4

• Report 5

• Report 6

• 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 aimum 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.

• Options sellers may be forced to forfeit premium they have earned if it is not settled by the users that purchase their options

• Pools that do not meet the criteria set here: http://docs.panoptic.xyz/docs/developers/pool-criteria

• Weird ERC20 Checklist

Feature	Supported
Missing return values	✅ Yes
Fee on transfer	❌ No
Balance changes outside of transfers	❌ No
Upgradeability	❌ No
Flash minting	✅ Yes
Pausability	❌ No
Approval race protections	✅ Yes
Revert on approval to zero address	✅ Yes
Revert on zero value approvals	✅ Yes
Revert on zero value transfers	✅ Yes
Revert on transfer to the zero address	✅ Yes
Revert on large approvals and/or transfers	❌ No
Doesn't revert on failure	❌ No
Multiple token addresses	❌ No
Low decimals (<6)	✅ Yes
High decimals (>18)	✅ Yes
Blocklists	❌ No

• Automated findings by Lightchaser
  • Panoptic report

Prohibited Actions

• No Unauthorized Testing on Production Environments:
  Do not test vulnerabilities on mainnet or public testnet deployments without prior authorization. Use local test environments or private test setups.

• No Public Disclosure Without Consent:
  Do not publicly disclose details of any vulnerability before it has been addressed and you have received written permission to disclose.

• No Exploitation or Data Exfiltration:
  Do not exploit the vulnerability beyond the minimum steps necessary to demonstrate the issue. Do not access private data, engage in social engineering, or disrupt service.

• No Conflict of Interest:
  Individuals currently or formerly employed by Panoptic, or those who contributed to the development of the affected code, are ineligible to participate.

Disclosure Requirements

You must report vulnerabilities directly on Cantina. Please include:

• A clear description of the vulnerability and its impact.
• Steps to reproduce the issue, ideally with a proof of concept.
• Details on the conditions under which the issue occurs.
• Potential implications if the vulnerability were exploited.

Reports should be made as soon as possible—ideally within 24 hours of discovery.

Eligibility

To be eligible for a reward, you must:

• Be the first to report a previously unknown, non-public vulnerability within the defined scope.
• Provide sufficient information to reproduce and fix the vulnerability.
• Not have exploited the vulnerability in any malicious manner.
• Not have disclosed the vulnerability to third parties before receiving permission.
• Comply with all Program rules and applicable laws.

You must also be of legal age in your jurisdiction and not be a resident in a country under sanctions or restrictions, as required by applicable laws.

Severity and Rewards

Vulnerabilities are classified using two factors: Impact and Likelihood. The combination of these factors determines the severity and guides the reward amount.

Risk Classification Matrix

Severity Level	Impact: High	Impact: Medium
Likelihood: High	Critical	High
Likelihood: Medium	High	-

Critical:

• Manipulation of governance voting result deviating from voted outcome and resulting in a direct change from intended effect of original results
  • Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
  • Permanent freezing of funds
  • Protocol insolvency
  • Once TVL exceeds $1M, switch to 25-100% of total TVL directly at risk

High:

• Theft of unclaimed yield
• Permanent freezing of unclaimed yield
• Temporary freezing of funds for more than 1 week
• Once TVL exceeds $1M switch to 1-25% TVL directly at risk

Medium:

• Smart contract unable to operate due to lack of token funds
• Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)
• Unbounded gas consumption

Low:

• Contract functions affected but does not result in loss of fund or impact severely

Impact Definitions:

• Critical: Vulnerabilities that can lead to severe loss of user funds, permanent system disruption, or widespread compromise.
• High: Vulnerabilities that cause notable financial loss or significantly harm user trust, but on a lesser scale than Critical.
• Medium: Vulnerabilities that lead to limited financial damage or moderate system impact.
• Low/Informational: Findings that pose minimal direct risk but reflect areas for improvement or best practices.

Likelihood Definitions:

• High: Very easy to exploit or highly incentivized.
• Medium: Exploitation is possible under certain conditions.
• Low: Difficult to exploit or requires highly specific conditions.

Rewards

Panoptic Smart contracts

Severity Level	Maximum Payout	Minimum Payout (In effect before TVL reaches $1M)
Critical	$250,000	$50,000
High	$50,000	$10,000

Other Terms

By submitting a report, you grant Panoptic the rights necessary to investigate, mitigate, and disclose the vulnerability. Reward decisions and eligibility are at the sole discretion of Panoptic. The terms, conditions, and scope of this Program may be revised at any time. All participants are responsible for reviewing the latest version before submitting a report.