The $190K LAXO Token Exploit and How Olympix Would Have Prevented It
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.
What Happened
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 Attack, Step by Step
1. Flash loan acquisition
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.
2. Triggering the burn
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.
3. Price inflation
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.
4. Profit extraction
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.
Root Cause: The Burn-from-Pair Mechanism
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.
What Olympix Found After the Exploit
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.
[Medium] LP Value Extraction via Sell Burn: Primary Finding
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);
// FAILS: pair did not gain LAXO from the sell assertGt(pairLAXOAfter, pairLAXOBefore, "VULNERABILITY: Pair did not gain LAXO from the sell."); }
[High] Overly Broad Bypass on Max Burn Reached
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.
[Medium] Flash Loan Griefing via Reserve Manipulation
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.
[Low] Fee and Restriction Bypass via Direct Burn Donation
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.
How Olympix Would Have Prevented This
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:
The exact burn-from-pair logic flagged as an LP value extraction vulnerability, with a Foundry PoC proving the failure on a live BSC fork
The isReachedMaxBurn bypass flagged as high-severity: a single condition that silently disables every protocol protection
The flash loan reserve manipulation vector identified as a denial-of-service risk, directly foreshadowing the attack path
These 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.
The Broader Pattern
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.
Don't Wait for the Post-Mortem to Be About You
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.
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.
Follow-up: Conduct a follow-up review to ensure that the remediation steps were effective and that the smart contract is now secure.
Follow-up: Conduct a follow-up review to ensure that the remediation steps were effective and that the smart contract is now secure.
In Brief
Remitano suffered a $2.7M loss due to a private key compromise.
GAMBL’s recommendation system was exploited.
DAppSocial lost $530K due to a logic vulnerability.
Rocketswap’s private keys were inadvertently deployed on the server.
Hacks
Hacks Analysis
Huobi | Amount Lost: $8M
On September 24th, the Huobi Global exploit on the Ethereum Mainnet resulted in a $8 million loss due to the compromise of private keys. The attacker executed the attack in a single transaction by sending 4,999 ETH to a malicious contract. The attacker then created a second malicious contract and transferred 1,001 ETH to this new contract. Huobi has since confirmed that they have identified the attacker and has extended an offer of a 5% white hat bounty reward if the funds are returned to the exchange.
