RES Token Exploit — Self-Burn-From-Pool + `sync()` Breaks the AMM Invariant

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

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

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains many unrelated PoCs that do not whole-compile, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: sources/BEP20TokenA_ecCD8B/BEP20TokenA.sol.

Key info#

TL;DR#

RES is a fee-on-transfer "DeFi" token whose internal _thisAToB() routine sweeps the RES that has accumulated inside the token contract (collected as swap tax), sells it through the RES/USDT pool, then _burn()s that same RES amount directly out of the pool and calls pair.sync() (BEP20TokenA.sol:679-692). The burn deletes RES from the pair's balance without removing any USDT, and sync() then forces the pair to treat the shrunken balance as its new reserve. That single operation breaks x·y = k in favour of whoever holds RES.

Worse, this routine is reachable through the fully permissionless thisAToB() entry point (:675-677) — anyone can call it at any time.

The attacker:

1. Flash-borrows 10,014,120.89 USDT from the USDT/WBNB pair.
2. Performs 6 raw pair.swap() buys (direct low-level swaps that bypass the token's buy/sell-fee path), pumping the RES pool's USDT reserve from 260,015.85 → 10,274,136.74 USDT while draining its RES reserve from 1,106,138.76 → 28,180.06 RES. These buys also load the token contract's own balance with 118,713.30 RES of "tax".
3. Calls thisAToB() — _thisAToB() sells the contract's 118,713.30 RES into the pool, then _burn(pool, 118,713.30 RES) + sync(). The pool's RES reserve is wiped to 28,180.06 RES while its USDT reserve (1,974,983.64 USDT) is left untouched — RES is now wildly over-priced inside the pool.
4. Dumps the cheaply-acquired RES back into the now-degenerate pool, pulling 1,905,851.85 USDT out for ~77,882 RES (8-dec) of input.
5. Repays the flash loan and keeps the difference: +180,757.72 USDT.

A side-pocket of profit also comes from the ALL token: _thisAToB's router hop routes the swept RES → USDT → ALL into addresses the attacker controls, which the attacker then sells for an extra ~8.31M USDT intra-transaction (recycled into the flash-loan repayment).

Background — what RES does#

RES (BEP20TokenA) is a BEP-20 with a fee-on-transfer "reflection-to-a-second-token" design:

• Swap taxes. A 15% buy fee and 15% sell fee (:417-418) are charged on Pancake buys/sells, but only when _isBuySwap() / _isSellSwap() heuristics decide the transfer is a "real" AMM trade (:622-634).
• Tax → "B token" (ALL) conversion. The collected fee RES is parked in _balances[address(this)]. Periodically it is converted to the ALL token (_allToken, 0x04C0f31C…) and distributed to a foundation / propaganda / LP address.
• The _thisAToB() sweep + self-burn. When the contract's RES balance exceeds _minAToB (which is 0 by default), _thisAToB() (:679-692) swaps that RES out via the router path RES → USDT → ALL, then burns the same RES amount out of the swap pair and sync()s it.

Pair / token facts at the fork block (read from the trace):

The critical fact: the contract's tax sink (_balances[address(this)]) is sold and then burned from the pool — and the trigger is public.

The vulnerable code#

1. _thisAToB() burns from the pool and sync()s#

BEP20TokenA.sol:679-692:

function _thisAToB() internal{
    if (_balances[address(this)] > _minAToB){           // _minAToB == 0
        uint256 burnNumber = _balances[address(this)];  // contract's accumulated tax RES
        _approve(address(this),_pancakeRouterToken, _balances[address(this)]);
        IPancakeRouter(_pancakeRouterToken).swapExactTokensForTokensSupportingFeeOnTransferTokens(
            _balances[address(this)],
            0,
            _pathAToB,                                   // [RES, USDT, ALL]
            address(this),
            block.timestamp);
        _burn(_swapV2Pair, burnNumber);                 // ⚠️ deletes RES from the pair's balance...
        IPancakePair(_swapV2Pair).sync();               // ⚠️ ...then forces it to be the new reserve
    }
}

The first line sells the contract's RES into the RES/USDT pair (the first hop of the router path). The next two lines then burn that same burnNumber of RES a second time, out of the pair, and sync() the pair so it accepts the lower balance. The pair loses RES twice (once legitimately to the swap, once to the _burn) but only gains USDT for the first.

2. It is reachable permissionlessly via thisAToB()#

BEP20TokenA.sol:675-677:

function thisAToB() external{   // ← no onlyOwner, no keeper guard
    _thisAToB();
}

_thisAToB() is also invoked implicitly on every plain TRANSFER (:636-638), but the dedicated public thisAToB() lets the attacker fire the reserve-shrinking burn at the exact instant it is most profitable.

3. Raw pair.swap() bypasses the fee/anti-bot logic#

The 15% fee and _isBuySwap/_isSellSwap heuristics only run when RES is moved through the token's own _transfer accounting with transferType != TRANSFER. By calling USDT_RES_PAIR.swap() directly (transferring USDT into the pair first, then swap(0, resOut, user, "")), the attacker buys RES through the pair's low-level swap and the RES transfer is treated such that the heuristics never charge the fee on the way out — the tax that does accrue is collected and becomes the very burnNumber the attacker weaponises in step 3.

Root cause — why it was possible#

A Uniswap-V2/PancakeSwap pair derives price purely from its reserves and only checks x·y ≥ k inside swap(). sync() exists to let the pair re-read its true token balances; it trusts that balances only change via mint/burn/swap/transfers the pair can reason about.

_thisAToB violates that trust:

It destroys RES held by the pair (_burn(_swapV2Pair, burnNumber)) and then calls pair.sync(), telling the pair "your RES reserve is now this much smaller." No USDT leaves the pair. k collapses and the marginal price of RES explodes — for free, callable by anyone.

The composing design defects:

1. Permissionless trigger. thisAToB() has no access control, so the attacker chooses when the reserve-deleting burn happens — right after positioning to profit from it.
2. Burning from the pool transfers value to RES holders. Removing RES from the pair without removing USDT shifts the entire USDT side toward whoever still holds RES. The attacker arranges to be that holder.
3. Self-balance is double-counted against the pool. The swept RES is sold into the pool and burned out of it. The pool effectively pays for the same RES twice — once in price impact, once in a free reserve deletion.
4. Reserves drive every internal decision with no oracle. _isBuySwap/_isSellSwap and the price math all read the instantaneous, flash-loan-manipulable pair reserves, so the attacker can pre-shape the pool to make the burn maximally damaging.

Preconditions#

• _balances[address(this)] > _minAToB (with _minAToB == 0, any tax RES suffices). The attacker manufactures this by running fee-charging swaps so RES accumulates in the contract.
• The RES/USDT pair exists and holds genuine USDT liquidity (260,015.85 USDT initially — the prize).
• Working capital in USDT to corner the pool. This is flash-loanable: the PoC borrows 10,014,120.89 USDT from the USDT/WBNB pair via pancakeCall and repays it in the same transaction.

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

The RES/USDT pair has token0 = USDT (18 dec), token1 = RES (8 dec), so reserve0 = USDT, reserve1 = RES. All figures below come directly from the Sync/Swap events and getReserves reads in output.txt. RES amounts shown in whole RES (raw / 1e8).

End state: attacker USDT balance = 180,757,719,881,106,660,102,346 wei = 180,757.72 USDT net profit (:2492-2493).

Why the burn is theft. Before the burn (step 4a) the pool was 1,974,983.64 USDT / 146,893.36 RES. The _burn(pool, 118,713.30) deletes 118,713.30 RES from the pool's balance, and sync() makes the pool's reserve 1,974,983.64 USDT / 28,180.06 RES — the USDT side is fully preserved while RES is slashed by ~81%. The marginal price of RES inside the pool jumps proportionally, so the attacker's remaining cheap RES (bought during the corner phase) is now worth far more USDT than they paid.

Profit accounting (USDT)#

The headline "Total Lost: 290,671 USDT" (from the PoC header / SlowMist) reflects the aggregate value removed from the RES and ALL pools across the two on-chain attack transactions; this single reproduced transaction nets the attacker 180,757.72 USDT.

Diagrams#

Sequence of the attack#

Pool state evolution#

The flaw inside _thisAToB#

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

Remediation#

1. Never burn from the liquidity pool. A token must only ever _burn tokens it owns (its own balance / a treasury), never _burn(_swapV2Pair, …). Removing the _burn(_swapV2Pair, burnNumber) + sync() pair eliminates the bug. If deflation must reach the pool, do it by buying-and-burning from protocol funds so both reserves move together and k is preserved.
2. Do not double-spend the swept balance. _thisAToB() both sells burnNumber RES into the pool and burns burnNumber RES out of it. Pick one. The router sell already removes the RES from the contract; the subsequent _burn(pool, …) is the entire vulnerability.
3. Gate the trigger. Restrict thisAToB() (and any path reaching _thisAToB) to a trusted keeper/role, or make the pool interaction unreachable from any externally-triggerable entry point.
4. Don't price/decide off raw reserves. _isBuySwap / _isSellSwap and the conversion math read instantaneous, flash-loan-manipulable reserves. Use a TWAP/oracle or remove reserve-dependent trust decisions entirely.
5. Cap single-operation reserve impact. Any token operation that can move a pool reserve by more than a small percentage in one call should be rejected; an 81%-of-reserve burn is a red flag.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to whole-compile under forge test):

_shared/run_poc.sh 2022-10-RES_exp -vvvvv

• RPC: a BSC archive endpoint is required (fork block 21,948,016 is old; most public BSC RPCs prune it and fail with header not found / missing trie node). foundry.toml is configured with a working archive endpoint.
• Result: [PASS] testExploit(), ending attacker USDT balance 180,757.72 USDT.

Expected tail (from output.txt):

  [FlashLoan] sell Restoken over, Attacker usdt balance is: 10220014.049973500894580201
  [End] Attacker USDT balance after exploit: 180757.719881106660102346

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 22.79s
[PASS] testExploit() (gas: 1104337)

References:

• BlockSec: https://twitter.com/BlockSecTeam/status/1578120337509662721
• Ancilia: https://x.com/AnciliaInc/status/1578119778446680064
• QuillAudits write-up: https://quillaudits.medium.com/res-token-290k-flash-loan-exploit-quillaudits-9300657fff7b

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2022-10-RES_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: RES_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

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