Executive summary
MAP Protocol's Butter Bridge v3.1 was exploited in early May 2026, with an attacker minting approximately one quadrillion MAPO tokens and extracting liquidity via on-chain swaps. The scale of the mint, 1,000,000,000,000,000 MAPO, was not constrained by any economic backing, and the attacker converted a portion of the fabricated supply into real assets before the protocol paused bridge operations.
Secondary reporting, citing analysis of the OmniServiceProxy contract's retryMessageIn function, points to a dynamic-type packing collision as the likely abuse path. Official root-cause confirmation from MAP Protocol was still pending at the time of this analysis.
Key concepts: This analysis covers token minting, smart contract vulnerability, DeFi attack, verification bypass and related blockchain security topics.
What happened
Butter Bridge v3.1, the cross-chain messaging layer in MAP Protocol's ecosystem, appears to have exposed an abuse path through its message retry mechanism. The attacker reportedly exploited the retryMessageIn function in the OmniServiceProxy contract, the component responsible for processing and re-executing cross-chain messages that failed on first attempt.
Secondary technical reporting suggests the vulnerability is a known Solidity footgun: using keccak256(abi.encodePacked(...)) to form a message authenticity preimage across multiple dynamic byte arrays. When field boundaries in the packed encoding can be manipulated to collide with an existing commitment hash, the retry path can be tricked into treating a fabricated message as previously approved, allowing an attacker to execute a destination-side mint without a legitimate corresponding source-side event.
The attacker minted approximately one quadrillion MAPO to a single wallet address, then swapped a portion of the minted supply to extract ETH and other liquid assets. MAP Protocol responded by pausing bridge operations between MAPO ERC-20 and mainnet MAPO following the exploit.
Why abi.encodePacked is dangerous for authenticity checks
The abi.encodePacked function does not pad its inputs to fixed widths, it packs them tightly. When two or more dynamic-length fields are packed together, the boundary between them is lost. A hash computed over abi.encodePacked(fieldA, fieldB) can collide with a hash computed over abi.encodePacked(fieldA', fieldB') where the field boundaries have simply shifted. This means an attacker can craft inputs that produce a hash matching an existing approved commitment, without any of the original authorised values.
Using this as an authenticity check for cross-chain message replay protection is a single-point-of-failure design: if the collision can be engineered, the entire validity gate fails. The Solidity documentation explicitly warns against using abi.encodePacked with multiple variable-length arguments for this reason.
What defenders can learn
Use abi.encode instead of abi.encodePacked for commitment hashes. abi.encode pads each field to 32 bytes, preserving boundaries and making collision attacks structurally much harder. Any contract computing a preimage for a message hash or authenticity check over multiple dynamic fields should default to abi.encode.
Treat retry paths as primary attack surface. Message retry and replay mechanisms exist to recover from failures, but they also represent a second opportunity to replay a manipulated message. Every retry path should apply the same validation logic as the initial message, with no relaxation of authenticity checks.
Mint operations on cross-chain messages require defence-in-depth. Any bridge that can trigger a token mint on the destination chain is operating with a high-consequence execution path. Rate limits, total supply caps, and circuit breakers on destination-side minting are compensating controls that can contain the blast radius of an exploit even if the core validation fails.
Key details
- Protocol: MAP Protocol / Butter Bridge v3.1
- Affected contract:
OmniServiceProxy - Suspected vulnerable function:
retryMessageIn - Issue class:
abi.encodePackeddynamic-type packing collision in a message authenticity preimage - Attacker address:
0x40592025… - Response: MAP Protocol paused the MAPO ERC-20 / mainnet bridge following the exploit
Further reading
If your protocol relies on bridge or messaging infrastructure with mint capabilities, Security4Web3 can help you review message validation paths, model retry attack surfaces, and build circuit breaker controls before they're needed.
Cross-Chain Bridge Attack Surface: A Security Operations Perspective
The MAP Protocol / Butter Bridge exploit is a textbook example of a pattern that repeats across bridge incidents with remarkable consistency: a message replay or retry mechanism, a validation shortcut, and an unbounded mint capability on the destination side. The specific technical details vary — hash collision this time, signature reuse another time — but the structural shape of the attack is predictable. That predictability is both a warning and an opportunity.
If the attack pattern is predictable, the defensive posture can be designed in advance rather than assembled after the fact. That is the security operations perspective that is largely absent from DeFi bridge design today.
Bridge Exploits Follow Recognisable Patterns
Reviewing bridge incidents across the last three years, the common themes are: validation logic that can be manipulated through carefully crafted inputs; retry or replay paths that apply relaxed checks compared to the initial execution path; and destination-side mint or release operations that lack independent rate limits or supply caps as compensating controls. The MAP Protocol incident fits this template precisely.
A security-first bridge design treats every one of these patterns as a primary threat model and designs explicit controls to address each:
- Validation invariants should be formally specified: For any function that can trigger a mint or asset release, the conditions under which it will execute should be expressed as a formal invariant, not just implemented in code. If the logic cannot be precisely stated, it cannot be reliably enforced.
- Retry paths are primary attack surface: Any mechanism that re-executes a previously failed message must apply identical validation to the original. Relaxing checks on retries is a structural vulnerability — the MAP Protocol incident demonstrates what happens when this assumption breaks.
- Pause mechanisms must be pre-built and pre-tested: MAP Protocol's bridge pause worked. But the damage had already been done before it was invoked. An effective pause mechanism requires a detection capability that fires fast enough to trigger the pause while there is still something to protect.
- Mint operations need hard supply limits: A bridge that can mint approximately one quadrillion tokens to a single address is operating without a circuit breaker. Per-transaction mint caps and total supply validation are compensating controls that constrain the blast radius even if the core validation path is compromised.
The Incident Response Gap in Bridge Operations
Most DeFi protocol teams have a pause function. Very few have a tested incident response plan that covers who decides to invoke it, on what evidence, within what time window, and what communications follow. That gap — between having a technical control and having an operational procedure for using it — is where significant additional loss occurs in every major bridge exploit.
Our DeFi protocol bridge audit covers validation logic, retry path security, and mint control design as a connected security model, not as isolated technical checks. For teams building or operating bridge infrastructure, our incident response planning service ensures that when the pause button needs to be pressed, the team knows exactly how to press it — and what happens next.