A brand-new Ethereum wallet received 1,000,000,000,000,000 MAPO in a single transaction. How did this happen, what are the consequences and what can we learn?
Author: Sahil Thakur
On 20 May 2026, a brand-new Ethereum wallet received 1,000,000,000,000,000 MAPO in a single transaction. That’s one quadrillion tokens, conjured out of nothing. The whole thing is still sitting on Etherscan for anyone to pull up and read line by line.
Here’s the part that surprised a lot of people. The MAPO token contract was never the weak point. The Butter Bridge exploit worked because the bridge that wraps MAP Protocol’s token onto Ethereum had a flaw in how it checked cross-chain message retries. The attacker didn’t break the token. They convinced the bridge that a forged message was one it had already approved, and the bridge minted accordingly.
The core event is easy to state. At 16:13:59 UTC on 20 May 2026, in block 25137572, an externally owned account ending in 4279 called a purpose-built exploit contract. That call routed through Butter Bridge V3.1 and ended with the Ethereum-wrapped MAPO token minting a quadrillion units to the attacker.
The transaction left a clean paper trail. It emitted a token Transfer from the null address, the signature of a fresh mint, plus an InterReceive event on the MAPO contract and a MessageIn event on the bridge. In plain terms, the mint came through the bridge’s receive path. It was not a bug in the MAPO token’s own code.
What did the attacker actually walk away with? Not a quadrillion dollars, obviously. A token with no real liquidity behind a number that large is close to worthless on paper. The real money came from selling. According to security firm Blockaid and on-chain observers, roughly 1 billion of the freshly minted MAPO got dumped into the ETH/MAPO market on Ethereum, pulling out around 52.21 ETH, or about 180,000 US dollars. That figure is reported rather than something I’d present as audited to the last decimal, but it lines up with the drain pattern visible on-chain.
MAP Protocol moved fast once it noticed. The team paused the bridge between MAPO ERC-20 and mainnet MAPO, and Butter was reported to have paused ButterSwap while a fix was prepared. MAP also said something worth repeating, because it narrows the problem considerably: this was not a private key compromise, not a light-client failure, and not a defect in the MAPO token itself. The bug lived in one specific place, the bridge’s retry logic.
Src: Etherscan
This is where the abi.encodePacked collision comes in, and it’s worth slowing down for, because the same mistake shows up in plenty of other contracts.
Cross-chain bridges relay messages. Sometimes a message fails on arrival and has to be retried later. To make sure a retry is genuine, the bridge stores a hash of the original message and checks any retry against it. Butter’s retry path built that hash with keccak256(abi.encodePacked(...)) over several dynamic byte fields, something like initiator, from, to, and the swap payload.
That’s the flaw. Solidity’s own ABI documentation warns about it directly. Packed encoding doesn’t store the length of each field. So if you concatenate two or more dynamic fields and hash the result, the boundaries between those fields disappear. The hash sees one long ribbon of bytes, not four labeled boxes.
Picture two adjacent fields holding “abc” and “def”. Packed together they become “abcdef”. Now split them as “ab” and “cdef” instead. Still “abcdef”. Same hash. Two genuinely different messages, identical fingerprint. That’s the abi.encodePacked collision in one sentence, and it’s exactly why the Solidity docs say to use abi.encode when more than one argument is dynamic.
Blockaid laid out the exploit as a deliberate three-step sequence, and MAP Protocol later backed the same conclusion. It wasn’t a lucky parser glitch. It was staged.
First, the attacker sent a legitimate message aimed at an address that had no code yet, an empty slot they had already computed in advance. The message failed with a “not a contract” error, which is a retriable failure, so the bridge stored a retry commitment for it.
Second, they deployed their exploit contract at that exact precomputed address. Now there was code where the bridge expected none.
Third, they called the retry, but with the same packed bytes split along different field boundaries. The retry hash still matched the stored commitment, so the bridge waved it through as authentic. The downstream receive logic, though, now read those bytes as a different set of instructions, and those instructions told the MAPO contract to mint. A forged message that passed a real authentication check. That’s the whole Butter Bridge exploit, compressed.
The cleanest evidence sits inside the exploit transaction itself. The bridge’s MessageIn event and the token’s InterReceive event don’t agree with each other. The bridge logged a message with token set to the zero address and amount zero, going to the MAPO contract. The token, in the same transaction, logged a transfer of a quadrillion MAPO to the attacker. When the authentication layer and the execution layer read the same bytes and come to two different conclusions, you’re looking at exactly the kind of ambiguity a packed-hash collision produces.
One thing this incident has going for it, from a researcher’s point of view, is that the main mint is fully public and verifiable. You don’t have to trust a summary. You can open the block and look.
The addresses that matter, all on Ethereum:
That receiver contract is worth a second look, because it shows how much privileged surface a cross-chain system tends to expose. Its verified ABI includes owner-controlled functions such as setAuthorization, updateKeepers, setBridgeAddress, and rescueFunds. None of those are the root cause here. But they’re a reminder that bridge and executor contracts hold powerful levers, and once a generic message-execution path gets tricked, that’s the machinery an attacker inherits.
After the mint, a second cluster of transactions shows value leaving the bridge. Between roughly 16:39 and 16:53 UTC, a burst of Message In executions ran on the bridge. One leg that’s independently checkable is transaction 0x829ed2a1…dafe5449 in block 25137766, which moved 0.041212877606648268 WETH from the bridge into a receiver contract and onward toward Uniswap V4’s Pool Manager.
That single leg is tiny, but it’s representative. The pattern across the cluster is consistent with post-mint market selling being settled and routed out: forged receive, massive mint, MAPO sold into liquidity, WETH pushed out through Butter’s execution contracts into Uniswap V4. The complete money trail isn’t something I can reconstruct down to the last wei from public explorer pages alone, and I’d rather say that plainly than overclaim. The shape of it, though, isn’t in doubt.
Blockaid and several community trackers also flagged BNB Chain as affected, with a similar MAPO mint there. That second mint is widely reported, but the exact BSC transaction hash isn’t something I could independently recover, so treat the BSC leg as reported rather than verified here.
The MAPO infinite mint and its fallout unfolded over a few hours on a single afternoon. All times are UTC.
Key events related to the MAPO infinite mint incident
One quadrillion MAPO is minted to the attacker in block 25137572.
Blockaid reports that Butter Bridge V3.1 was exploited on Ethereum and BSC. PeckShield amplifies the alert shortly after.
A cluster of Message In executions routes value out through the bridge.
MAP Protocol confirms the incident and says the MAPO ERC-20 bridge is paused.
Butter is reported to pause ButterSwap and begin patch, audit, and redeployment work.
The issue is linked to a collision in keccak256(abi.encodePacked(…)) across multiple dynamic fields in the retry path.
Read that sequence back and one thing stands out. Detection was quick. The first public warning came about twenty minutes after the mint. But containment lagged the market. By the time the bridge was paused, the fresh MAPO had already reached liquidity and the selling had started. Fast alerting is not the same thing as fast protection, and this gap is the part bridge teams should sit with.
It helps to split the damage from this cross-chain bridge hack into three layers, because they’re not equally certain.
The first layer is supply corruption, and it’s beyond dispute. The exploit transaction itself shows the quadrillion-MAPO mint from the null address. After the incident, Etherscan’s MAPO page reflected a total supply figure near one quadrillion and a price move of around minus 69.84 percent.
The second layer is realized loss. Blockaid and on-chain observers put the liquidity extraction at roughly 52.21 ETH, about 180,000 dollars, after around 1 billion MAPO was dumped into the ETH/MAPO market. That number is plausible and consistent with the drain legs visible on-chain, but it’s secondary reporting, not a figure I summed transaction by transaction.
The third layer is operational disruption. The MAPO ERC-20 bridge was paused. ButterSwap was reported paused. MAP Protocol also said its Arbitrum bridge auto-locked after detecting abnormal account-balance variation, and that user funds there stayed safe. So Arbitrum shows up in this story as a system that reacted correctly, not as a chain that got drained.
One honest caveat on the numbers. Public supply references for MAPO don’t agree. Some sources describe a legitimate baseline around 208 million MAPO, third-party market data showed a circulating figure in the billions, and the explorer reflected a post-incident supply near a quadrillion. The exact dilution multiple depends entirely on which baseline you treat as the real one. None of this is financial advice, and anyone touching bridged MAPO should verify the current supply state directly before assuming anything.
The immediate response covered the obvious bases. MAP Protocol acknowledged the MAP Protocol exploit publicly, paused the bridge between MAPO ERC-20 and mainnet MAPO, and adopted Blockaid’s root-cause framing. Butter was reported to keep ButterSwap paused while it worked on a patch, an audit, and a redeployment.
MAP’s framing of the MAP Protocol exploit did real work here. By ruling out a key compromise, a light-client problem, and a token bug, the team narrowed the fix to one component: the Solidity retry logic. That’s a much smaller and more tractable problem than “the bridge is broken somewhere.”
What I couldn’t verify is the cleanup. As of late May 2026, there was no publicly recovered burn transaction reversing the inflated supply, no wrapper rollback, and no public patch commit with a visible diff. Butter’s public GitHub repositories still showed their last indexed updates in April 2026, before the exploit. That doesn’t mean no patch exists. Private branches and unindexed commits are normal. It just means the verifiable, machine-checkable proof of remediation wasn’t there to point at yet.
Strip away the specifics and the Butter Bridge exploit is a lesson that applies far beyond one bridge. Several lessons, actually.
Start with the obvious one. Don’t use abi.encodePacked for anything security-sensitive when more than one dynamic field is involved. Authentication checks, replay protection, signature-equivalent hashing, integrity commitments, none of them. Use abi.encode, which keeps the length prefixes, or a typed, domain-separated hash in the style of EIP-712 where every field’s type and length are explicit. The abi.encodePacked collision is a documented footgun, not an exotic zero-day, and that’s almost the most uncomfortable part.
The deeper lesson is about what you authenticate. Butter’s retry path appears to have authenticated a flat blob of bytes, while the receive path decoded meaning from those same bytes under a different schema. A retry check should authenticate a canonical message object, not a lossy concatenation. Bind the order ID, source and destination chains, token, receiver, call target, and a hash of the payload, and make sure retry validation and final execution use the exact same serialization. If the two layers can disagree about what a message says, an attacker will find the gap between them.
Then there’s blast radius. A bridge that mints wrapped tokens should not expose unlimited mint authority through generic message execution. A safer design isolates minting behind a single-purpose gateway with hard caps. Those caps should apply per order, per asset, and per time window. Even if a message route gets forged, an independent mint-control layer should refuse massive supply creation. Circuit breakers on supply and market price belong in the core design. They should not sit in a dashboard that pages someone later.
The last lesson is disclosure. Detection here was genuinely fast. But assessing damage still means stitching together explorer pages, a security firm’s thread, and official posts. A complete incident pack would list every affected chain and every exploit transaction hash. It would also include pause transactions, burn or remediation transactions, the patched commit, and the fix’s audit status. Until that exists, integrators are guessing.
For anyone holding or routing bridged MAPO, the practical takeaway is blunt. A wrapped bridge token is only as trustworthy as the weakest authenticated path behind it. This one failed on a mistake the language’s own documentation warns against. Until MAP Protocol and Butter publish proof, caution is warranted. That means a verifiable patch commit, a clean re-audit, and proof the inflated supply was handled. Until then, treat bridged MAPO as unconfirmed. Verify its state yourself before trusting it.
