XDK Exploit — Sell-Path "Recycle" Removes XDK from the Live Pair and `sync()`s

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

Vulnerability classes: vuln/logic/incorrect-order-of-operations · vuln/oracle/spot-price

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains several unrelated PoCs that do not all compile together, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: contracts_XDK.sol.

Key info#

TL;DR#

1. XDK is a fee-on-transfer "deflationary + dividend" token on BSC. Its uniswapV2Pair is the live XDK/GPC PancakeSwap pair (GPC, ticker for the AMMToken contract, is the quote asset). Every buy/sell routed through that pair runs through XDK._transfer → handlerTranscation (contracts_XDK.sol:202-281).

2. On a sell, the contract calls _recycleFromBlackHoleOnSell(transferAmount) (contracts_XDK.sol:400-467). That routine is meant to "recycle" XDK from the dead-wallet's LP share, but it is implemented as two raw super._transfer(uniswapV2Pair, …) calls — _transfer(pair → DEAD_WALLET, actualRecycleXdk) and _transfer(pair → address(this), otherLpTotalShrink) — followed by lpContract.sync(). This is an un-compensated one-sided removal of XDK from the pair's reserve: ~10% of the pool's XDK is deleted/moved out, no GPC moves, and sync() forces the pair to accept the smaller XDK reserve.

3. The attacker flash-borrows 99,789,278,778,620,420,792,392,638 GPC (~9.98e25, ≈99% of the WBNB/GPC pair's GPC reserve) via a pancakeCall flash swap from the WBNB/GPC pair (output.txt:1614), then buys XDK out of the XDK/GPC pair in ~10% reserve chunks (buyXdkWithGpcUntilSpent, 16 chunk swaps).

4. The attacker then repeatedly sells tiny XDK amounts back into the pair (sellXdkIntoRecycleWindow), each sell tripping _recycleFromBlackHoleOnSell so the pair sheds ~10% of its XDK and sync()s, and using pair.skim() to scoop the XDK that the recycle pushed out. 72 SellRecycledFromBlackHole events fire (output.txt:2843 onward), driving the pair's XDK reserve down while its GPC reserve stays loaded with the attacker's borrowed capital.

5. Finally the attacker dumps its accumulated XDK back into the now XDK-depleted / GPC-rich pool (sellRemainingXdkForGpc), pulling GPC out (output.txt:21038), repays the flash swap 100,039,377,221,674,607,310,669,312 GPC (output.txt:21054), and converts the 5,144,739,567,228,948,814,053,975 GPC (~5.14e24) surplus to 6.840316534082275362 WBNB (output.txt:21066), forwarding it to the attacker EOA (output.txt:21108).

Net result asserted by the PoC: attacker WBNB grows from 1e11 wei (0.0000001 WBNB) to 6.840316634082275362 WBNB (output.txt:21117), i.e. profit > 6 WBNB.

Background — what XDK does#

XDK (source) is a fee-on-transfer ERC20 with three bolted-on mechanisms, all triggered inside _transfer/handlerTranscation:

• 3% trade fee — every buy/sell pays TOTAL_TRADE_FEE = 30 / 1000 = 3%, split 1% burn / 1% "black hole" LP / 1% reward pool (contracts_XDK.sol:211-263).
• LP-holder dividends — accumulated reward-pool XDK is paid out pro-rata to LP holders via distributeRewardsBatch (contracts_XDK.sol:322-397).
• "Black-hole recycle on sell" — _recycleFromBlackHoleOnSell (contracts_XDK.sol:400-467) tries to claw XDK attributable to the dead-wallet's LP position back out of the pair on each sell, capped per 24h window.

The quote token is GPC (AMMToken, 0xD3c304697f63B279cd314F92c19cDBE5E5b1631A), and XDK's uniswapV2Pair is created in BaseGpc's constructor against _GPC (contracts_BaseGpc.sol:31). There is no separate WBNB pool for XDK that holds liquidity; WBNB is reached only by routing GPC → WBNB through the separate WBNB/GPC pair.

On-chain parameters at the fork block (read from the trace):

The whole game is that _recycleFromBlackHoleOnSell treats uniswapV2Pair as a balance it is free to debit, and re-syncs the pair afterward — exactly the "burn/move from the pool then sync" anti-pattern.

The vulnerable code#

1. The sell path calls the recycle hook#

if (isSell) {
    _processPendingFees();

    if (currentBurn + burnAmount <= maxBurnFee && isMainPair(recipient)) {
        _recycleFromBlackHoleOnSell(transferAmount);
    }
    if (rewardPoolBalance > 0) {
        distributeRewardsBatch();
    }
}

(contracts_XDK.sol:268-278)

Any transfer whose recipient is the main pair is classified as a sell (contracts_XDK.sol:180-188), so an attacker can drive this path at will simply by transfer-ing XDK to the pair (the classic "manual swap" pattern that bypasses the router's slippage checks).

2. The recycle removes XDK out of the live pair and sync()s#

function _recycleFromBlackHoleOnSell(uint256 sellAmount) internal virtual {
    if (lastRecycleTime + recycleColdTime < block.timestamp) {
        lastRecycleTime = block.timestamp;
        thisRecycleMaxBalance =
            (balanceOf(uniswapV2Pair) * MAX_RECYCLE_RATE) / 1000;   // 10% of pair XDK
        thisRecycleBalance = 0;
        return;                                                     // first stale sell only resets
    }
    if (thisRecycleBalance >= thisRecycleMaxBalance) { return; }    // per-window cap

    uint256 targetXdk = sellAmount * SELL_RECYCLE_RATE / 1000;      // 10% of this sell

    IPancakePair lpContract = IPancakePair(uniswapV2Pair);
    uint256 blackHoleLp     = lpContract.balanceOf(DEAD_WALLET);
    uint256 totalLpSupply   = lpContract.totalSupply();
    uint256 reserveXdk      = balanceOf(uniswapV2Pair);            // XDK held by the pair
    // ... boundary checks ...

    uint256 xdkInBlackHoleLp = (blackHoleLp * reserveXdk) / totalLpSupply;
    uint256 actualRecycleXdk = targetXdk > xdkInBlackHoleLp ? xdkInBlackHoleLp : targetXdk;
    // ... boundary checks ...

    uint256 otherLpTotalShrink =
        (actualRecycleXdk * (reserveXdk - xdkInBlackHoleLp)) / reserveXdk;
    // ...
    thisRecycleBalance = thisRecycleBalance + actualRecycleXdk + otherLpTotalShrink;

    super._transfer(uniswapV2Pair, DEAD_WALLET, actualRecycleXdk);     // ⚠️ debit pair's XDK reserve
    super._transfer(uniswapV2Pair, address(this), otherLpTotalShrink); // ⚠️ debit pair's XDK reserve
    rewardPoolBalance += otherLpTotalShrink;
    success = true;
    lpContract.sync();                                                 // ⚠️ force pair to accept new XDK reserve
    emit SellRecycledFromBlackHole(sellAmount, actualRecycleXdk, success);
}

(contracts_XDK.sol:400-467)

The source even admits the implementation is a shortcut. The Chinese comments at contracts_XDK.sol:451-456 translate to: "In a real scenario you must first move the black-hole LP into the contract, remove liquidity to obtain XDK, then burn it. Here it is simplified to transferring XDK directly out of the LP contract to the dead address." That "simplification" is the bug: it deletes one side of the AMM reserve with no counterparty outflow.

3. The sell-classification + manual-swap surface#

if (isPair(recipient)) {           // transfer to the pair == "sell"
    isSell = true;
    user = sender;
    pairAddress = recipient;
} else if (isPair(sender)) {       // transfer from the pair == "buy"
    isBuy = true;
    user = recipient;
    pairAddress = sender;
}

(contracts_XDK.sol:180-188)

Because a plain transfer(pair, amount) is classified as a sell, the attacker drives the recycle hook without ever calling the router, then uses the pair's own swap()/skim() primitives to collect the displaced reserves — the trace shows 56 skim() calls (output.txt:1852 onward).

Root cause — why it was possible#

A Uniswap-V2/PancakeSwap pair prices assets purely from its cached reserves and only enforces x·y ≥ k inside swap(). sync() exists to force the cached reserves to equal the actual token balances — it trusts that balances only change through mint/burn/swap. _recycleFromBlackHoleOnSell violates that trust:

It calls super._transfer(uniswapV2Pair, …) to move XDK out of the pair's balance, then calls pair.sync() to tell the pair "your XDK reserve is now this much smaller." No GPC ever leaves the pair. The product k drops and the marginal price of XDK rises — value flows to whoever holds XDK.

Concretely, four design decisions compose into the loss:

1. The recycle debits the live pair, not a treasury. uniswapV2Pair is the real PancakeSwap pair. _transfer(uniswapV2Pair, DEAD_WALLET, …) + _transfer(uniswapV2Pair, address(this), …) is an un-compensated one-sided reserve removal — functionally identical to "burn from the pool then sync".
2. The trigger is attacker-controlled. Any transfer to the pair is a "sell", so the attacker decides exactly when and how often the reserve-shrinking recycle fires, and sizes each sell so the recycle takes a meaningful 10% chunk.
3. The window cap is on the pair's own balance. thisRecycleMaxBalance is 10% × balanceOf(pair) measured at reset (output.txt:2722 = 1.131e24), and SELL_RECYCLE_RATE is 10% of each sell — both keyed off instantaneous, attacker-manipulable pool state, so the cap does nothing to stop an attacker who has already cornered the pool.
4. skim() lets the attacker harvest the displacement. After each recycle desyncs the pair, the attacker calls pair.skim(self) to pull the XDK overage to itself, recycling it into the next sell.

The 3% fee, dividend distribution, and swapAndLiquify machinery do not claw the value back — they actually help the attacker by routing the fee-XDK through the pair and steadily moving GPC into the XDK/GPC pair while XDK is drained, leaving a GPC-rich pool the attacker then sells into.

Preconditions#

• The recycle window must be reachable. lastRecycleTime + recycleColdTime < block.timestamp (1,771,159,602 + 86,400 < 1,771,246,282) is true at the fork block, so the first stale sell resets the window and arms thisRecycleMaxBalance (contracts_XDK.sol:402-408). The PoC handles this in primeRecycleWindow() (XDKRecycle_exp.sol:133-148) by doing one small buy/sell to trip the reset before the real drain loop.
• isStart == true (trading launched) so handlerTranscation does not revert (contracts_XDK.sol:206). True at the fork block.
• Each buy/sell must stay under the anti-whale cap transferAmount < reserveXdk/10 (contracts_XDK.sol:208-209) — hence the cappedTenth() sizing in the PoC (XDKRecycle_exp.sol:224-227).
• Working capital in GPC to corner the XDK/GPC pool. Peak outlay was ~9.98e25 GPC, fully recovered intra-transaction, hence flash-loanable: the PoC borrows it from the WBNB/GPC pair via a pancakeCall flash swap (XDKRecycle_exp.sol:88-92).

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

The XDK/GPC pair has token0 = XDK, token1 = GPC, so reserve0 = XDK, reserve1 = GPC. All figures are taken directly from getReserves / Sync returns in output.txt. Amounts are raw (18-decimal) wei; human approximations in parentheses.

Why "transfer to the pair == sell": the recycle never requires a router call. The attacker transfers XDK to the pair (sell-classified), the hook deletes ~10% of the pair's XDK and sync()s, and skim() returns the displaced XDK to the attacker — repeated 72× until the per-window cap or the attacker's XDK balance is exhausted.

Profit / loss accounting (WBNB, raw wei)#

The profit is realised entirely in GPC inside the transaction (GPC surplus after repaying the flash swap = 5,144,739,567,228,948,814,053,975 wei (output.txt:21072)) and then converted to 6.840316534082275362 WBNB via the WBNB/GPC pair (output.txt:21066). The PoC asserts profit > 6 ether (XDKRecycle_exp.sol:64-65).

Diagrams#

Sequence of the attack#

Pool state evolution (XDK/GPC pair)#

The flaw inside _recycleFromBlackHoleOnSell#

Why the recycle is theft: constant-product before vs. after one recycle#

Why each magic number#

• borrowAmount = gpcReserve * 99 / 100 (XDKRecycle_exp.sol:88-89): borrows ~99% of the WBNB/GPC pair's GPC reserve (~9.98e25 GPC, output.txt:1614) — the maximum working capital available from the flash source, used to corner the XDK/GPC pool's XDK side.
• primeRecycleWindow 1 GPC donation (XDKRecycle_exp.sol:134, output.txt:1626): a tiny buy/sell to trip the stale-window reset branch (contracts_XDK.sol:402-408) so the real drain loop runs against an armed thisRecycleMaxBalance instead of wasting its first sell on the reset.
• cappedTenth(reserveXdk) = reserveXdk/10 - 1 (XDKRecycle_exp.sol:224-227): keeps every buy/sell strictly under the anti-whale cap transferAmount < reserveXdk/10 (contracts_XDK.sol:208-209); the -1 avoids the boundary revert.
• Loop bounds 20 / 55 / 27 (buyXdkWithGpcUntilSpent / sellXdkIntoRecycleWindow / sellRemainingXdkForGpc, XDKRecycle_exp.sol:151, XDKRecycle_exp.sol:170, XDKRecycle_exp.sol:185): generous upper bounds; each loop exits early when the GPC/XDK balance is spent, the recycle cap (thisRecycleBalance ≥ thisRecycleMaxBalance) is hit, or getAmountOut returns 0. The 72 recycle events / 16 buy chunks are how many were actually needed.
• repayAmount = borrowed * 10_000 / 9_975 + 1 (XDKRecycle_exp.sol:129, output.txt:21054 = 1.0004e26 GPC): PancakeV2's 0.25% flash-swap fee — repaying the borrowed amount grossed up by 10000/9975 plus 1 wei for rounding.
• getAmountOut/getAmountIn with 9_975/10_000 (XDKRecycle_exp.sol:208-218): the PancakeV2 0.25% swap-fee constant-product formulas, used to size manual swaps against the live reserves.

Remediation#

1. Never move tokens out of a live AMM pair from a token hook. A "recycle"/"burn" must only ever destroy or move tokens the protocol owns (its own balance or a dedicated treasury). Removing the two super._transfer(uniswapV2Pair, …) calls + lpContract.sync() (contracts_XDK.sol:457-461) eliminates the bug entirely. If "recycling LP value" is a product requirement, implement it as a proper removeLiquidity of the dead-wallet's own LP tokens (both reserves move together, k preserved) — exactly what the code's own comment said the correct path was.
2. Do not classify a raw transfer to the pair as a privileged "sell". Driving reserve-mutating logic from transfer(pair, …) lets an attacker trigger it without router slippage protection. Gate the recycle behind an authenticated keeper, or make it unreachable from any externally-triggerable transfer.
3. Never call pair.sync() from the token. sync() after a one-sided balance change is the exact mechanism that converts a balance edit into a price move. Removing it forces any reserve change to go through the AMM's own burn/swap, which preserve the invariant.
4. Stop keying caps off instantaneous pool state. thisRecycleMaxBalance (10% of pool XDK) and SELL_RECYCLE_RATE (10% of each sell) are both attacker-manipulable. Bound any single operation's reserve impact with a hard percentage-of-reserve revert, and price trust decisions from a TWAP/oracle, not the live reserve.
5. Disallow skim()-harvestable displacement. As long as the token can push its own balance out of the pair, skim() lets the caller pocket the displacement. Eliminating (1)–(3) removes the displacement so there is nothing to skim.

How to reproduce#

The PoC runs offline against a local anvil fork served from anvil_state.json (the project's foundry.toml sets evm_version = 'cancun' and createSelectFork points at a local http://127.0.0.1:8546 anvil instance at block 81,556,795):

_shared/run_poc.sh 2026-02-XDKRecycle_exp --mt testExploit -vvvvv

• Fork: the shared harness boots anvil from the bundled anvil_state.json (BSC state at block 81,556,795) and exposes it on a local port; no public RPC is contacted.
• EVM: foundry.toml pins evm_version = 'cancun'.
• Result: [PASS] testExploit() with Attacker After exploit WBNB Balance: 6.840316634082275362.

Expected tail (output.txt:1562-1565 / output.txt:21127-21130):

Ran 1 test for test/XDKRecycle_exp.sol:ContractTest
[PASS] testExploit() (gas: 27715040)
  Attacker Before exploit WBNB Balance: 0.000000100000000000
  Attacker After exploit WBNB Balance: 6.840316634082275362
...
Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 181.53s (178.78s CPU time)

Reference: DefimonAlerts — https://x.com/DefimonAlerts/status/2024163654631882916 (XDK, BSC, ~6.84 WBNB).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2026-02-XDKRecycle_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: XDKRecycle_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

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