Date: February 22, 2026
Chain: BNB Smart Chain
Amount Lost: ~$190,000
Attack Vector: Flash loan + burn-from-pair price manipulation
Root Cause: _transfer function burns tokens from the liquidity pair's balance before updating reserves, enabling artificial price inflation
On February 22, 2026, the LAXO token on BNB Smart Chain was drained of approximately $190,000 in a single transaction. The attacker didn't find an exotic zero-day. They didn't need one. They exploited a logic flaw baked into the token's own transfer function: one that burned tokens directly out of the liquidity pool, collapsed the supply, and handed them a 21x price multiplier to cash out against.
Two more attackers copied the attack within 13 minutes of the first. The vulnerability wasn't subtle. It was detectable before a single line of code was ever deployed to mainnet.
After the exploit, we ran Olympix's BugPocer on the LAXO contract. It found the vulnerability, with a working proof-of-concept, in minutes. If the team had run BugPocer before deployment, this exploit never happens.
The LAXO token implemented a deflationary burn mechanism designed to reduce supply on every sell. The intention was straightforward: as tokens are sold, some get burned, creating long-term scarcity for holders. In practice, the implementation had a critical flaw that inverted this logic into a weapon.
When a sell was triggered, the _transfer function burned tokens directly from the Uniswap pair's balance, not the seller's, and immediately called sync() to update the pool's reserves. The seller's tokens arrived at the pool only after this sequence completed. The result: the pool's LAXO balance was permanently reduced on every sell, while LP providers bore 100% of the deflationary cost.
Under normal conditions, this quietly drained value from LP providers on every trade. Under a flash loan, it became catastrophic.
The attacker borrowed 350,000 USDT from a PancakeSwap V3 pool via flash loan and used it to purchase approximately 43 million LAXO tokens from the LAXO/USDT liquidity pool.
The attacker called the transfer function, routing tokens through the sell path. This triggered the burn-from-pair mechanism: 41 million LAXO tokens were burned directly from the pair's balance and sent to the DEAD address (0x000...dEaD). The pair's sync() was called immediately after, updating reserves to reflect the new, drastically reduced supply.
Before the attack, the LAXO/USDT pool held approximately 54 million LAXO against 500,000 USDT, a price of roughly $0.0116 per token. After 41 million LAXO were burned from the pool, the pair held approximately 13 million LAXO against the same 500,000 USDT. The effective price surged to approximately $0.038 per token, a more than 3x increase in that step alone, ultimately reaching a 21x price distortion at peak manipulation.
The attacker sold their remaining LAXO holdings at the inflated price, receiving approximately 487,500 USDT. After repaying the 350,175 USDT flash loan, they walked away with approximately $137,000 in net profit from the first run alone. Two additional attackers exploited the same vulnerability within 13 minutes, bringing total losses to approximately $190,000.
The vulnerability lives in the sell path of LAXOToken.sol's _transfer function. A simplified version of the logic looks like this:
// During a sell (recipient == pair):
uint256 actualBurn = (amount * burnRate) / 100;
// Burns tokens directly from the PAIR's balance (not the seller's)
_burn(pair, actualBurn);
// Updates reserves to reflect the reduced pair balance
IPancakePair(pair).sync();
// Only NOW does the seller's tokens arrive at the pair
super._transfer(sender, pair, amount - fee);
Because sync() is called between the burn and the seller's transfer, the AMM's reserve calculation for the outgoing swap uses the post-burn reserve. This means the seller receives a better price than they should, at the direct expense of LP providers who permanently lose actualBurn tokens on every transaction.
At normal sell volumes, this is a slow drain. With a flash loan amplifying the sell size to tens of millions of tokens, it becomes a single-block wipeout.
After the LAXO attack, we ran BugPocer on the contract to see what proactive analysis would have surfaced. It returned five severity-ranked findings, each backed by a working Foundry proof-of-concept on a BSC fork, covering the exact attack surface the attacker exploited. All of this would have been in the team's hands before deployment, if they had run it.
BugPocer identified the core vulnerability directly. The finding stated:
"During a sell, the code burns actualBurn tokens directly from the Uniswap pair's balance to the DEAD address, then calls sync() to update reserves, and finally transfers the seller's burnAmount tokens to the pair. Because sync() is called between the burn and the seller's transfer, the reserves are reduced by actualBurn before the swap calculation occurs... LP providers permanently lose actualBurn tokens on every sell, while the seller gets an improved price from the reduced reserve."
The generated PoC deployed LAXO on a BSC fork with a 100K LAXO / 100K USDT liquidity pool, executed a sell through the PancakeSwap V2 router, and asserted that the pair's LAXO balance increased after the sell, as any correctly implemented AMM would guarantee. The assertion failed. The pair gained zero net LAXO while paying out USDT. LP providers bore 100% of the deflationary cost.
function test_sellBurnsFromPairDrainsLPValue() public {
uint256 pairLAXOBefore = laxo.balanceOf(pair);
vm.startPrank(seller);
laxo.approve(address(router), sellAmount);
router.swapExactTokensForTokensSupportingFeeOnTransferTokens(
sellAmount, 0, path, seller, block.timestamp
);
vm.stopPrank();
uint256 pairLAXOAfter = laxo.balanceOf(pair);
// FAILS: pair did not gain LAXO from the sell
assertGt(pairLAXOAfter, pairLAXOBefore,
"VULNERABILITY: Pair did not gain LAXO from the sell.");
}
BugPocer also flagged that when isReachedMaxBurn() returns true, the _transfer function bypasses all protocol logic, not just the burn mechanism. This includes the buyEnabled check, buy quota enforcement, sell fees, buy fees, and all liquidity restrictions. A single condition silently disables every protection the protocol has.
The PoC forced the DEAD address balance past MAX_BURN and demonstrated that buys succeed despite buyEnabled being false and sells collect zero fees.
The buy quota mechanism derives USDT-equivalent costs from instantaneous Uniswap pair reserves via getReserves(). Because reserves can be manipulated intra-block via flash loans, an attacker can transiently skew reserves to cause targeted buy transactions to revert, a denial-of-service vector that also foreshadows the price manipulation path used in the actual exploit.
isReachedMaxBurn() checks balanceOf[DEAD] >= MAX_BURN. Since anyone can transfer tokens directly to address(0xdead), a whale or coordinated group can prematurely trigger this state, permanently disabling all fee collection and protocol protections, with no admin recourse.
The LAXO exploit was not a novel attack. It was a textbook consequence of a specific implementation choice: burning from the pair before the swap settles. Olympix's analysis engine is purpose-built to detect exactly this.
We ran BugPocer on the LAXO contract after the exploit. Running it before deployment would have put the following directly in the team's hands:
isReachedMaxBurn bypass flagged as high-severity: a single condition that silently disables every protocol protectionThese aren't theoretical findings. They are executable proofs, the same class of evidence an attacker develops before striking. BugPocer generates them automatically and hands them to the development team first.
The $190,000 loss was not inevitable. It was the cost of shipping code that had never been stress-tested against the conditions an attacker would actually use. One BugPocer session, run before mainnet, changes the outcome entirely.
LAXO is not an isolated case. The same exploit pattern, burn-from-pair combined with sync() misuse and flash loan amplification, has appeared repeatedly across BNB Chain. In February 2026 alone, flawed burn mechanisms cost BNB Chain protocols over $300,000. The SOF token was drained the same week via the same vulnerability class.
Deflationary token mechanics are popular. The assumption that they behave safely under adversarial conditions (flash loans, large sells, reserve manipulation) rarely gets tested before deployment. When it doesn't, LP providers are the ones who absorb the cost.
The fix for LAXO's primary vulnerability is not complex: burn from the seller's tokens, not the pair's balance. Never call sync() between a burn and the corresponding transfer. Test your sell path against flash-loan-scale inputs before mainnet. These are not exotic requirements. They are the baseline that proactive security tooling can enforce automatically.
Every exploit post-mortem tells the same story in different numbers: a vulnerability that was detectable before deployment, found only after funds were lost.
Olympix's BugPocer exists to change that sequence. It finds the issues your auditors might miss, proves them with working exploits, and hands them to your team before the attacker gets there first.