TIPMine exploit analysis

TIPMine lets anyone call mine(), and the function it exposes is wired to a live Pancake pair for the TIP and SOL tokens on BNB Chain. SOL here is a BEP-20 token that uses the ticker, not Solana's native asset. Calling it moves two percent of TIP's supply straight out of that pair and then forces the pair to resync its reserves. The result is a pool holding the same SOL and a fraction of the TIP it held a moment earlier. DeFiHackLabs records the incident and ships a proof of concept that runs the sequence against a fork of the chain.

Two guards, neither of them an access check

mine() carries a supply condition and a once-a-day timer. Both are satisfied on a contract that has never been called: lastMineTime starts at zero, so block.timestamp >= lastMineTime + 1 days holds on the first transaction anyone sends. There is no owner check, no role, no signature, no keeper. The first caller to arrive runs it.

That matters less for who may call than for what calling does. mine() hands the work to the TIP token: burnFromPool transfers TIP out of the pair directly to the burn address, and distributeFromPool pushes the remainder out to the staking core. Both end with _syncPool(), which asks the pair to overwrite its stored reserves with the balances actually sitting in it.

Why the resync is the damage

A constant-product pair holds its price by refusing to let its reserves move except through a swap that pays the curve. Forcing a resync breaks exactly that guarantee. Reserves are no longer the product of the trades that produced them, only the current token balances, so the invariant the pool was priced under no longer holds.

The proof of concept's notes report the effect as measured on a fork. After the attacker's 35,121 SOL dump (step 2 below), a single call to mine() from an address with no privilege moves 2,000,000,000 TIP out of the pair and drops its TIP reserve from 2,000,053,839 to 53,839. The SOL reserve, already swollen by the dump, reads 35,837 before and after.

An attacker holding TIP at that moment is holding a claim on the SOL side that the pool's own accounting no longer backs.

The sequence

1. Buy a small TIP position using 1 SOL.
2. Swap 35,121 SOL into the pair, which pushes most of the pool's TIP onto the attacker's side of the curve.
3. Call mine().
4. Sell the held TIP back into the repriced pair.

Step 2 is the part that makes the drain large rather than merely possible. Removing most of the pool's TIP means the remaining reserve is small enough that the 2 percent mine() removes is a large share of what is left.

The proof of concept's notes also report a control: the same buy, dump and sell sequence with mine() left out turns a profit of about 706 SOL into a loss of roughly 31,563 SOL, which is the ordinary cost of round-tripping that much value through the curve. The call is what carries the attack.

Capital and result

The attacker needed roughly 36,000 SOL of working capital, assembled inside the transaction from a SOL borrow on a Venus fork, about 14,404 SOL collateralised by a 206,503 WBNB flash loan, and about 21,664 SOL borrowed from 13 separate pools, all repaid in the same transaction. The BEP-20 SOL token has little liquidity outside the pools that quote it.

DeFiHackLabs records a loss of about 667 SOL drained from the TIP and SOL pair on BNB Chain. The chain agrees with that reading: the attack transaction 0xa7b879b5d4252fa5b518db1f81be8a5cc670c5b978c7626fa287c0a1f37895a3 at block 128,188,934 ends with a transfer of 667.228863551156127021 SOL to the attacker's address. The proof of concept reconstructs 706.253909658913182860 SOL, the pair's full reserve net of the curve residual, and attributes the gap to the borrow interest and flash premiums that its fee-free modelled capital does not pay.

Where the guard was missing

The timer and the supply flag were never doing this job. A resync that any caller can trigger is the actual hazard. Burning tokens out of a pair that is still quoting a price needs either a pair that is not live or a reserve update that charges the difference to whoever caused it.

BYToken is the closest precedent. Its permissionless triggerAutoBurn collapsed the BY reserve of its Pancake pair after the attacker had cornered BY supply through router swaps, and a small sell then drained the WBNB side. TIPMine follows the same order: the 35,121 SOL dump comes before the call that shrinks the reserve. DIP reached a deflated reserve by a different route, a sell fee burned twice in one swap followed by skim() and sync().