Super DCA

We are excited to announce that 6 of the 11 teams awarded @OptimismGov Season 8 OP Audit Grants applied with Sherlock, the most of any audit firm. We are proud to continue to support growth and security in the @Optimism ecosystem through their generous grant program. Congratulations to our awarded partner teams! @40acres_Finance - 75,000 OP @ArcadiaFi - 53,950 OP @HighwayFi - 52,800 OP @ownfinanceHQ - 48,250 OP @super_dca - 33,000 OP @metromxyz - 28,000 OP

Welcome back to Sherlock’s Vulnerability Spotlight, where we highlight an impactful vulnerability uncovered during a Sherlock audit. This week, we examine an unfair rewards distribution vulnerability found in the @super_dca Super DCA Liquidity Network contest by @vinicaboy and @patitonar. Summary of the Vulnerability In the SuperDCA protocol, rewards for liquidity providers are distributed during liquidity operations (add/remove) through the _handleDistributionAndSettlement() function, which uses Uniswap v4's donate mechanism. This mechanism distributes rewards only to in-range LPs at the current slot0.tick when distribution occurs. The problem is that rewards accumulated over an extended period are distributed based on the current tick position at the moment of distribution, regardless of which positions actually provided active liquidity during the reward accrual period. Attack Steps 1. Initial Setup and Monitoring - An attacker deploys a liquidity position with an extremely tight tick range (e.g., single tick width) - The position is placed out of range at a predictable tick where the attacker can manipulate the price - The attacker monitors the pool for reward accumulation without distribution events 2. Accumulation Period - Time passes and rewards accrue in the staking contract based on mintRate and elapsed time - Multiple swaps occur naturally, moving the tick within the range where honest LPs are active - No liquidity operations trigger distribution, so rewards continue to accumulate 3. Price Manipulation (Tick Movement) - The attacker executes a swap to move the current slot0.tick to their predetermined tick (t2) - The attacker's tight-range position is now the only (or dominant) in-range position - Transaction structure: swap → addLiquidity/removeLiquidity → swap back (can be atomic) 4. Distribution Trigger - With the tick now at t2, the attacker triggers a liquidity operation (add or remove) - This calls _beforeAddLiquidity()` оr _beforeRemoveLiquidity()` hooks - The hooks execute _handleDistributionAndSettlement(): - Calls staking.accrueReward(otherToken) to calculate accumulated rewards - Mints new DCA tokens as rewards - Calls `poolManager.donate()` to distribute rewards 5. Reward Theft via Donate Mechanism - The `donate()` function distributes rewards to in-range LPs at the current tick (t2) - The attacker's tight range means they receive maximum concentration of the donated tokens - Honest LPs who provided liquidity during accrual receive nothing or minimal rewards 6. Reversion and Exit - The attacker executes another swap to move the tick back to its original position - The attacker exits with rewards that should have gone to honest LPs - Net cost: gas fees + swap fees (can be calculated to ensure profitability) - Net gain: All accumulated rewards for the period The Root Cause The vulnerability stems from a fundamental mismatch between when rewards accrue and how rewards are distributed. Rewards accrue continuously based on time elapsed (block.timestamp - lastMinted) and are calculated for the entire period since the last distribution, regardless of which LPs were in-range. The protocol has no way to: - Track which positions were in-range during the reward accrual period - Weight reward distribution based on time spent in-range - Prevent manipulation of the tick before distribution - Attribute rewards to positions that earned them over time This results in a last-position-wins scenario where whoever is in-range at distribution time captures rewards, regardless of who deserved them. Distribution only occurs during liquidity operations, creating predictable trigger points that attackers can exploit. What's the Impact? Direct Economic Loss: - Honest LPs lose rewards - Disproportionate gains for attackers - Compounding effect over time The Mitigation The recommended fix requires implementing a mechanism to track and account for which positions provided active liquidity during reward accrual periods. Option 1: Time-Locked Distribution with Active Liquidity Tracking Option 2: Swap-Triggered Reward Distribution Critical Requirements for Any Mitigation: • Time-weighted tracking • Manipulation resistance • Atomicity prevention • Fair reward attribution We are proud to have helped secure @super_dca through this discovery. When it absolutely needs to be secure, Sherlock is the right choice.