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
- 18
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 18 closed, publicly disclosed Panoptic reports indexed on CoinBuggie. 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, Reentrancy, Oracle manipulation, 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
- Reentrancy findings disclosed against Panoptic
- Oracle manipulation 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: 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.
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: Premia calculation can cause DOS
In Panoptic's SemiFungiblePositionManager, the stored-premia update path performs premia0X64_base = mulDiv(collected0, totalLiquidity * 2**64, netLiquidity**2).toUint128(). When a position carries a high removedLiquidity relative to an extremely small netLiquidity ("dust"), the computed value overflows uint128 and the mint/burn call reverts with CastingError. Because amountToCollect must be non-zero to enter this path, the DoS only materializes once fees accrue in the tick range. The sponsor confirmed the finding and the judge lowered it to Medium, noting it needs very high-value or very high-supply tokens (such as 100Me18 PEPE) and depends on external market conditions rather than being purely attacker-driven.
Panoptic: Premium owed can be calculated as a very big number due to reentrancy on uninitialized pools
Panoptic's SemiFungiblePositionManager was vulnerable to a reentrancy attack on not-yet-registered Uniswap pools. Because SFPM mints the position's ERC1155 token before validating or initializing the underlying Uniswap pool, a contract wallet with a custom onERC1155Received handler could re-enter SFPM mid-mint, call initializeAMMPool to clear the pool's reentrancy lock, and burn the not-yet-completed position. That burn executes in an unchecked scope and underflows the chunk's removedLiquidity storage to near-maximum, and when the outer mint resumes, _updateStoredPremia derives an enormously overstated premiumOwed from that corrupted figure. The economic impact is corrupted premium accounting for that pool's range, which can cascade into broken positions and dependent external contracts relying on those stored premiums.
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: Panoptic pool can be non-profitable by specific Uniswap governanceLogic error$0
- Panoptic: Partial transfers are still possible, leading to incorrect storage updates, and the calculated account premiums will be significantly different from what they should beLogic error$0
- Panoptic: `SettleLongPremium` is incorrectly implemented: premium should be deducted instead of addedLogic error$0
- Panoptic: Attacker can steal all fees from SFPM in pools with ERC777 tokensReentrancy$0
- Panoptic: The Main Invariant "Fees paid to a given user should not exceed the amount of fees earned by the liquidity owned by that user." can be broken due to slight difference when computing collected feeReentrancy$0
- Panoptic: `PanopticFactory` uses spot price when deploying new pools, resulting in liquidity manipulation when mintingOracle manipulation$0
- Panoptic: `_updateSettlementPostBurn()` may not correctly reduce `s_grossPremiumLast[chunkKey]`Logic error$0
- Panoptic: Overflow in `CollateralTracker` allows minting shares for freeInteger overflow/underflow$0
- Panoptic: ` validateCallback()` is vulnerable to a birthday attackLogic error$0
- Panoptic: `removedLiquidity` can be underflowed to lock other user's depositsInteger overflow/underflow$0