GoodDollar `GoodCompoundStaking` Exploit — Slippage-Free COMP Reward Swap into a Pre-Manipulated Pool

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2023-12-GoodCompound_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/GoodCompound_exp.sol.

Vulnerability classes: vuln/defi/slippage · vuln/oracle/spot-price

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo does not whole-compile under forge test, so this PoC was extracted standalone). Full verbose trace: output.txt. Verified vulnerable sources under sources/.

Key info#

TL;DR#

GoodDollar's GoodCompoundStaking contracts earn COMP from supplying assets to Compound. When interest is harvested, the staking contract sells its entire COMP reward balance on Uniswap V2 (COMP → WETH → DAI) with the minimum-output argument hard-coded to 0 — i.e. zero slippage protection (redeemUnderlyingToDAI, GoodCompoundStakingV2.sol:142-147).

The only guard is maxSafeTokenAmount (UniswapV2SwapHelper.sol:19-42), which caps the swap at maxLiquidityPercentageSwap = 0.3% of the pool's current reserve. But that cap is computed from the live, manipulable reserve, so an attacker who first crashes the COMP/WETH pool simply pushes the cap up along with the (now worthless) COMP price.

The harvest is reachable permissionlessly: GoodFundManager.collectInterest() (GoodFundManager.sol:221-249) accepts a caller-supplied list of staking-contract addresses with no whitelist check and calls collectUBIInterest() on each. The attacker passes the same target five times to force five slippage-free COMP dumps in one transaction.

The attacker, inside a Balancer flash loan (COMP + WETH) and a nested SushiSwap flash swap:

1. Crashes the COMP/WETH pool — swaps 20,096.81 COMP → 38.25 WETH into the pair, taking the COMP reserve from 1,764.50 → 21,861.31 and the WETH reserve from 41.62 → 3.37. COMP is now ~22× too cheap in this pool.
2. Force-distributes COMP into the staking contract via Comptroller.claimComp (268.53 COMP landed in the staking contract), so it has a reward balance to harvest.
3. Triggers collectInterest([staking ×5], true) — each collectUBIInterest sells ~65.58 COMP into the crashed pool for ~0.01 WETH (worth ~$0.02 of WETH for ~$3,600 of COMP at honest price), pumping the pool's COMP reserve and barely moving WETH.
4. Reverses — swaps the 38.25 WETH back for 20,353.76 COMP, i.e. more COMP than it put in, because the protocol's near-free COMP sales inflated the pool's COMP side.
5. Unwinds the flash loans (repays COMP+WETH to Balancer, COMP+WETH to SushiSwap, repays the Compound cETH/cCOMP positions) and ships 258.03 COMP to the profit receiver.

Background — what GoodDollar's staking does#

GoodDollar runs UBI funded by DeFi yield. GoodCompoundStakingV2 (source) supplies an underlying token to Compound (here cDAI), accrues COMP governance-token rewards, and periodically converts those rewards plus the interest into DAI/cDAI for the GoodDollar Reserve.

The harvest path is:

GoodFundManager.collectInterest([staking…])      ← permissionless keeper entry point
  └─ for each staking: collectUBIInterest(reserve)         (SimpleStakingV2.sol:389)
        └─ redeemUnderlyingToDAI(iTokenGains, reserve)     (GoodCompoundStakingV2.sol:117)
              ├─ swap entire COMP balance → WETH → DAI     (minOut = 0)   ← the bug
              └─ redeem cDAI interest → DAI → reserve

On-chain facts at the fork block:

The vulnerable code#

1. The harvest swaps the whole COMP balance with minOut = 0#

GoodCompoundStakingV2.redeemUnderlyingToDAI:

function redeemUnderlyingToDAI(uint256 _amount, address _recipient) internal override
    returns (uint256 actualTokenGains, uint256 actualRewardTokenGains, uint256 daiAmount)
{
    uint256 compBalance = comp.balanceOf(address(this));   // ⚠️ ENTIRE reward balance
    uint256 redeemedDAI;
    if (compBalance > 0) {
        address[] memory compToDaiSwapPath = new address[](https://github.com/sanbir/evm-hack-registry/tree/main/2023-12-GoodCompound_exp/3);
        compToDaiSwapPath[0] = address(comp);
        compToDaiSwapPath[1] = uniswapContract.WETH();
        compToDaiSwapPath[2] = nameService.getAddress("DAI");
        actualRewardTokenGains = IHasRouter(this).maxSafeTokenAmount(   // cap = 0.3% of LIVE reserve
            address(comp), uniswapContract.WETH(), compBalance, maxLiquidityPercentageSwap
        );
        redeemedDAI = IHasRouter(this).swap(
            compToDaiSwapPath,
            actualRewardTokenGains,
            0,                          // ⚠️⚠️ _minTokenReturn = 0 → NO slippage protection
            _recipient
        );
    }
    ...
}

2. The "safety" cap scales with the manipulated reserve#

UniswapV2SwapHelper.maxSafeTokenAmount:

function maxSafeTokenAmount(
    IHasRouter _iHasRouter, address _inToken, address _outToken,
    uint256 _inTokenAmount, uint256 _maxLiquidityPercentageSwap
) public view returns (uint256 safeAmount) {
    ...
    (uint112 reserve0, uint112 reserve1, ) = pair.getReserves();   // ⚠️ spot reserve, attacker-controlled
    uint112 reserve = reserve0;
    if (_inToken == pair.token1()) reserve = reserve1;

    safeAmount = (reserve * _maxLiquidityPercentageSwap) / 100000;  // 0.3% of CURRENT reserve
    return safeAmount < _inTokenAmount ? safeAmount : _inTokenAmount;
}

The comment claims this is an anti-sandwich limit. It is meaningless: the attacker first inflates the COMP reserve to 21,861 COMP, so 0.3% × 21,861 ≈ 65.58 COMP — the function returns exactly 65583941528193262325 in the trace (output.txt:368). The cap grew with the attack.

3. The trigger has no staking-contract whitelist#

GoodFundManager.collectInterest:

function collectInterest(address[] calldata _stakingContracts, bool _forceAndWaiverRewards) external {
    ...
    for (uint256 i = _stakingContracts.length; i > 0; i--) {
        if (_stakingContracts[i - 1] != address(0x0)) {
            IGoodStaking(_stakingContracts[i - 1]).collectUBIInterest(reserveAddress);  // ⚠️ any address, any count
        }
    }
    ...
}

_stakingContracts is taken verbatim from the caller — no check that the addresses are registered activeContracts. The PoC passes [staking, staking, staking, staking, staking] to force five slippage-free COMP dumps in a single call (GoodCompound_exp.sol:155-161).

Root cause — why it was possible#

The protocol performs a value-bearing swap (COMP rewards → DAI) at the AMM spot price with no trustworthy minimum-output bound. Three design decisions compose into the loss:

1. minOut = 0 on the COMP→WETH leg. The swap accepts any amount of WETH back, so a price-skewed pool lets the protocol sell its COMP for essentially nothing. This is the core flaw — slippage protection is the one thing that would have made the attack revert.
2. The slippage cap is a function of the live reserve, not an oracle. maxSafeTokenAmount computes 0.3% × reserve, but a flash-loan-funded attacker controls reserve. Anchoring the "safe amount" to a manipulable spot quantity provides no protection — the cap simply tracks the manipulation.
3. A permissionless, count-unbounded trigger. collectInterest() lets anyone choose when and how many times the harvest runs, against any address, in the same transaction in which they have already skewed the pool. The attacker even pre-loads the rewards via claimComp, so there is always COMP to dump.

The net effect: each collectUBIInterest call moves real COMP from the staking contract into the COMP/WETH pool at a price the attacker chose, and the attacker harvests the resulting reserve imbalance by reversing its own position.

Preconditions#

• The COMP/WETH Uniswap V2 pool must be cheaply skewable — true for any V2 pool given enough working capital, which a flash loan supplies (Balancer COMP+WETH here, nested with a SushiSwap COMP flash swap).
• The staking contract must hold a COMP reward balance to harvest. The attacker manufactures this with Comptroller.claimComp(staking, [cDAI]) (268.53 COMP), so it is not a real precondition on protocol state — it is created on demand.
• No timing gate blocks it: collectInterest's interval require is commented out (GoodFundManager.sol:230-233) and _forceAndWaiverRewards = true skips the gas/UBI sanity requires.
• All capital is borrowed and repaid in-transaction → flash-loanable, near-zero attacker capital.

Attack walkthrough (with on-chain numbers from the trace)#

The COMP/WETH pair 0xCFfDde… has token0 = COMP, token1 = WETH (so reserve0 = COMP, reserve1 = WETH). All figures are taken from getReserves/Sync/Transfer lines in output.txt. COMP and WETH are 18-decimals.

The "1 WETH back per 65 COMP sold" is the whole heist: the protocol sold ~268 COMP across the five calls (worth ~$13K at the honest $48/COMP) and received about **0.04 WETH ($90)** total, gifting the difference to the pool — which the attacker owned the rest of and reversed out of.

Profit accounting (COMP, attacker's net)#

Final transfer to receiver was 258.03 COMP (:1619); combined with the 7.4 COMP it contributed via transferFrom mid-attack, the receiver's balance nets to 258.05, i.e. +250.63 COMP over the pre-attack 7.42. All flash loans (Balancer COMP+WETH, SushiSwap COMP) and the Compound cETH/cCOMP positions are fully closed in-transaction.

Diagrams#

Sequence of the attack#

COMP/WETH pool state evolution#

The flaw inside the harvest path#

Why the cap fails: spot reserve vs. honest reserve#

Why each magic number#

• 20,096.81 COMP dumped (step 4): assembled from the Balancer COMP flash loan + SushiSwap COMP flash swap (4,200) + cCOMP borrow (14,995) + a 7.4 COMP transferFrom. Large enough to crash the 1,764-COMP pool ~22×, making the protocol's COMP worthless on the swap.
• claimComp → 268.53 COMP: the reward balance to be harvested. Manufactured on demand; the protocol will dump all of it.
• maxSafe = 65.58 COMP: exactly 0.3% × 21,861 — proof the "safety" cap tracked the manipulation instead of constraining it.
• minOut = 0: the literal hard-coded slippage bound on the COMP→WETH leg; the single line that makes the loss possible.
• 5× the same staking address: drains the staking COMP balance over several swaps within the one permissionless call, since each collectUBIInterest is capped to maxSafe.

Remediation#

1. Set a real minOut/slippage bound on the reward swap. Compute the expected WETH/DAI out from a manipulation-resistant price (Chainlink/TWAP — the contract already wires a compUsdOracle) and pass it as _minTokenReturn. Reverting on bad execution price would have stopped this attack outright.
2. Do not anchor the "safe amount" to spot reserves. maxSafeTokenAmount must not derive its cap from pair.getReserves(); an attacker controls that. Bound the swap by an oracle-priced notional or a fixed protocol limit instead.
3. Whitelist staking targets in collectInterest. Validate each _stakingContracts[i] against the registered activeContracts set and reject duplicates, so the harvest can only run against legitimate contracts the expected number of times.
4. Guard the harvest against same-block price manipulation. Re-enable the collection interval require (currently commented out) and/or require that the swap happen at a price consistent with a TWAP, so a freshly-skewed pool cannot be harvested in the same transaction.
5. Don't route reward conversion through a single thin AMM pool with no checks. Use a router with amountOutMin enforced, split across venues, or convert via an oracle-priced OTC/settlement path.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo does not whole-compile under forge test):

_shared/run_poc.sh 2023-12-GoodCompound_exp -vvvvv

• RPC: an Ethereum mainnet archive endpoint is required (fork block 18,759,540). foundry.toml uses an Infura archive endpoint; if it 401s, rotate the /v3/<key> to another provided key.
• Result: [PASS] testExploit(); attacker COMP 7.42 → 258.05 (+250.63 COMP).

Expected tail:

Ran 1 test for test/GoodCompound_exp.sol:GoodCompound
[PASS] testExploit() (gas: 2739829)
  [Begin] Attacker COMP before exploit: 7.416522729556363808
  [End] Attacker COMP after exploit: 258.047626966913589004
Suite result: ok. 1 passed; 0 failed; 0 skipped

Sources downloaded from Etherscan (verified): GoodCompoundStakingV2, GoodFundManager, plus the GoodDollar reserve/staking dependency tree under sources/.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2023-12-GoodCompound_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: GoodCompound_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "GoodDollar GoodCompoundStaking Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.