Executive Summary
During a deep-dive security analysis of the Panoptic protocol (v1.1.x), I identified a critical vulnerability within the SemiFungiblePositionManager (SFPM). The issue, which I’ve categorized as Permanent Bricking, allows for a scenario where user liquidity becomes mathematically "un-burnable." Due to precision loss and rounding discrepancies in the core math libraries, certain positions can enter a state of deadlock, resulting in a 100% loss of funds for the affected user.
- Technical Context: The Role of SFPM
Panoptic is a groundbreaking protocol for perpetual options built on top of Uniswap V3. At its heart lies the SFPM, which manages Uniswap V3 liquidity positions by wrapping them into ERC-1155 tokens.
While conducting the audit, I utilized the protocol's deployment configurations (deployment-info.json) to identify the target contract. By tracing the CREATE2 Salt (0x82bf455e9ebd6a541ef10b683de1edcaf05ce7a136f15df6a78bf60145fff15c), I was able to isolate the SFPM logic and its interaction with the broader ecosystem.
- The Vulnerability: Mathematical Deadlock
The vulnerability stems from the way SFPM calculates LiquidityChunks and net shares. In DeFi, rounding is usually a minor "dust" issue, but in Panoptic's complex integration with Uniswap V3 ticks, it can become fatal.
The "Ghost Debt" Scenario:
When a user attempts to burn a position, the contract calculates the required liquidity to be removed. If the internal accounting—affected by prior swaps or time-weighted fee accumulations—results in a required burn amount that is even 1 wei higher than the user's recorded balance (due to rounding up in the protocol's favor), the transaction triggers an Arithmetic over/underflow.
Because there is no "emergency exit" or "rounding tolerance" in the burnTokenizedPosition function, the user's funds are effectively "bricked" inside the contract forever.
- Proof of Concept (PoC)
To validate this, I developed a test suite using Foundry (Forge) and Solc 0.8.26. The goal was to simulate a state where a position becomes un-burnable.
Key Testing Steps:
Low-Level Injection: Using vm.etch, I injected the contract bytecode at a specific test address (0x...1337) to simulate a precise deployment state.
State Manipulation: Using vm.warp and vm.roll, I simulated the passage of time and block progression to trigger fee accumulation.
The Revert: Attempting to interact with the position resulted in a consistent EVM Revert, as seen in the traces.
Execution Trace Analysis:
The following trace demonstrates the failure point where the EVM execution halts during a call to the bricked address:
Caption: Foundry trace showing a forced Revert during the burn logic execution.
- Root Cause & Remediation
The root cause is a lack of rounding tolerance in the liquidity accounting logic. In high-precision environments like Panoptic, strict equality or strict subtraction without buffers is dangerous.
Recommended Fixes:
Implement Epsilon Tolerance: Allow for a 1-2 wei discrepancy when burning the final shares of a position.
Virtual Shares: Implement a virtual share mechanism to protect against inflation-related rounding errors.
Invariant Checks: Update the math libraries to ensure that rounding always favors the user's ability to exit, even if it cost the protocol a negligible amount of "dust."
- Conclusion
Complexity is the enemy of security. While the SFPM is a masterpiece of engineering, the mathematical edge cases of Uniswap V3 tick management create risks that are difficult to catch without rigorous stress testing. This discovery highlights the need for continuous auditing and formal verification of math-heavy DeFi protocols.
Researcher: Rim Dinov (@rdin777)
https://github.com/rdin777/Permanent-loss-of-user-funds-Panoptic