Panoptic — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Panoptic, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 10
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 10 closed, publicly disclosed Panoptic reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Integer overflow / underflow, Oracle manipulation, Reentrancy, across EVM-Solidity, Move. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Panoptic
- Integer overflow / underflow findings disclosed against Panoptic
- Oracle manipulation findings disclosed against Panoptic
- Reentrancy findings disclosed against Panoptic
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Panoptic: Incorrect validation during checking liquidity spread
Panoptic contains a vulnerability where option buyers can avoid paying premiums by creating positions that result in zero net liquidity. This occurs because the protocol's liquidity spread validation incorrectly ignores zero net liquidity states, failing to trigger necessary fee settlement checks. Consequently, when these positions are closed, the fee accounting logic fails to compute the correct premium, leading to financial loss for the protocol liquidity providers.
Panoptic: Overflow in `CollateralTracker` allows minting shares for free
The `CollateralTracker` contract contains a critical integer overflow vulnerability within the `previewMint` function. By performing share-to-asset calculations inside an `unchecked` block, the contract allows the `shares * DECIMALS` expression to wrap around when a large input is provided. This causes the function to return a near-zero requirement for underlying assets, enabling malicious users to mint massive quantities of shares for virtually free. Consequently, attackers can exploit this to drain the protocol's collateral reserves.
Panoptic: `PanopticFactory` uses spot price when deploying new pools, resulting in liquidity manipulation when minting
The PanopticFactory contract relies on the Uniswap V3 spot price when initializing new pools to determine liquidity requirements. Because this spot price is derived directly from the current state (slot0), it is highly vulnerable to flash loan-based price manipulation. An attacker can artificially skew the price, forcing the protocol to initialize pools with incorrect and unbalanced liquidity distributions, which negatively impacts the protocol's pool setup integrity.
Panoptic: When Burning a Tokenized Position `validate` should be done before flipping the `isLong` bits in `_validateAndForwardToAMM()`
Panoptic's position management contains a logic flaw that prevents users from burning specific complex tokenized positions. During the burn process, the system incorrectly modifies the state of the position's legs before performing necessary validation checks. This premature modification causes the validation logic to misinterpret the position's risk parameters, leading to a permanent revert for affected positions and effectively causing a Denial-of-Service for those specific user assets.
Panoptic: Wrong leg `chunkKey` calculation in `haircutPremia` function
The Panoptic protocol contains a logic error in its liquidation accounting process that results in incorrect premium distributions. During the liquidation of positions, the haircutPremia function fails to properly calculate the storage keys for multi-leg positions, instead defaulting to the index of the first leg. This leads to inaccurate updates to the settledTokens accumulator, resulting in the miscalculation of tokens owed to option sellers and potential financial loss for the protocol and its users.
Panoptic: `CREATE2` address collision during pool deployment allows for complete draining of the pool
The Panoptic protocol allows users to supply a custom `salt` when deploying new pools via `CREATE2`, making the contract address predictable. An attacker can exploit this by brute-forcing a large number of salt values to find a collision between a future, legitimate pool address and a wallet contract they control. By successfully generating such a collision, the attacker can deploy a malicious contract at the intended pool address, potentially enabling them to drain user deposits once sufficient liquidity has been added to the pool.
All reports in this group
- Panoptic: Removed liquidity can overflow when calling `SemiFungiblePositionManager.mintTokenizedPosition` functionReentrancy$0
- Panoptic: `_validatePositionList()` does not check for duplicate tokenIds, allowing attackers to bypass solvency checksOracle manipulation$0
- Panoptic: `SettleLongPremium` is incorrectly implemented: premium should be deducted instead of addedLogic error$0
- Panoptic: `_updateSettlementPostBurn()` may not correctly reduce `s_grossPremiumLast[chunkKey]`Logic error$0