Superfluid Locker System — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Superfluid Locker System, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 7
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 7 closed, publicly disclosed Superfluid Locker System 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, Reentrancy, Integer overflow / underflow, 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
- Logic error findings disclosed against Superfluid Locker System
- Reentrancy findings disclosed against Superfluid Locker System
- Integer overflow / underflow findings disclosed against Superfluid Locker System
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Superfluid Locker System: Incorrect initial deposit calculation may cause cancelProgram to revert
FluidEPProgramManager.cancelProgram() recomputes the treasury refund using live Superfluid governance parameters (minimum deposit and liquidation period) at cancellation time, rather than the values locked in when the program was funded. If governance raises either parameter, the recalculated buffer exceeds the originally funded deposit, so the contract tries to return more tokens than it holds and the cancellation reverts; if parameters are lowered, the contract returns less and excess tokens are stranded. The finding was acknowledged by the team as a medium-severity issue but not fixed.
Superfluid Locker System: Staked tokens inside FluidLocker can be withdrawn without calling Unstake
The Superfluid FluidLocker contract lets a locker owner move staked tokens into a Uniswap LP position via provideLiquidity, and later pull those tokens back through withdrawLiquidity, all without ever calling unstake. Because provideLiquidity never checks getAvailableBalance, the locker's bookkeeping continues to count the tokens as staked even after the underlying funds have left the contract. Since staking rewards accrue indefinitely against a phantom balance, an attacker can farm reward points on tokens that are no longer locked, diluting or redirecting future reward distributions.
Superfluid Locker System: User can instantly `unlock` most of his funds with less fee when he is unique `staker`/`liquidityProvider`
FluidLocker's instant-unlock path imposes an 80% penalty that is supposed to be distributed to the staker and LP distribution pools. Because _instantUnlock distributes the penalty to those pools, a locker that happens to be the sole staker or sole liquidity provider receives the entire penalty back into its own balance, effectively canceling the fee. An attacker can therefore unlock virtually all of his funds immediately with only a negligible dust cost, defeating the locker's intended vesting/penalty mechanism.
Superfluid Locker System: Locker owners can leverage low liquidity pools to bypass the tax mechanism
The FluidLocker withdrawal path lets locker owners convert their locked SUP into Uniswap v3 LP positions and then redeem them. Because withdrawLiquidity values the ETH side by the current (manipulable) pool price rather than a manipulation-resistant measure, an owner can flashloaned-swap a low-liquidity pool so it is overwhelmingly ETH-concentrated, withdraw nearly all value as untaxed ETH, then swap the SUP back — bypassing the protocol's up-to-80% exit tax. The Sherlock finding was acknowledged by the team but declined for fixing at that time.
Superfluid Locker System: An attacker may DoS user Fluid balance increases by frontrunning `FluidLocker::claim()` calls and calling `EP_PROGRAM_MANAGER::batchUpdateUserUnits()` directly
A griefing/front-running vulnerability in the Superfluid FluidLocker system lets an attacker spend a user's signed claim nonce in advance. FluidLocker::claim() first connects to the fluid pool and then calls EPProgramManager::updateUserUnits() to validate the signature and credit points; because updateUserUnits can be invoked directly with the same signature, a frontrunner can consume the nonce so the user's claim reverts. Since Fluid balance only grows on a successful claim, the victim ends up with zero Fluid, cannot stake for points, and misses a share of large incoming tax distributions that are paid pro-rata to staked units. The attacker economically gains a larger share of those distributions, and the issue was fixed by adding a separate pool-connection method.
Superfluid Locker System: `FluidLocker::_getUnlockingPercentage()` divides before multiplying, suffering a significant precision error
The FluidLocker computes its unlocking percentage by dividing before multiplying inside `_getUnlockingPercentage()`, which truncates a constant 0.4821 component from the division result. That truncation propagates into a persistent ~1 BPS discrepancy: on maximum-duration unlocks the returned value lands at 9999 BPS instead of 10000 BPS, and the missing basis point is redirected to the protocol's tax pool. Because the arithmetic error occurs on every withdrawal that uses a vesting period, the loss recurs frequently and accumulates; a 1e5 USD unlock forfeits about 10 USD. The maintainers confirmed the finding and fixed it by reordering the operations to multiply before dividing, which cannot overflow.