Particle Protocol — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Particle Protocol, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 15
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 15 closed, publicly disclosed Particle Protocol 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 Front-running / MEV, Logic error, Reentrancy, Integer overflow / underflow, Governance attack, across EVM-Solidity. 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
- Front-running / MEV findings disclosed against Particle Protocol
- Logic error findings disclosed against Particle Protocol
- Reentrancy findings disclosed against Particle Protocol
- Integer overflow / underflow findings disclosed against Particle Protocol
- Governance attack findings disclosed against Particle Protocol
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Particle Protocol: AddLiquidity and decreaseLiquidity missing slippage protection
Particle's LiquidityPosition library wraps Uniswap V3's NFT position manager for minting, increasing, and decreasing liquidity. The mint path correctly forwards user-supplied amount0Min/amount1Min slippage bounds, but the increaseLiquidity and decreaseLiquidity helpers hardcode both minimums to zero and pass block.timestamp as the deadline. As a result, Uniswap's built-in 'Price slippage check' never reverts, so an MEV bot that frontruns or sandwiches these calls can force an unfavorable token ratio at execution. The judge upheld the finding as valid and the protocol confirmed the fix of adding user-controlled slippage parameters.
Particle Protocol: Malicious lender can manipulate the fee to force borrower pay high premium
Particle Protocol's leveraged Uniswap V3 NFT lending snapshots the position's feeGrowth into a lien at open time, but at close/liquidation re-reads the live spot feeGrowth from the position manager and charges the borrower's prepaid premium to cover the difference. Because that derivation uses manipulable spot state rather than a bounded value, a lender who dominates liquidity in the collateral's tick range can swap back and forth to inflate accrued fees and force the borrower to pay an inflated premium or be liquidated so the lender seizes it. The protocol acknowledged the manipulation angle but argued it is economically impractical unless the lender is the absolute dominant LP; the judge kept it at Medium, finding it infeasible only in most, not all, scenarios.
Particle Protocol: Excess tokens that are not accounted in the token premium portion stuck in the `ParticlePositionManager`
Particle Protocol stores each position's token premium as a uint24 basis-point fraction of collateral and margin, computed inside openPosition using a BASIS_POINT of only 1,000,000. Converting a premium back from this compressed portion representation loses precision because the division truncates, especially when the token has more decimals than the basis-point scale can represent, and the compressed value — not the exact premium — is persisted in the Lien record. As a result, the residual dust from every premium round-trip stays trapped in the ParticlePositionManager contract and can never be withdrawn by the LP or the treasury. A Foundry PoC exercising the full lifecycle (open, add premium, reclaim, liquidate, LP collect, treasury withdraw) leaves ~1123 USDC and ~0.516 WETH stranded in the contract. The protocol acknowledged the uint24 compression trade-off and the judge confirmed Medium severity on the basis that the dust will accumulate materially over the protocol's lifetime.
Particle Protocol: reclaimLiquidity() Malicious borrowers can force LPs to be unable to retrieve Liquidity by closing and reopening the Position before it expires
Particle Protocol lets LPs request retrieval of lent liquidity by setting a renewalCutoffTime through reclaimLiquidity(), after which liquidatePosition() can force-close a position once the loan term passes. However, openPosition() never checks that cutoff, so a borrower may close and immediately reopen a position just before its term ends, resetting lien.startTime and extending the LP's wait by a full new loan term. Repeating this cycle indefinitely lets a malicious borrower permanently occupy liquidity, since the only cost is the position opening fee. The sponsor confirmed the finding and endorsed gating openPosition() on the renewal cutoff plus a retrieval window.
Particle Protocol: Position can be opened even when the particle position manger does not hold the Uniswap V3 Position NFT
Particle Protocol lets users borrow against Uniswap V3 LP positions, but the open-position code path validates only Uniswap's operator-approval semantics rather than confirming the ParticlePositionManager actually holds the NFT. Because Uniswap V3's decreaseLiquidity and collect calls honor a plain approval, a borrower can open a leveraged position against an NFT that was merely approved to the manager and reduce the owner's liquidity for the full loan term while paying enough premium to avoid liquidation. The sponsor confirmed the finding and committed to adding an ownership check on position open.
Particle Protocol: malicious borrowers can follow reclaimLiquidity() then execute addPremium() to invalidate renewalCutoffTime
Particle Protocol's loan lifecycle lets an LP force-close an expired loan by calling reclaimLiquidity(), which records the current timestamp as the renewal cutoff. The addPremium() renewal guard only revokes when the cutoff is strictly greater than the lien's startTime, so at equality a borrower can still add premium. A malicious borrower monitoring the mempool can, in the same block as an LP's reclaim, call addPremium() to reset lien.startTime to block.timestamp, making it equal to the cutoff. Because liquidatePosition() only force-closes when startTime is strictly less than the cutoff, the liquidation reverts with LiquidationNotMet, letting the borrower trap the LP's liquidity and keep an unhealthy position open. The protocol confirmed the one-line fix changing '>' to '>=', and the judge finalized severity at medium after debate over whether the position could still be liquidated via uncovered-fees branch.
All reports in this group
- Particle Protocol: Underflow could happened when calculating Uniswap V3 position's fee growth and can cause operations to revertInteger overflow/underflow$0
- Particle Protocol: collectLiquidity() Lack of can specify recipient leads to inability to retrieve token1 after entering the blacklist of token0Logic error$0
- Particle Protocol: liquidatePosition() liquidator can construct malicious data to steal the borrower's profitLogic error$0
- Particle Protocol: Impossible to open a position with a large `marginTo`Integer overflow/underflow$0
- Particle Protocol: Modifying the loan term setting can default existing loansGovernance attack$0
- Particle Protocol: openPosition() Lack of minimum token0PremiumPortion/token1PremiumPortion limitLogic error$0
- Particle Protocol: Add premium doesn't collect feesLogic error$0
- Particle Protocol: openPosition() use stale feeGrowthInside0LastX128/feeGrowthInside1LastX128Logic error$0
- Particle Protocol: Liquidation condition should not factor the liquidation reward into the premiumsLogic error$0