GDS Coin Exploit — Spot-Price `pureUsdtToToken` Reward Inflation via Nested Flash Loans (BSC)

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

Vulnerability classes: vuln/oracle/spot-price · vuln/logic/reward-calculation

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. The fork is served offline from the bundled anvil_state.json (the test calls createSelectFork("http://127.0.0.1:8546", 24_449_918), a local Anvil port — no public RPC is required). Full verbose trace: output.txt (16,358 lines). Verified vulnerable source: sources/GDSToken_C1Bb12/GDSToken.sol (the bundled file is a single JSON of concatenated sources; the GDSToken contract lives in its GDS.sol entry).

Key info#

TL;DR#

1. GDSToken.pureUsdtToToken(uAmount) is a view that quotes a USDT amount into GDS by calling the PancakeSwap V2 router's getAmountsOut on the live GDS/USDT pair (sources/GDSToken_C1Bb12/GDSToken.sol, pureUsdtToToken). It is therefore a classic manipulable spot oracle: whoever moves the pair reserves first controls the "price" every other contract reads in the same transaction.

2. That quote is wired into two sensitive paths. _activateAccount uses pureUsdtToToken(minUsdtAmount) (a fixed 100 * 1e18 USDT) to decide whether a transfer to dead is "big enough" to mark an account as activated and to credit the inviter tree, and the project's reward helper ClaimReward uses it to convert a nominal 100 USDT of reward into the amount of GDS it pushes to dead via GDS.transfer(dead, GDS.pureUsdtToToken(100 * 1e18)) (test/GDS_exp.sol:41-44). GDS sent to dead accrues into the _refreshDestroyMiningAccount mining ledger.

3. The attacker's core trick: inflate the GDS price (in USDT) before calling the reward path, so that the same nominal 100 USDT converts into a much larger amount of GDS. With the pair pre-loaded with USDT, pureUsdtToToken(100e18) returns ≈ 1,762 GDS per call output.txt:281 instead of the resting ≈ 19 GDS, a ~92× inflation.

4. The attacker spawns 100 throwaway ClaimReward clones and, for each one, transfers it a sliver of LP and GDS, then calls transferToken() which (i) ships the inflated ~1,762 GDS to dead, crediting mining rewards, and (ii) forwards the clone's entire LP balance back to the attacker. This is repeated 100× in ClaimRewardFactory (test/GDS_exp.sol:128-136).

5. Capital for the price ramp is borrowed in a nested flash-loan stack: a Saddle SwapFlashLoan of 2,063,196.66 USDT output.txt:6848, inside whose callback the attacker takes a DODO flash loan of 315,517.00 USDT output.txt:6861, and inside that callback swaps 600,000 USDT → GDS output.txt:6874, ramming USDT into the pair.

6. After the ramp, the attacker calls withdraw() on all 100 reward clones (WithdrawRewardFactory), each of which pushes the accrued GDS to dead and dumps its remaining GDS through the router for USDT. The attacker then removes the LP they added, sells the recovered GDS back, and repays DODO (315,517.00 USDT) and Saddle (2,064,848.54 USDT, principal + fee).

7. Because the attacker bought GDS at the inflated price they created but the reward system credited them GDS at that same inflated rate (and they sold into a USDT-rich pool), the cycle leaves them with a net +207,248.32 USDT (output.txt:16249; final balance 219,748.32 USDT minus the 12,500 USDT seed cost = 50 WBNB × 250 they put in to bootstrap).

Background — what GDS Coin does#

GDS Coin is a BSC ERC20 (GDSToken) with a referral/mining economic layer bolted onto a standard PancakeSwap V2 token. At the fork block the relevant on-chain parameters are:

The economic design has three building blocks that the exploit turns against the protocol:

• pureUsdtToToken — a public view that converts USDT→GDS at the current spot AMM price via uniswapV2Router.getAmountsOut. This is used as a price oracle in two sensitive places.
• Activation (_activateAccount) — when enableActivate is on, an account becomes "activated" only if it transfers at least pureUsdtToToken(minUsdtAmount) GDS to the dead address. Once activated, the account's inviter gains invite-count levels that unlock referral mining tiers.
• Destroy-mining ledger (destroyMiningAccounts) — every GDS sent to dead is added to the sender's destroyMiningAccounts[_from], which then earns per-block mining rewards pulled from destoryPoolContract. The settlement loop _settlementDestoryMining pays out (destroyMiningAccounts * miningRate / 10000) * diffBlock / theDayBlockCount per day.

The project also ships an off-token helper called ClaimReward (replicated in the PoC) whose job is to convert a nominal 100 USDT of reward into GDS and push it to dead on behalf of a user. It does that conversion with the same vulnerable pureUsdtToToken call.

The vulnerable code#

All snippets are copied verbatim from the verified GDSToken source bundled in sources/GDSToken_C1Bb12/GDSToken.sol (the file is a JSON of concatenated .sol sources; the GDSToken contract is in its GDS.sol entry).

1. pureUsdtToToken — a spot-price oracle on the live pair#

function pureUsdtToToken(uint256 _uAmount) public view returns(uint256){
    address[] memory routerAddress = new address[](https://github.com/sanbir/evm-hack-registry/tree/main/2023-01-GDS_exp/2);
    routerAddress[0] = usdt;
    routerAddress[1] = address(this);
    uint[] memory amounts = uniswapV2Router.getAmountsOut(_uAmount,routerAddress);
    return amounts[1];
}

Source: sources/GDSToken_C1Bb12/GDSToken.sol — pureUsdtToToken inside contract GDSToken.

getAmountsOut reads the pair's getReserves() at the instant of the call. Anyone who changes those reserves in the same transaction (e.g. with a flash-loan-funded swap) controls the number this returns for every subsequent caller in that transaction. There is no TWAP, no TWAB, no sanity bound.

2. _activateAccount trusts that spot quote for activation#

function _activateAccount(address _from,address _to,uint256 _amount)internal {
    if(enableActivate && !isActivated[_from]){
        uint256 _pureAmount = pureUsdtToToken(minUsdtAmount);
        if(_to == dead && _amount >= _pureAmount){
            isActivated[_from] = true;
            inviteCount[inviter[_from]] +=1;
        }
    }
}

Source: sources/GDSToken_C1Bb12/GDSToken.sol — _activateAccount inside contract GDSToken, called from _afterTokenTransfer.

_pureAmount is 100 USDT worth of GDS at the manipulated spot price. After the attacker pumps the pair with USDT, 100 USDT "buys" ~1,762 GDS instead of ~19 GDS, so a transfer that would not normally qualify now flips the account to activated and increments the inviter's invite count — for free.

3. _refreshDestroyMiningAccount credits mining principal from transfers to dead#

function _refreshDestroyMiningAccount(address _from,address _to,uint256 _amount)internal {
    if(_to == dead){
        _settlementDestoryMining(_from);
        if(isOpenLpMining){
            _settlementLpMining(_from);
        }
        destroyMiningAccounts[_from] += _amount;
        if(lastBlock[_from] == 0){
            lastBlock[_from] = block.number;
        }
    }
    ...
}

Source: sources/GDSToken_C1Bb12/GDSToken.sol — _refreshDestroyMiningAccount inside contract GDSToken, called from _afterTokenTransfer.

Every GDS sent to dead is added to the sender's mining principal. The exploit leverages this via the ClaimReward.transferToken() helper:

function transferToken() external {
    GDS.transfer(deadAddress, GDS.pureUsdtToToken(100 * 1e18));
    Pair.transfer(Owner, Pair.balanceOf(address(this)));
}

Source: test/GDS_exp.sol#L41-L44 — the attacker's ClaimReward clone mirrors the on-chain project helper that gates the same reward path.

When the pair has been pumped, pureUsdtToToken(100e18) returns the inflated ~1,762 GDS, so a single transferToken() destroys ~1,762 GDS on the clone's behalf (crediting mining) while pulling the clone's LP back to the attacker. Repeated across 100 clones, the attacker harvests the spread between the real cost of GDS (paid in the ramp swap) and the inflated GDS credited by the reward system.

4. The reward-withdraw path that converts credited GDS back to USDT#

function withdraw() external {
    GDS.transfer(deadAddress, 10_000);
    Pair.transfer(Owner, Pair.balanceOf(address(this)));
    GDS.approve(address(Router), type(uint256).max);
    address[] memory path = new address[](https://github.com/sanbir/evm-hack-registry/tree/main/2023-01-GDS_exp/2);
    path[0] = address(GDS);
    path[1] = address(USDT);
    Router.swapExactTokensForTokensSupportingFeeOnTransferTokens(
        GDS.balanceOf(address(this)), 0, path, Owner, block.timestamp
    );
}

Source: test/GDS_exp.sol#L46-L56.

withdraw() takes whatever GDS the clone has accumulated and sells it through PancakeSwap for USDT, forwarded to Owner (the attacker). Combined with transferToken(), the two functions let each clone act as a one-shot "convert inflated GDS credit into USDT" terminal.

Root cause — why it was possible#

The single root cause is using a flash-loan-manipulable spot AMM price as a trust anchor. Specifically:

• pureUsdtToToken is a view that calls IUniswapV2Router02.getAmountsOut on the live GDS/USDT pair. The pair's reserves are public, permissionless state that any caller can move with a swap.
• Two economic decisions hang off that number: (a) whether a transfer qualifies an account for activation/inviter rewards (_activateAccount), and (b) how much GDS the reward system destroys on a user's behalf (ClaimReward.transferToken). Both assume the spot price reflects honest market demand, but nothing enforces that — a flash loan can spike the price inside the same transaction.
• The attacker therefore buys the price up, lets the protocol's own logic credit them GDS at the inflated rate, then dumps that GDS into the now USDT-heavy pool. The asymmetry — protocol pays out at attacker-controlled price — is the entire bug. A TWAP oracle, or removing pureUsdtToToken from any state-changing/reward path, would close it.

The nested DODO-inside-Saddle flash-loan structure exists only to assemble ~2.38M USDT of working capital without upfront funds; the bug itself is the spot-price dependency.

Preconditions#

1. enableActivate is true and isOpenLpMining is true on GDS at the fork block, so the _activateAccount / mining-settlement hooks actually fire on transfers to dead.
2. The GDS/USDT pair is shallow enough (≈290K USDT resting reserve output.txt:81) that a few hundred thousand USDT of flash-loaned capital moves the spot price ~92× (from ~19 to ~1,762 GDS per 100 USDT).
3. pureUsdtToToken is publicly callable and feeds the reward/activation logic — i.e. no access control on the price reader, and no circuit-breaker on rapid reserve changes.
4. Flash-loan liquidity exists: Saddle SwapFlashLoan (2.06M USDT) and a DODO DVM pool (315.5K USDT) are both available and repayable in one transaction.

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

The trace is from the offline Anvil fork at block 24,449,918. Every reserve/amount figure carries the exact output.txt line it was read from; raw wei is given alongside a human approximation.

Note on the GDS reserve evolution: the GDS leg of the pair balloons from ~5.57M (step 6) to ~21.06M (step 14) because the attacker both adds GDS LP and dumps GDS into it, while the USDT leg swings up to ~1.0M during the ramp (step 11) and is then drained back down to ~81K by the final sell. The net transfer of value to the attacker is USDT leaving the GDS economic system.

Profit / loss accounting (USDT, raw wei)#

The attacker's only real input is 50 WBNB of their own (worth ~12,500 USDT after the WBNB→USDT swap). Everything else is flash-borrowed and repaid within the transaction.

The 207,248.32 USDT figure is the exact value the PoC asserts in its final log_named_decimal_uint line output.txt:16249 and is the reproduced loss.

Diagrams#

Sequence of the attack#

Pool state evolution (GDS/USDT pair reserves)#

The flaw inside pureUsdtToToken#

Why the ramp is profitable: USDT-rich pool after the dump#

Why each magic number#

Remediation#

1. Never use a spot AMM price for any state-changing decision. Replace pureUsdtToToken's getAmountsOut with a TWAP/TWAB over a meaningful window (e.g. 30 minutes of priceCumulativeLast), or remove it entirely from the activation and reward paths. The reward amount should be denominated directly in the asset being distributed, not derived from a manipulable quote.
2. Decouple reward distribution from pureUsdtToToken. ClaimReward.transferToken should destroy a fixed, admin-set GDS amount per claim (or none), never pureUsdtToToken(100 USDT).
3. Access-control the reward helper. ClaimReward.transferToken/withdraw are external with no caller check; require a privileged caller or a per-user claim signature with nonce + replay protection.
4. Cap reserves exposure / add a circuit breaker. Reject or rate-limit swaps/adds that move the pair price more than X% in a single block, or pause reward accounting when the spot price deviates from a TWAP beyond a threshold.
5. Re-audit the mining-settlement math. destroyMiningAccounts[_from] += _amount on every transfer to dead lets anyone manufacture mining principal by sending GDS to dead; principal should be sourced only from recognized, non-manipulable deposits.

How to reproduce#

The PoC runs fully offline against the bundled anvil_state.json. The shared harness boots a local Anvil on 127.0.0.1:8546 serving that state, and setUp() forks it at block 24,449,918.

# from the evm-hack-registry repo root
_shared/run_poc.sh 2023-01-GDS_exp --mt testExploit -vvvvv

Notes:

• The test name is testExploit (test/GDS_exp.sol:81) — pass it via --mt.
• foundry.toml uses evm_version = "cancun" and only sets fs_permissions (read) and eth_rpc_retries; the actual RPC is the local Anvil, not a public endpoint.
• The run is long (~7 min: the trace reports finished in 430.38s) because 100 clones each execute a full reward + swap cycle.

Expected tail of output.txt (verbatim):

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 430.38s (429.75s CPU time)

Ran 1 test suite in 431.08s (430.38s CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests)

with the single log line:

Attacker USDT balance after exploit: 207248.323853403323395141

Reference: PeckShield alert — https://twitter.com/peckshield/status/1610095490368180224 ; BlockSec analysis — https://twitter.com/BlockSecTeam/status/1610167174978760704

Sources & further analysis#

Reproductions & code

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

Alerts & third-party analyses

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