HackDao Exploit — Fee-on-Transfer Token Listed in a Vanilla Pancake Pair (skim/sync reserve desync)

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

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

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. Full verbose trace: output.txt. Verified vulnerable source (the HackDao Token contract): Token.sol; the AMM pair it manipulates: PancakePair.sol; the flash source: DPPAdvanced.sol.

Key info#

TL;DR#

1. Hackerdao is an ERC-20 with a heavy transfer-fee regime baked into its overridden _transfer (Token.sol#L457-L521). Every non-whitelisted transfer pays a 12% fee, a 4% "destroy" (sent to address(1)), an 8% "pool" cut, and up to seven affiliate "level" kickbacks — all of them taken from the sender's balance on top of the transferred amount.

2. The fee logic keys off a single stored pair, uniswapV2Pair (Token.sol#L420-L421), which the constructor hard-wires to the HackDao/USDT pair (0x55d398… = BSC USDT). The other traded pair, HackDao/WBNB (0xcd4CDA…), is not uniswapV2Pair from the token's point of view. This asymmetry is the seed of the bug.

3. On any transfer whose recipient == uniswapV2Pair the token takes the "sell" branch (Token.sol#L487-L491): it deducts the 12% fee as an extra charge from the sender's balance, yet still credits the full amount to the pair. So the pair's token balance ends up higher than the reserve it cached — the pair is owed fee tokens it never asked for.

4. Conversely, on a "buy" (sender == uniswapV2Pair, but here the WBNB pair is not the registered pair, so the branch is the default) the token strips 12% + 4% + 8% from the sender's balance while crediting only 88% to the buyer — so the WBNB pair's token balance ends up lower than its cached reserve. Either way, the pair's balanceOf and its reserve0/reserve1 drift apart.

5. The attacker flash-borrows 1,900 WBNB from the DODO DVM pool (test/HackDao_exp.sol#L29), buys HackDao from the WBNB pair (driving its real HackDao balance well below its cached reserve), then pushes the bought HackDao back into the WBNB pair and calls skim() → sync() → skim() across the two pairs.

6. The two skim()s move the "excess" HackDao around; the sync() then re-bases the WBNB pair's reserve0 down to its now-depleted real balance — making HackDao look artificially scarce and WBNB look cheap inside that pair (output.txt:126-134).

7. The attacker finally sells the relayed HackDao back into the re-synced WBNB pair. Because reserve0 was just collapsed from ~7,110 to ~112 HackDao while reserve1 still holds ~2,096 WBNB, the manual getAmountOut in the PoC (test/HackDao_exp.sol#L43-L47) computes 2,063.67 WBNB out for ~6,998 HackDao in (output.txt:165-180).

8. Net: the attacker receives 2,063.673482526496579211 WBNB, repays the 1,900 WBNB flash loan, and keeps 163.673482526496579211 WBNB (output.txt:181, output.txt:199-200) — the WBNB pair's honest liquidity, extracted for free.

Background — what HackDao does#

Hackerdao (source) is a fixed-supply (21,000-token, 18-decimal) ERC-20 that layers a referral/fee economy on top of every transfer. The interesting part is entirely inside the overridden _transfer:

• A whitelist (WhiteList, Token.sol#L61-L76) lets the owner and chosen addresses skip all fees.
• A parent/referral tree (parentAddress, levelRatio, Token.sol#L401-L402) records who introduced whom, and pays up to 7 levels of "profit" on every transfer.
• Three fee knobs — _feeRatio, _destroyRatio, _poolRatio (Token.sol#L396-L398) — plus the 7 level ratios are charged on every non-whitelisted transfer.
• A single stored AMM pair, uniswapV2Pair (Token.sol#L393), set in the constructor to the HackDao/USDT pair (Token.sol#L420-L421). The contract uses it solely to decide whether a transfer is a "sell".

On-chain parameters at the fork block (block 18,073,756), read from the trace:

The fees were confirmed against the trace: when the WBNB pair sends 10,269,229,249,262,517,377,464 HackDao to the attacker (a "buy"), the token emits a 410,769,169,970,500,695,098 (4%) destroy to address(1) and a 821,538,339,941,001,390,197 (8%) cut to the pool address, and the attacker actually receives 9,036,921,739,351,015,292,169 = 88% = amount − 12% fee (output.txt:50-59).

The vulnerable code#

1. The fee-bearing _transfer override#

The whole exploit lives in this override. The branches that matter are the "sell" branch (recipient is the registered pair) and the default branch (every other non-whitelisted transfer):

function _transfer(
    address sender,
    address recipient,
    uint256 amount
) internal override virtual {
    require(sender != address(0), "ERC20: transfer from the zero address");
    require(recipient != address(0), "ERC20: transfer to the zero address");

    _beforeTokenTransfer(sender, recipient, amount);

    uint256 senderBalance = _balances[sender];
    require(senderBalance >= amount, "ERC20: transfer amount exceeds balance");
    unchecked {
        _balances[sender] = senderBalance - amount;
    }
    uint256 actualAmount = amount;

    if(parentAddress[recipient] == address(0) && recipient != uniswapV2Pair){
        if(sender == uniswapV2Pair){
            parentAddress[recipient] = _defaultAddress;
        }else{
            parentAddress[recipient] = sender;
        }
    }

    if(!isWhiteListed(sender) && !isWhiteListed(recipient)){

        uint256 fee = calculationFeeNum(amount,_feeRatio);
        //sell
        if(recipient == uniswapV2Pair){
            require(senderBalance >= amount.add(fee), "ERC20: There are not enough charges for the account balance");
            unchecked {
                _balances[sender] -= fee;          // ⚠️ extra 12% stripped from the SENDER, on top of `amount`
            }
        }else{
            actualAmount = amount - fee;           // ⚠️ buyer receives only 88%
        }
        uint256 destroyNum = calculationFeeNum(amount,_destroyRatio);
        _balances[address(1)] += destroyNum;       // 4% to address(1)
        uint256 poolNum = calculationFeeNum(amount,_poolRatio);
        _balances[_poolAddress] += poolNum;        // 8% to the pool
        emit Transfer(sender, address(1), destroyNum);
        emit Transfer(sender, _poolAddress, poolNum);
        address nextAddress = sender;
        if(sender == uniswapV2Pair){
            nextAddress = recipient;
        }
        for(uint32 i=1;i<=7;i++){                  // up to 7 affiliate kickbacks
            address addr = parentAddress[nextAddress];
            uint256 profit = calculationProfitNum(amount,levelRatio[i]);
            if(addr == address(0)){
                addr = _defaultAddress;
            }else{
                nextAddress = addr;
            }
            _balances[addr] += profit;
            emit Transfer(sender, addr, profit);
        }
    }
    _balances[recipient] += actualAmount;          // ⚠️ "sell": credits the FULL `amount` to the pair
    emit Transfer(sender, recipient, actualAmount);

    _afterTokenTransfer(sender, recipient, amount);
}

(Token.sol#L457-L521)

Two properties of this code are lethal for an AMM pair:

• On a "sell" (recipient == uniswapV2Pair) the pair receives the full amount (because actualAmount is left equal to amount), while the sender is debited amount + 12% plus the destroy/pool cuts. The pair's balanceOf therefore ends up larger than the amount the AMM's swap() thinks it received.
• On a "buy" or any non-sell (recipient != uniswapV2Pair) the recipient is credited only amount − 12%, and the sender additionally loses the destroy/pool cuts. The pair's balanceOf therefore ends up smaller than its cached reserve.

Both cases break the invariant the Pancake pair depends on: that balanceOf(pair) only moves by the amounts swap()/mint()/burn()/skim()/sync() reason about.

2. The single hard-wired pair#

constructor(
    address owner
    ,address poolAddress_
    ,address defaultAddress_
    ,uint256 feeRatio_
    ,uint256 destroyRatio_
    ,uint256 poolRatio_
) ERC20("Hackerdao", "Hackerdao", 18) {
    ...
    IUniswapV2Router02 _uniswapV2Router = IUniswapV2Router02(0x10ED43C718714eb63d5aA57B78B54704E256024E);
    uniswapV2Pair = IUniswapV2Factory(_uniswapV2Router.factory())
    .createPair(address(this), address(0x55d398326f99059fF775485246999027B3197955));   // ⚠️ HackDao/USDT, not WBNB
    ...
}

(Token.sol#L404-L430)

The token registers only the USDT pair as uniswapV2Pair. The WBNB pair (0xcd4CDA…) is a perfectly ordinary counterparty from the token's perspective, so transfers in and out of it hit the asymmetric fee branches in ways the pair never priced in.

3. The Pancake pair that gets desynced#

The pair's swap enforces K against its cached reserves, not its live balances, and sync blindly rebases reserves to balances:

function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external lock {
    ...
    (uint112 _reserve0, uint112 _reserve1,) = getReserves();            // cached, possibly stale
    ...
    uint amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0;
    uint amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0;
    ...
    uint balance0Adjusted = (balance0.mul(10000).sub(amount0In.mul(25)));
    uint balance1Adjusted = (balance1.mul(10000).sub(amount1In.mul(25)));
    require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(10000**2), 'Pancake: K');
    _update(balance0, balance1, _reserve0, _reserve1);
    ...
}

// force balances to match reserves
function skim(address to) external lock {
    ...
    _safeTransfer(_token0, to, IERC20(_token0).balanceOf(address(this)).sub(reserve0));
    _safeTransfer(_token1, to, IERC20(_token1).balanceOf(address(this)).sub(reserve1));
}

// force reserves to match balances
function sync() external lock {
    _update(IERC20(token0).balanceOf(address(this)), IERC20(token1).balanceOf(address(this)), reserve0, reserve1);
}

(PancakePair.sol#L452-L493)

sync() is honest if balances only move through the pair's own functions. HackDao's fee logic moves the pair's HackDao balance silently, so sync() faithfully records a wrong reserve, and the next swap() enforces K against that wrong reference.

Root cause — why it was possible#

A Uniswap-V2/Pancake pair assumes its token balances change only through transferFrom in swap/mint/burn, skim, and sync. It computes amount{0,1}In as balance − (reserve − amountOut) and enforces K against the cached reserve. This is safe for plain ERC-20s and even for standard fee-on-transfer tokens if the pair is the fee-aware variant (…SupportingFeeOnTransferTokens).

HackDao violates the assumption in two compounding ways:

1. The fee is debited from the sender on top of the transfer amount on a "sell", so the pair's balance grows by the full amount while the AMM's amountIn math (which only sees balance − (reserve − amountOut)) under-counts the value that actually arrived. Over many transfers the pair accumulates "phantom" HackDao.
2. The fee is debited from the sender and the recipient is short-credited on a "buy", so the pair's balance shrinks by the destroy+pool+fee cuts that the AMM never sees. After a buy the pair's real HackDao balance is below its cached reserve.

Either drift is exploitable on its own, but the attacker combines both: a buy drives the WBNB pair's balance below its reserve; the attacker then dumps HackDao into the pair (raising the balance above the reserve), skims the excess out, syncs the reserve down to the depleted post-buy balance, and finally skims the excess back in and sells into the now-mispriced pool. The K check passes at every step because it is evaluated against a reserve that the attacker has just rewritten with sync().

This is the same family of bug as the Zeed / WDOGE / numerous "fee-token in a vanilla pair" incidents: a token whose transfer mutates the pair's balance in a way swap() cannot reconcile, plus the pair's trust of sync(). The single hard-wired uniswapV2Pair (pointing at the USDT pair, not the WBNB pair) simply decides which branch each transfer takes — it does not change the fact that some branch always desyncs the WBNB pair.

Preconditions#

• The HackDao/WBNB pair holds non-trivial WBNB liquidity (~196.8 WBNB at the fork block — output.txt:45).
• The attacker can flash-borrow WBNB to fund the cornering buy. The PoC uses a DODO DPPAdvanced flash loan of 1,900 WBNB (test/HackDao_exp.sol#L29); the loan is repaid inside the same callback, so no upfront capital is required.
• Anyone may call skim() and sync() on a Pancake pair — they are permissionless (PancakePair.sol#L483-L493).
• The attacker is not on HackDao's whitelist, which is exactly what's needed for the fee branches to fire.

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

Pair1 = HackDao/WBNB (0xcd4CDA…), token0 = HackDao, token1 = WBNB, so reserve0 = HackDao, reserve1 = WBNB. Pair2 = HackDao/USDT (0xbdB426A2…) = the token's uniswapV2Pair. All numbers are raw 18-decimal wei; the human approximation follows in parentheses. Every figure is cited to its line in output.txt.

The final attacker WBNB balance is 163,673,482,526,496,579,211 (~163.673482526496579211 WBNB), logged by the PoC (output.txt:199-200).

Profit / loss accounting (WBNB)#

The accounting reconciles exactly: the attacker put in 1,900 WBNB and pulled out 2,063.67 WBNB. Of the 2,096.81 WBNB the pair held after the cornering buy, 163.67 WBNB is the pair's original honest liquidity (~196.81 WBNB minus the ~33.13 WBNB left behind and AMM/fee rounding); the rest of the outflow is the attacker's own 1,900 WBNB being handed back.

Diagrams#

Sequence of the attack#

Pool state evolution#

The flaw inside _transfer#

Why sync() is the weapon: reserves vs. balances before and after#

Why each magic number#

• 1900 * 1e18 WBNB flash loan (test/HackDao_exp.sol#L29): the cornering budget. It is sized so the buy pulls most of Pair1's HackDao out (amount0Out = 10,269.23 HackDao against an 11,335.6 reserve) and loads Pair1 with WBNB. It is fully repaid inside the callback, so it costs nothing but gas.
• The corner buy's amount0Out = 10,269,229,249,262,517,377,464 (output.txt:48): the router's getAmountOut(1,900 WBNB, reserveWBNB=196.81, reserveHackDao=11,335.6) with the 0.25% fee. The attacker does not choose this number; it is the AMM's quote.
• The 88% / 12% / 4% / 8% split: not hardcoded in the PoC — they are the token's _feeRatio=12, _destroyRatio=4, _poolRatio=8 (confirmed against the trace: 410,769,… = 4% to address(1), 821,538,… = 8% to the pool, attacker receives 88%).
• The skim amount 7,952,491,130,628,893,457,109 (output.txt:103): not chosen by the attacker; it is Pair1.balanceOf(HackDao) − reserve0 after the re-inject, i.e. exactly the "phantom" tokens the fee logic left behind.
• The sync'd reserve0 = 112,076,746,397,174,699,342 (output.txt:128, output.txt:131): Pair1's real HackDao balance after the skim's extra 12% sell-fee — again, not chosen, just observed.
• The final swap's amountOut = 2,063,673,482,526,496,579,211 WBNB (output.txt:166): computed in the PoC by the standard getAmountOut formula against the sync'd reserves (test/HackDao_exp.sol#L43-L47). Because reserve0 is ~112 HackDao and reserve1 is ~2,096.8 WBNB, selling ~6,998 HackDao buys ~2,063.7 WBNB.
• Net profit 163,673,482,526,496,579,211 WBNB (~163.67): 2,063.67 − 1,900.00. This is what the PoC logs (output.txt:6, output.txt:200).

Remediation#

1. Do not list fee-on-transfer / reflection tokens in vanilla Uniswap-V2 pairs. Either use a fee-aware pair (or router) that measures amount{0,1}In from balance deltas and transfers the fee to the pair, or wrap the token behind a plain ERC-20 wrapper that the AMM trades. The Pancake pair's swap literally cannot see HackDao's side-effects.
2. If a fee token must be used, make sync() and skim() unable to lock in a wrong reserve. The cleanest fix is to forbid sync() on pairs containing such tokens, or to have the token itself never mutate a pair's balance outside of the amount the pair's swap/transferFrom requested — i.e. take fees from the recipient (so balanceOf(pair) only ever changes by the transferred amount), or burn fees from supply rather than redirecting them to arbitrary addresses.
3. Make fee logic symmetric and pair-agnostic. The single hard-wired uniswapV2Pair (pointing at the USDT pair) is what makes the WBNB pair hit the asymmetric default branch. A token that needs "sell" detection should either treat every known AMM pair as a sell target, or — better — charge fees uniformly regardless of counterparty.
4. Enforce K against real received amounts, not cached reserves. A fee-aware pair recomputes amountIn = balanceAfter − balanceBefore and charges K on the fee-adjusted input; the vanilla pair's trust of sync() is what lets the attacker rewrite the reference.
5. Monitor and circuit-break. A sync() that moves a reserve by more than a small percentage, or a swap that pulls more than X% of a reserve in one call, should trip a pause. No such guard existed here.

How to reproduce#

The PoC is run fully offline through the shared harness, which serves the fork state from the bundled anvil_state.json on a local anvil instance. The test's createSelectFork points at http://127.0.0.1:8546 (test/HackDao_exp.sol#L23); run_poc.sh starts anvil on that port and loads the state.

_shared/run_poc.sh 2022-05-HackDao_exp --mt testExploit -vvvvv

• RPC: none required — the fork is served from the local anvil_state.json snapshot at block 18,073,756 on BSC. The test does not call a public RPC.
• EVM: foundry.toml sets evm_version = 'cancun' (the historical BSC state replays fine under it).
• Result: [PASS] testExploit() with the attacker's WBNB balance printed as 163.673482526496579211.

Expected tail (output.txt:203-205):

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 1.54s (16.03ms CPU time)

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

with the preceding log line (output.txt:6):

[End] Attacker WBNB balance after exploit: 163.673482526496579211

Reference: BlockSec analysis — https://twitter.com/BlockSecTeam/status/1529084919976034304 (HackDao, BSC, May 2022).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2022-05-HackDao_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: HackDao_exp.sol.

Alerts & third-party analyses

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