OLPC/LABUBU's $1.12M Loss and How Olympix Would Have Prevented It
Date: June 20, 2026 (11:31 UTC), BNB Chain block 105326393
Chain: BNB Chain
Loss: 1,115,903.66 USDT (about $1.12M)
Class: pair-originated amplified burn weaponized through public AMM mechanics
Summary
On June 20, 2026, the LABUBU/OLPC pool on PancakeSwap V2 was drained of about $1.12M. The exploit did not break PancakeSwap. It abused a flaw in the OLPC token, which applied an amplified burn whenever the pool itself was the sender of a transfer. Because two ordinary PancakeSwap functions, skim() and sync(), are public and force the pool to move its own tokens, the attacker used them to make the pool repeatedly send OLPC to itself, and each of those sends triggered OLPC to burn a hugely amplified amount out of the pool. Twenty of those cycles collapsed the pool's OLPC reserve to almost nothing while its LABUBU reserve sat nearly untouched, and the attacker then bought the mispriced LABUBU for a trivial OLPC input and cashed it out to USDT. The infrastructure behaved exactly as designed. The token turned safe, permissionless AMM plumbing into a weapon against its own pool.
Background
A PancakeSwap V2 pair holds two tokens and tracks a cached reserve for each. Two of its public functions keep that cache honest. skim() sends any surplus of real balance above the cached reserve to a recipient, and sync() updates the cached reserves to match the real balances. Both are permissionless by design, and on a normal token they are harmless housekeeping. Anyone can call them, and nothing bad happens, because a normal token transfer moves exactly the amount requested and nothing more.
OLPC was not a normal token. Its transfer logic contained an amplified burn keyed to who was sending the tokens, and an owner-settable multiplier that controlled how large that burn was. Roughly 46 days before the attack, that multiplier, decimalsValue, was set from 1 to an extremely large value near 7.3e18. From that point on, the token was armed. Any transfer that OLPC treated as a buy would destroy a vastly amplified amount instead of moving it.
Root Cause
The flaw was in OLPC's _updateTransfer(). When the transfer sender was the AMM pair (from == _swapPair), the function treated the transfer as a buy, computed a burn of amount * decimalsValue, moved that amplified amount from the pair to the dead address, and then set the delivered amount to zero. So a pair-originated transfer did not deliver tokens to the recipient. It destroyed a multiplied quantity of the pair's own OLPC and handed the recipient nothing.
That behavior is dangerous on its own, but it became a drain because it composed with PancakeSwap's public functions. skim() forces the pair to transfer its surplus, which makes the pair the sender. Every time the attacker created a tiny surplus and called skim(), the pair transferred OLPC, OLPC read that pair-originated transfer as a buy, and burned surplus * decimalsValue from the pair to the dead address while delivering zero. Following each skim() with sync() wrote the reduced balance into the cached reserve, locking in the loss and setting up the next cycle.
Two conditions made this a code-level defect in OLPC's own Solidity. The amplified burn was applied to pair-originated transfers, which lets AMM mechanics rewrite reserves, and the multiplier feeding it was owner-settable with no bound. Neither is a PancakeSwap flaw. The pool did precisely what a pool is supposed to do.
Attack Flow
The attacker sent 1 OLPC to the LABUBU/OLPC pair and called sync(), setting the reserve snapshot to roughly 720,372 LABUBU and 51,928,295 OLPC.
In a loop, the attacker transferred dust OLPC into the pair, called skim(helper), and called sync(). Each effective skim() made the pair call OLPC.transfer(helper, surplus), which OLPC treated as a buy, burning surplus * decimalsValue from the pair to the dead address and delivering zero to the helper.
Across 20 skim() calls and 21 sync() calls, about 51.93M OLPC moved from the pair to the dead address, collapsing the pair's OLPC reserve to roughly 0.375 while the LABUBU reserve stayed nearly unchanged.
With OLPC's reserve gutted, the attacker pushed a small OLPC amount in and let the distorted swap path release about 688,381 LABUBU, of which about 564,128 was sellable after LABUBU's own sell tax.
The attacker routed the LABUBU through LABUBU/WBNB and WBNB/USDT into about 2,041 WBNB and finally 1,115,903.66 USDT.
Impact
The pool's OLPC reserve was destroyed and its LABUBU reserve was extracted, draining about $1.12M in realized value to the attacker and leaving the pool and its liquidity providers holding a collapsed position. Because the OLPC destruction ran through the token's own burn to the dead address rather than an obvious theft, the reserve manipulation looked like token mechanics until the LABUBU was already gone.
The Problem With Audit-Only Security
The danger here lived in a place a single-scope audit is structurally unable to see: the interaction between one token's transfer logic and the standard, permissionless functions of an exchange it never controlled.
PancakeSwap V2 is one of the most heavily audited pieces of infrastructure in the ecosystem, and an audit of it would correctly conclude that skim() and sync() are safe. They are. An audit scoped to the OLPC token, meanwhile, reads its burn logic but typically treats the pair and its public functions as trusted externals, out of scope for the review. So the token review sees a burn, and the exchange review sees safe housekeeping, and neither one simulates the token being called by the pair through a public function that anyone can trigger. The exploit exists only in the seam between them, and reviewing either side alone leaves that seam untested.
A point-in-time audit misses it a second way. The multiplier that armed the burn was set to its dangerous value roughly 46 days before the attack, long after any deployment-time review would have concluded. An audit that examined the contract when decimalsValue was 1 would have seen a burn that looked negligible, because at that value it was. The parameter that turned it into a weapon was a later change the audit never saw. A clean report describes the code as it stood on one day, and this code did not become dangerous until a day the report did not cover.
How Olympix Would Have Prevented It
Olympix analyzes a token together with the contracts it interacts with, which is the only level at which this defect is visible. A retrospective full-repo BugPocer scan of the OLPC token, run after the incident, flagged an unbounded_tokenomics_parameter finding at the token's buy branch, at the exact line where the owner-settable decimalsValue is applied to burn value * decimalsValue from the pair while crediting the buyer nothing. That is the literal code the attack ran through. The same scan flagged the sibling reserve-drain paths, unbounded_buy_tax_multiplier and amm_reserve_emptying, where a small token input drains the paired reserve, which is the exact economic shape of the exploit.
The reserve-manipulation class was confirmed as a true positive with a runnable proof-of-concept, demonstrating the core mechanic of a tiny token input draining the paired reserve. Fully reproducing the primary decimalsValue path as a standalone test requires a forked live PancakeSwap pair preloaded with the malicious multiplier, which is the ordinary character of an exploit that depends on live AMM state rather than any absence of the defect. The vulnerable code sat at a known line that the scan identified directly, with a working proof-of-concept for the reserve-manipulation twin that carried the drain. The scan was run after the incident, so it does not represent detection at the time, but it shows the defect was catchable by this analysis, which means running it before deployment would have surfaced the flaw before the token shipped.
This is why cross-contract analysis matters. The flaw cannot be seen by reading OLPC alone or PancakeSwap alone. It appears only when the token is tested against the pool and the public functions the pool exposes. This is not an argument against audits. A skilled human review remains valuable. It is an argument that an audit alone is not a security model, because a single-scope review cannot test a token against the permissionless mechanics of the market it trades into, and a point-in-time review cannot see a parameter armed weeks later. Continuous, cross-contract analysis that tests the token inside the system it runs in is what surfaces a defect like this, and a retrospective scan confirms it surfaces this one.
Takeaway
Nobody broke PancakeSwap. Its public skim() and sync() did exactly what they are built to do, and that is the point. OLPC made those safe functions destructive by applying an amplified burn whenever the pool was the sender, and an owner-set multiplier with no bound made the burn large enough to empty a reserve. The loss did not require a clever break in the exchange. It required a token that turned permissionless plumbing into a lever, and that lever was plain Solidity in OLPC that a scan identifies at the exploited line, catchable before it ever needed to run. Testing a token against the system it actually lives in, before it ships, is the difference between infrastructure that stays safe and infrastructure a token can quietly weaponize. You can see Olympix analyze your token alongside the contracts and public functions it interacts with, with a proof-of-concept for the findings that carry real loss, in a free demo.
A retrospective Olympix scan identified this token's amplified-burn and reserve-manipulation paths at the exact exploited line, the kind of defect the analysis is built to catch before deployment. If you are shipping a token or a protocol that touches an AMM, see the same analysis run against your own contracts, with a proof-of-concept for the findings that carry real loss. Book a free demo.
What’s a Rich Text element?
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.
