Super DCA Liquidity Network — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Super DCA Liquidity Network, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed Super DCA Liquidity Network 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, 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 Super DCA Liquidity Network
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Super DCA Liquidity Network: Attackers will steal rewards from legitimate pools by making duplicate pools for listed token.
The Super DCA gauge accrues community rewards globally per reward token inside the Uniswap V4 hook `_handleDistributionAndSettlement`, without verifying that the pool triggering settlement is the single legitimately-listed pool for that token. Because Uniswap V4 permits multiple pools for the same token pair under different fee tiers or configurations, an attacker can spin up an unlisted duplicate pool with the same gauge hook, add minimal liquidity to trigger reward accrual, and divert the community-share rewards that were intended for the legitimate pool's liquidity providers. Repeated add/remove liquidity cycles let the attacker drain those rewards. The protocol team acknowledged and fixed the issue (confirmed PR), recommending pool-specific listing validation.
Super DCA Liquidity Network: Fee collection will always fail for initial positions of SuperDCA pools that contain native tokens
Super DCA's gauge protocol builds Uniswap v4 pools and lists them for DCA campaigns, harvesting accumulated trading fees to pay rewards. Uniswap v4 encodes native ETH as address(0) using the Currency primitive, but the fee-collection logic in SuperDCAListing.sol treats every pool currency as an ERC20 and calls IERC20(...).balanceOf() to sample before/after balances. When a pool pairs a DCA token against native ETH, that call resolves to IERC20(address(0)).balanceOf(), which reverts because address(0) has no code. As a result admin fee collection for the initial locked LP position permanently fails, locking all accumulated trading fees for every ETH-paired pool, which tends to be high-volume and therefore a meaningful recurring revenue loss. The team confirmed the issue and fixed it in a pull request to the gauge repository.
Super DCA Liquidity Network: Manager can retroactively apply new rate to past time, misallocating emissions - Invariant Broken
SuperDCAStaking distributes emissions to stakers through an accruing rewardIndex whose exact increment formula is contractually guaranteed by the protocol readme. The guard in setMintRate() re-assigns the emission rate without first settling rewards for the time elapsed since lastMinted. As a result the entire past interval is priced at the new rate rather than the rate that was in effect, so a rate change retroactively re-prices already-earned rewards. This lets a manager or any holder of the rate-setter role backdate a rate change, overpaying or underpaying stakers and breaking the documented invariant. The protocol acknowledged and fixed the issue in the referenced pull request.
Super DCA Liquidity Network: System underpays cashback on BNB: hardcoded “USDC = 6 decimals” causes 1e12× underpayment when USDC is 18-dec
Super DCACashback.sol underpays cashback on BNB Chain because a fixed divider hardcodes the assumption that USDC has 6 decimals, dividing 1e18-precision amounts by 1e12. On BNB Chain the configured USDC is an 18-decimal token, so every claim is scaled down by 1e12, paying users about one-trillionth of the owed cashback. The bug needs no attacker and fires deterministically on every claim, exposing all users on affected chains until fixed. The team acknowledged the issue and merged a token-decimal-aware fix in a follow-up pull request.