IntrospectionToken (IT) Exploit — Inflationary Repricing Mint Drains the IT/USDT Pancake Pair

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

Vulnerability classes: vuln/logic/incorrect-state-transition

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo holds many unrelated PoCs that fail to build together, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: contracts_bsc_BEP20.sol and contracts_bsc_IntrospectionToken.sol.

Key info#

TL;DR#

IntrospectionToken tries to defend its USDT price by minting free IT to the liquidity pool whenever someone buys IT out of the pool (mintToPoolIfNeeded, BEP20.sol:380-419). The intent is: a buy that pushes the IT price up more than 1% should be "topped up" with extra IT so the price stays flat.

That defense is the vulnerability. The token has no idea the mint happened inside a Uniswap-style swap(), so the freshly minted IT lands in the pair's balance after the constant-product check, and is immediately withdrawable. Concretely, the attacker runs a 9-step loop:

1. Deposit 2,000 USDT directly into the pair (transfer), inflating reserve1 without touching reserve0.
2. Compute the exact IT amount (reserve0 - 1) and USDT amount that satisfies the pair's k invariant after the token's _transfer mints a large IT top-up into the pair.
3. Call pair.swap(reserve0 - 1, amountout, to, "") — pulling out nearly the entire IT reserve plus ~3,590 USDT.

Because the token re-mints the IT reserve back into the pool on each buy-triggered transfer, the attacker can repeat the trick nine times with the same 2,000 USDT. Each iteration the IT reserve grows larger (the mint is inflationary) while the USDT reserve shrinks. After 9 rounds the attacker has extracted 31,357 USDT for only 18,000 USDT deposited, repays the 2,000-USDT flash loan, and walks away with ≈ 13,357 USDT of pure profit.

Background — what IntrospectionToken does#

IntrospectionToken (IntrospectionToken.sol) is a BEP-20 token with an unusual anti-speculation hook built into its _transfer (BEP20.sol:586-637). Whenever the sender is the registered exchange (the IT/USDT pair), i.e. a buy of IT, the transfer performs extra side effects (BEP20.sol:606-613):

if(address(exchange) == sender) {
    if(exchange.totalSupply() >= _lastExchangeTotalSupply) {
        updateCurrMaxUsdtRateIfNeeded();
        _makeReferralUnlocksIfNeeded(recipient, amount);
        mintToPoolIfNeeded(amount);          // ⚠️ mints fresh IT into the pair
        _mint(_owner, amount.div(20));        // ⚠️ mints 5% to owner
    }
}

The key function, mintToPoolIfNeeded (BEP20.sol:380-419), tries to keep the post-buy IT/USDT rate within +1% of the pre-buy rate. It computes what the IT reserve "should" be after the buy and, if the buy would push the price up too much, mints the difference directly to the pair:

function mintToPoolIfNeeded (uint256 amount) internal {
    ...
    uint256 tokenReserveAfterBuy = tokenReserve - amount;
    uint256 usdtReserveAfterBuy = this.min(tokenReserve.mul(usdtReserve).div(tokenReserveAfterBuy),
                                           usdtToken.balanceOf(address(exchange)));
    uint256 maxTokenUsdtRateAfterBuy = tokenUsdtRate.add(tokenUsdtRate.div(100)); // +1% cap
    uint256 tokenMinReserveAfterBuy = usdtReserveAfterBuy.mul(PRECISION).div(maxTokenUsdtRateAfterBuy);

    uint256 mintAmount;
    if(tokenReserveAfterBuy >= tokenMinReserveAfterBuy){
        mintAmount = amount.div(2);                         // even so, mint half the buy size
    } else {
        mintAmount = this.max(tokenMinReserveAfterBuy.sub(tokenReserveAfterBuy), amount.div(2));
    }
    _mint(address(exchange), mintAmount);                   // ⚠️ free IT into the pair
}

The protocol's intent is "stable price." The effect is "the pair gets free IT injected on every buy, and that IT is sitting in the pair's balance when the surrounding swap() finishes."

On-chain state at the fork block (block 36,934,258, read from the trace):

The vulnerable code#

1. mintToPoolIfNeeded — the inflationary repricing mint#

contracts_bsc_BEP20.sol:380-419 (shown above). Two problems:

• It mints into the pair (_mint(address(exchange), mintAmount)), increasing the pair's actual IT balance.
• It is invoked inside _transfer, which the pair itself calls during swap(). The pair's invariant check (balance0Adjusted * balance1Adjusted >= k) runs after _transfer returns, so it sees the post-mint balance — and the minted IT can be pulled straight back out by the same swap() call.

2. The buy side-effect is unconditional on swap vs. plain transfer#

contracts_bsc_BEP20.sol:606-613: the only gate for the mint side-effect is sender == exchange and exchange.totalSupply() >= _lastExchangeTotalSupply. There is no check that the transfer is part of a legitimate swap vs. an attacker calling pair.swap(...) with arbitrary amounts.

3. The pair's swap() accepts the attacker-computed amounts#

The attacker does not call router.swapExactTokensForTokens. They call pair.swap(amount0Out, amount1Out, to, "") directly (IT_exp.sol:72), so they fully control the output amounts — they just have to satisfy the constant-product check after the token's internal mint fires.

Root cause — why it was possible#

A Uniswap-V2 pair enforces x·y ≥ k after the swap's callbacks return. The token contract hooks into that callback to perform a value-printing side effect (_mint to the pair) that the pair then treats as genuine liquidity. This inverts the AMM's safety model:

The pair believes its reserves grew honestly (via mint/burn/deposits). In reality, the token printed reserve-side IT out of thin air mid-swap, and the attacker withdraws that printed IT for the USDT they just handed the pair.

The four compounding design errors:

1. Mint-to-pool on buy. mintToPoolIfNeeded prints new IT to the pair whenever a buy moves the rate, instead of, say, redirecting the buy or reverting. Minting to the counterparty (the pair) of an in-flight swap is the core mistake — it makes the pair's reserves attacker-controllable.
2. No swap-context discrimination. The _transfer side-effect fires whenever sender == exchange, regardless of whether the transfer is a real buy vs. the attacker's hand-rolled pair.swap() with custom outputs.
3. The constant product check sees post-mint balances. Because the mint happens inside the pair's _token0.transfer(to, amount0Out) call, the subsequent balance0/balance1 reads include the minted IT, so swap() accepts amounts that would otherwise be impossible.
4. The mint is inflationary and unbounded. Each iteration mints more IT to the pool, increasing the withdrawable IT reserve — so the attacker can loop the trick instead of depleting it.

Preconditions#

• A flash-loanable USDT balance (the PoC uses a 2,000-USDT V3 flash; on-chain the attacker funded themselves).
• The IT/USDT pair has non-trivial USDT liquidity (15,363 USDT here) — enough to extract a meaningful profit per loop.
• The token's exchange is set (it is) and mintToPoolIfNeeded is reachable on buy transfers (it always is).
• No time-gate or reentrancy guard on the buy path — _transfer runs fully each swap.

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

token0 = IT, token1 = USDT, so reserve0 = IT, reserve1 = USDT. All reserve figures are taken verbatim from the Sync events in output.txt. The attacker flashes 2,000 USDT from the V3 pool, then runs hack() which loops 9 times. Each iteration:

1. transferFrom(Money, pair, 2,000 USDT) — deposits 2,000 USDT directly into the pair (raises reserve1).
2. Computes balance0 = reserve0 - 1 (the max IT to pull out) and a precise amountout of USDT that satisfies the constant-product invariant after the token's internal mint inflates the IT reserve.
3. pair.swap(reserve0 - 1, amountout - 1, Money, "") — pulls out (reserve0 - 1) IT and amountout USDT to the attacker. Inside that swap, _transfer(pair → attacker) triggers mintToPoolIfNeeded, which mints a large IT top-up into the pair so the next k check passes — and that minted IT becomes the next iteration's reserve0.

(IT and USDT figures are /1e18. "IT minted to pool" = next row's reserve0 − this row's reserve0 − IT received back in the loop; the dominant term is mintToPoolIfNeeded.) Final IT reserve: 1,074,970.40 IT — the token printed ~939K of fresh IT into the pair over 9 swaps; final USDT reserve: 2,006.11 USDT.

Why each iteration is profitable#

The attacker deposits 2,000 USDT and pulls out ~3,590 USDT each round. The extra ~1,590 USDT per round comes from the free IT the token minted into the pair: the pair's k check passes because the post-mint IT balance is much higher than the pre-swap reserve, so the pair happily releases more USDT than the 2,000 deposited. The minted IT is then immediately withdrawn by the same swap (reserve0 - 1) and recycled — the attacker keeps only the USDT delta.

Profit / loss accounting (USDT)#

This matches the PoC log [End] Attacker USDT after exploit: 13356.873044389055648103 to the wei.

Diagrams#

Sequence of the attack#

Pool-state evolution & the flaw inside _transfer#

Why the mint is theft: constant-product before vs. after the in-swap mint#

Why each magic number#

• 2,000 USDT deposit per iteration: small enough to be flash-loanable and recycled, large enough that the +1% price-cap branch in mintToPoolIfNeeded mints a substantial IT top-up. The 2,000 USDT is returned to the attacker each round (inside amountout), so the same 2,000 is reused 9 times.
• reserve0 - 1 as IT output: pulls out essentially the entire IT reserve, maximizing both the price impact (which forces a large compensating mint) and the withdrawable IT. The -1 avoids a revert from rounding at the reserve boundary.
• amountout (computed, ~3,590 USDT): the maximum USDT the pair can release while still satisfying balance0Adjusted * balance1Adjusted >= k after the token's internal mint inflates balance0. The formula in IT_exp.sol:66-69 inverts the invariant under the 0.25% fee to solve for the exact USDT output.
• 9 iterations: the USDT reserve decays geometrically each round (15,363 → 2,006); after iter 8 the remaining USDT (~2,006) is too small to keep the per-iteration USDT delta profitable relative to gas, so the loop stops.

Remediation#

1. Never mint to the pair inside _transfer. The repricing defense should never print tokens into the AMM counterparty mid-swap. If price-stability is a product requirement, implement it as an off-chain keeper, a virtual sync()-free rebalance, or a fee — not a _mint(address(exchange), …).
2. Detect swap context. If a mint/burn side-effect must run on buys, gate it on tx.origin/msg.sender being the canonical router and revert if the transfer originates from a raw pair.swap() callback by a non-whitelisted caller.
3. Make the constant-product check authoritative. Any token that hooks _transfer for AMM-related logic must assume the pair's invariant runs after its side effects and that the attacker chooses the swap outputs — so any mint to the pair is, by construction, withdrawable.
4. Bound or disable inflationary minting. mintToPoolIfNeeded has no cap; a single buy can mint unbounded IT. A hard cap (e.g., max 0.5% of supply per block) would have killed the spiral.
5. Separate accounting from transfer. Repricing should adjust prices (e.g., via an oracle or fee), not supplies. Coupling supply emission to every pool-originated transfer is what made the loop self-sustaining.

How to reproduce#

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

_shared/run_poc.sh 2024-03-IT_exp --mt testExploit -vvvvv

• RPC: a BSC archive endpoint is required (fork block 36,934,258 is well over two years old). foundry.toml uses https://bsc-mainnet.public.blastapi.io, which serves historical state at that block; most public BSC RPCs prune it and fail with header not found / missing trie node.
• Result: [PASS] testExploit() with Attacker USDT after exploit: 13356.873044389055648103.

Expected tail (from output.txt):

Ran 1 test for test/IT_exp.sol:ContractTest
[PASS] testExploit() (gas: 1374060)
  [Begin] Attacker USDT before exploit: 0.000000000000000000
  Time :  0
  amountout 3.594282185158060009132e21
  ...
  Time :  8
  amountout 3.202235487448456075216e21
  [End] Attacker USDT after exploit: 13356.873044389055648103

Reference: DeFiHackLabs PoC — 2024-03/IT_exp/. Attack tx on BSC block 36,934,258, March 2024, ~$13.4K loss.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2024-03-IT_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: IT_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "IntrospectionToken (IT) 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.