XDK Sell-Hook Reserve Theft on PancakePair

1. Incident Overview TL;DR

A single BNB Chain transaction (0x4848bae0fe22f781a94b4613596e7640f70d443db03b6a18fdaffcd30de718d0, block 81556796) executed by an unprivileged adversary flow extracted value from XDK-linked liquidity pools. The sender 0xb180ef1bf6fb3e9a0b5db4460e4db804e946cc8a called orchestrator 0xb94f61855f616057a6dc790c2269a33d1b13a0ed, which CREATE2-deployed helper 0x1e7e4e41defde022e78add6f6e406a7520b63c70 and completed a dense swap/recycle loop in one tx.

The root cause is an ATTACK-class logic flaw in XDK sell handling: token logic can directly debit XDK from its LP pair and then force sync, violating AMM reserve-custody assumptions. This allows deterministic reserve/price distortion and permissionless extraction. The incident is ACT (is_act=true) because execution requires no privileged keys or hidden dependencies.

2. Key Background

• XDK overrides _transfer and routes pair interactions through handlerTranscation, distinguishing buy/sell by whether sender or recipient is a configured pair.
• For main-pair sells, XDK executes additional tokenomics hooks before the final seller-to-pair transfer.
• AMM pairs (Pancake/Uniswap V2 model) assume reserve updates reflect legitimate pair-authorized flows (swap/mint/burn), not arbitrary token-side confiscation.
• Relevant public contracts:
  • XDK token: 0x02739be625f7a1cb196f42dceee630c394dd9faa
  • XDK/GPC pair: 0xe3cba5c0a8efaedce84751af2efddcf071d311a9
  • WBNB/GPC pair: 0x12dabfce08ef59c24cdee6c488e05179fb8d64d9
  • Pancake router: 0x10ed43c718714eb63d5aa57b78b54704e256024e

3. Vulnerability Analysis & Root Cause Summary

This is a token-hook reserve-custody violation. During sells to the main pair, XDK enters _recycleFromBlackHoleOnSell, computes recycle amounts, then performs super._transfer from the pair address to the dead wallet and to the token contract itself, followed by lpContract.sync(). That sequence mutates pair balances outside canonical LP burn/remove-liquidity semantics and immediately commits manipulated balances into reserves.

Because the path is reachable by ordinary sell activity from an unprivileged address, an attacker can repeatedly trigger it in one transaction while interleaving swaps. The observed transaction shows this pattern at scale (133 swaps, 72 recycle-event emissions), demonstrating deterministic exploitability rather than accidental drift.

4. Detailed Root Cause Analysis

1. Sell-path triggerability is public: when recipient is a pair, XDK marks the transfer as sell and enters handlerTranscation.
2. For main-pair sells, XDK executes recycle logic before final transfer.
3. The recycle function directly debits pair inventory and forces sync, creating reserve drift.

Snippet (XDK verified source, sell/recycle breakpoint):

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

super._transfer(uniswapV2Pair, DEAD_WALLET, actualRecycleXdk);
super._transfer(uniswapV2Pair, address(this), otherLpTotalShrink);
rewardPoolBalance += otherLpTotalShrink;
lpContract.sync();

On-chain evidence (seed transaction receipt) confirms repeated execution of the recycle branch and heavy AMM interaction:

{
  "logs_count": 4048,
  "swap_events": 133,
  "sync_events": 288,
  "sell_recycle_topic_count": 72
}

State impact is visible in reserve snapshots for XDK/GPC pair (0xe3cba5...):

• Pre-tx reserves: XDK 11311911655724807549926752, GPC 14838228195602116419462362
• Post-tx reserves: XDK 9499198844327752138392151, GPC 9329280916612873261152222

These shifts align with pair-side confiscation and forced synchronization.

5. Adversary Flow Analysis

Adversary-related accounts were identified with deterministic role evidence:

• 0xb180ef1bf6fb3e9a0b5db4460e4db804e946cc8a (EOA sender, gas payer)
• 0xb94f61855f616057a6dc790c2269a33d1b13a0ed (entry/orchestrator contract)
• 0x1e7e4e41defde022e78add6f6e406a7520b63c70 (helper contract created and profit receiver)

Execution stages:

1. Initialization: EOA calls orchestrator; helper is deployed via CREATE2 in-tx.
2. Manipulation loop: repeated sell-triggered recycle and sync on XDK/GPC, interleaved with swaps across XDK/GPC and WBNB/GPC.
3. Unwind/profit: flash-funded leg is repaid and helper ends with WBNB gain.

Snippet (internal tx evidence for helper deployment):

{
  "hash": "0x4848bae0fe22f781a94b4613596e7640f70d443db03b6a18fdaffcd30de718d0",
  "type": "create2",
  "from": "0xb94f61855f616057a6dc790c2269a33d1b13a0ed",
  "contractAddress": "0x1e7e4e41defde022e78add6f6e406a7520b63c70"
}

6. Impact & Losses

Measured impact from collector artifacts:

• WBNB adversary gain: 6840316534082275362 wei transferred to helper 0x1e7e... with no WBNB outflow from helper in the same tx.
• Sender native gas paid: 3627129480000000 wei.
• XDK/GPC pair reserve-side token deltas:
  • GPC: -5508947278989243158310140
  • XDK: -1812712811397055411534601

Safety impact: reserve-custody integrity is broken by token-side confiscation of pair balances, enabling deterministic distortion and extraction in one permissionless transaction.

7. References

• Seed exploit tx: 0x4848bae0fe22f781a94b4613596e7640f70d443db03b6a18fdaffcd30de718d0
• XDK verified source (sell dispatch and recycle path), contract 0x02739be625f7a1cb196f42dceee630c394dd9faa
• Parsed receipt events and raw receipt for exploit tx (Transfer/Swap/Sync and recycle-topic evidence)
• Role metadata and reserve snapshots (XDK/GPC, WBNB/GPC) at blocks 81556795 and 81556796
• Internal tx evidence showing CREATE2 helper deployment from orchestrator