Superposition — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Superposition, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 24
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 24 closed, publicly disclosed Superposition 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 Access control, Logic error, Front-running / MEV, Integer overflow / underflow, Price manipulation, across EVM-Solidity, Solana-Rust, 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
- Access control findings disclosed against Superposition
- Logic error findings disclosed against Superposition
- Front-running / MEV findings disclosed against Superposition
- Integer overflow / underflow findings disclosed against Superposition
- Price manipulation findings disclosed against Superposition
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Superposition: It's still not possible to set pool's protocol fees
Superposition's Seawater AMM left an admin fee-configuration function unimplemented after an earlier medium-severity finding (M-12) was supposedly fixed, so protocol operators still had no reachable path to set a pool's protocol fee split. The report traces the root cause to the missing `set_fee_protocol_C_B_D_3_E_C_35` implementation on the Solidity side rather than the Move-side executor. The sponsor argued the selector signature resolves correctly through the fallback dispatch, but the judge upheld the finding as a valid Medium, noting the sponsor fixed the related issues in principal. The recommended remediation is a wrapper function in `SeaWaterAMM.sol` that forwards to the admin executor via `directDelegate`.
Superposition: `createPoolD650E2D0` will not work due to mismatch in solidity and stylus function definitions
Superposition's SeawaterAMM exposes a Solidity wrapper `createPoolD650E2D0` that forwards to a Stylus (Rust) function `create_pool_D650_E2_D0`. The two declarations have incompatible signatures: the Solidity side declares five parameters (token, sqrtPriceX96, fee, tickSpacing, maxLiquidityPerTick) while the Stylus implementation expects only three (pool, price, fee). Any call to the wrapper therefore produces calldata that does not match the Stylus ABI, so the call always fails and the admin-initiated pool-creation pathway is unusable. The judge confirmed the finding and escalated it to High, rejecting the counterargument that a fallback function could technically create pools with the correct ABI, noting this aligns with prior audit rulings on this submission type.
Superposition: Tokens are pulled from users without verifying pool status contrary to requirement
Superposition's Seawater concentrated-liquidity library enforces an enabled-pool precondition inconsistently across the two entry points that pull tokens from users. update_position_internal() asserts pool.enabled is true before taking tokens, but adjust_position_internal() reaches the same erc20::take calls through adjust_position()/update_position() without any such check. As a result, liquidity can be added to disabled or frozen pools (e.g. markets disabled programmatically in the 9lives integration) even though the in-code documentation states additions require an enabled pool. The documented-versus-implemented discrepancy led the Code4rena judge to reinstate the finding at medium risk, and the sponsor subsequently fixed it in follow-up commits.
Superposition: No slippage control when withdrawing a position leads to loss of funds
Superposition's liquidity-withdrawal path was made insecure after the decr_position_09293696 function was removed, leaving update_position_C_7_F_1_F_740 with a negative delta as the only way to unwind a position. That path carries no slippage protection — the removed function's amount_0_min and amount_1_min bounds are gone — so a withdrawing user is exposed to being sandwiched by an attacker who moves the pool price, causing the victim to receive materially fewer tokens. The judge confirmed the finding as a tangible high-risk vulnerability and noted the protocol offers slippage protection for other interaction types, while the sponsor acknowledged it but declined to fix it in the short term citing their centralized sequencer; the warden pushed back that centralization does not eliminate MEV extraction.
Superposition: Users are incorrectly refunded when liquidity is insufficient
In Superposition's swap_2_internal AMM flow, when the first pool lacks sufficient liquidity to cover the full user-supplied amount, the contract correctly takes only the reduced amount_in from the sender — but then still executes a refund branch that transfers original_amount minus amount_in back to the sender. Because this shortfall was never collected from the swapper in the first place, the refund mints/credits value the user never paid, letting callers repeatedly route swaps through a low-liquidity pool and drain funds from the protocol. The judge confirmed the refund logic is extraneous, and the fix is to remove the redundant conditional refund block entirely.
Superposition: `get_fee_growth_inside` in `tick.rs` should allow for `underflow`/`overflow` but doesn't
Superposition's Rust-based Stylus implementation (`tick.rs`) of Uniswap V3 fee tracking incorrectly utilized checked subtraction (`checked_sub`) when calculating tick fee growth inside positions. Uniswap V3's fee growth tracking mechanism relies fundamentally on modular arithmetic integer overflow/underflow wrapping (i.e. `wrapping_sub`) to maintain correct state across global fee accumulators. Because `checked_sub` returns an error when global fee counters overflow, operations dependent on fee calculations (such as burns, collects, or position updates) would unexpectedly revert, locking liquidity and preventing fee claims.
All reports in this group
- Superposition: `decrPosition09293696` will not work due to incorrect function signatureLogic error$0
- Superposition: Volatile pools with higher fee structure cannot be created because of tick_spacingLogic error$0
- Superposition: When performing `swap` and the swap position does not cover `swap amount`, the base price of `sqrt_price` is set incorrectlyLogic error$0
- Superposition: Unintended under/overflow of the amount already swapped in/out due to unmatching logicInteger overflow/underflow$0
- Superposition: If liquidity is insufficient, users may need to pay more tokens in `swap2`Logic error$0
- Superposition: Missing `lower<upper` check in `mint_position`Integer overflow/underflow$0
- Superposition: No related function to set `fee_protocol`Logic error$0
- Superposition: Wrong liquidity formula usedLogic error$0
- Superposition: `swapOut` functions have invalid slippage check, causing user loss of fundsLogic error$0
- Superposition: `update_emergency_council_7_D_0_C_1_C_58()` updates nft manager instead of emergency councilLogic error$0
- Superposition: Parameter misordering in fee collection function causes denial of service and fee lossLogic error$0
- Superposition: Users can't remove liquidity while a pool is disabledAccess control$0
- Superposition: `_onTransferReceived()` does not work as intendedLogic error$0
- Superposition: Position's owed fees should allow underflow but it reverts instead, resulting in locked fundsInteger overflow/underflow$0
- Superposition: Lp's liquidity may be lost if re-org happensPrice manipulation$0
- Superposition: `bytes data` param is not passed to ERC721 recipient as expected by EIP-721Logic error$0
- Superposition: Unrevoked approvals allow NFT recovery by previous ownerLogic error$0
- Superposition: `swap_2` implementation will randomly revert due to improper check, root cause for failed test `ethers_suite_uniswap_orchestrated_uniswap_two`Logic error$0