How MEV Bots Hijacked a $4.1M DeFi Exploit — And Claimed the Power to Decide Who Gets Repaid

When Makina Finance was hit by a multimillion-dollar exploit, it wasn’t the protocol’s governance, security council, or even the attacker who ultimately dictated where most of the money went. It was a Maximal Extractable Value (MEV) builder.

The incident exposes a structural shift in how DeFi exploits play out on Ethereum. MEV bots and builders have become an informal emergency-response layer that can front-run thieves and intercept funds in real time. But because they operate as profit-driven intermediaries with no predefined obligations, they also end up deciding—case by case—who gets repaid and on what terms.

The Makina Finance Exploit: When the Rescuer Becomes the Custodian

Makina Finance suffered a flash-loan and oracle manipulation exploit that drained 1,299 ETH, around $4.13 million at the time. The attacker broadcast their draining transaction to Ethereum’s public mempool, expecting it to be included in an upcoming block and settled like any other trade or transfer.

Instead, the transaction became an opportunity for the block-building supply chain.

An MEV builder, identified on-chain by the address 0xa6c2, constructed and relayed a competing transaction that front-ran the exploit. Rather than letting the attacker move the funds off-chain, the builder’s transaction executed first and redirected most of the stolen ETH into addresses under builder-controlled custody.

The attacker’s original transaction failed. From the perspective of Makina’s users, this avoided an immediate, irreversible loss: the funds were not successfully extracted by the exploiter.

But the deeper issue is where those funds landed and what that implies. Instead of being controlled by Makina, a court-appointed custodian, or a pre-authorized white hat, they now reside in two addresses associated with the MEV builder. There is no on-chain guarantee about what happens next—only informal expectations and whatever negotiations may occur off-chain.

The Makina case crystallizes a broader reality: in modern Ethereum, whoever controls transaction ordering during an exploit often becomes the de facto custodian of user funds, even when they never touched the protocol itself.

MEV Bots as an Unofficial Emergency-Response Layer

The Makina episode is not isolated. Chainalysis documented a similar dynamic during the 2023 Curve and Vyper exploit, where a combination of white hat responders and MEV bot operators helped recover funds and reduce realized losses compared with the initial damage.

The pattern is mechanical and rooted in how public transaction ordering works:

• An exploit transaction hits the public mempool, visible to anyone running the right infrastructure.
• MEV searchers scan for profitable opportunities—this includes both exploit attempts and rescue attempts.
• If a searcher spots a way to construct a transaction that executes before the attacker’s and reroutes the funds elsewhere, they bundle it and submit it to a block builder.
• Builders select the most profitable bundle; if their block wins the race to be proposed and finalized by a validator, the searcher’s transaction executes and the attacker’s fails.

Sometimes this behavior looks like altruism: funds that would otherwise be stolen are effectively “saved.” But under the hood, it is profit extraction with a beneficial side effect. Searchers and builders are responding to financial incentives around ordering, not to normative judgments about who should be made whole.

Still, this MEV-driven interception has become one of the most reliable real-time defenses against exploits. It operates at the transaction-ordering layer, which is often faster and more decisive than protocol-level circuit breakers, governance votes, or after-the-fact law enforcement.

That reliability comes with a critical tradeoff: whoever wins the ordering race acquires leverage over the outcome. In Makina’s case, that leverage now sits with a builder that has no pre-agreed service-level agreement (SLA), no on-chain bounty schedule, and no formal obligation to the affected users.

Centralization Risks: When a Handful of Builders Control the Lifeboats

The uncomfortable reality is not just that MEV builders can rescue funds. It’s that a small subset of them sit at the center of almost every block—and therefore at the center of almost every potential rescue.

On Ethereum, MEV-Boost dominates block production. Data from Rated’s relay explorer shows that roughly 93.5% of recent blocks are routed via MEV-Boost, while only about 6% use “vanilla” block production without the MEV-Boost relay pipeline.

Within that 93.5%, the relay market is itself concentrated. Ultra Sound Money handles around 29.84% of relay traffic, and Titan manages roughly 24.24%. Together, the two largest relays account for over 54% of block production routed via MEV-Boost.

This topology has immediate governance implications. If most blocks—and therefore most possible rescue opportunities—flow through MEV-Boost, and more than half of that flow concentrates in just two relays, the effective “emergency-response” layer for DeFi is highly intermediated and structurally dependent on a narrow group of infrastructure providers.

That raises a series of unresolved questions:

• If a builder ends up holding rescued funds, who is authorized to custody them?
• Who sets the bounty for returning them, and based on what standard?
• What prevents an implicit ransom dynamic—“pay more than the norm or the funds remain stuck”?
• How does jurisdiction matter if the builder is offshore, anonymous, or operating under weak enforcement?

None of these questions have standardized answers today. In Makina’s case, the funds are in builder-controlled addresses, but there is no public SLA, no predefined bounty, and no formal recovery pipeline back to Makina or its users. The builder could return the funds voluntarily, negotiate terms, demand an above-market fee, or refuse to cooperate at all.

Private routing deepens the opacity. A 2025 academic paper titled “Sandwiched and Silent” found that many users who suffer MEV sandwich attacks migrate to private order flow channels instead of the public mempool. But moving off the public mempool does not eliminate MEV; it simply channels it through private, builder-controlled order flow, where visibility is lower and participation is more exclusive.

For protocols, that means public mempool-based rescues become less predictable over time. As more flow moves into private routes only a subset of builders can see, the power to intercept or influence exploits concentrates further into a small number of hands.

Safe Harbor: Turning Ad Hoc Rescues into a Formal Framework

One attempt to address this emerging power imbalance is Safe Harbor, a framework developed by SEAL that seeks to replace the “accidental custodian” model with defined roles, explicit SLAs, and bounded incentives.

SEAL describes Safe Harbor as a combined legal and technical framework that allows protocols to pre-authorize white hat responders to intervene during active exploits. The core operational rule: when white hats rescue funds under Safe Harbor, they must send them to official recovery addresses within 72 hours, in exchange for pre-defined, enforceable bounties.

The framework is explicitly shaped by previous incidents such as the Nomad bridge hack, where white hats wanted to help but were constrained by legal uncertainty around whether accessing and returning funds could be construed as unauthorized computer access.

Safe Harbor’s promise is to clear that ambiguity. By embedding pre-authorization into protocol governance and specifying recovery addresses and bounty terms up front, it tries to give white hats and other responders a clear, rule-based path for intervention.

SEAL claims that Safe Harbor-based protections already extend to more than $16 billion in value across major protocols, including Uniswap, Pendle, PancakeSwap, Balancer, and zkSync.

Immunefi, a prominent bug bounty platform, has gone further by operationalizing Safe Harbor with stricter timing requirements. In Immunefi’s implementation, funds rescued under its Safe Harbor program must be transferred back to a protocol-controlled vault on its platform within six hours—a fourfold tightening compared with SEAL’s 72-hour baseline. Failing to meet this six-hour window is considered a material breach of the program’s terms.

It’s important to note what Safe Harbor does not do. It does not remove MEV builders from the loop. Instead, it attempts to formalize their role:

• If a builder front-runs an exploit against a Safe Harbor–adopting protocol, they are expected to recognize that the intervention is authorized and route funds to the designated recovery address within the SLA.
• The assumption is that builders will monitor Safe Harbor registries, respect those terms, and prioritize compliant routing even while maximizing profit elsewhere.

Whether that expectation holds in practice remains an open question. Builders are not directly bound by protocol governance in the way that white hats enrolling in Safe Harbor programs are, and the framework currently relies on a mix of norms, reputation, and legal pressure rather than fully automated enforcement at the block-building layer.

Best- and Worst-Case Futures for DeFi’s Rescue Layer

The effectiveness of any exploit response can be modeled simply as:

Expected user recovery = (probability of intervention) × (1 − bounty percentage) × (1 − failure/leak percentage)

Safe Harbor aims to improve the first two terms: it increases the probability that someone will intervene by reducing legal risk, and it caps bounty percentages in advance to prevent opportunistic gouging. That leaves execution risk—operational failures or leaks during the rescue—as the remaining source of uncertainty.

Across that formula, the next few years could break into three broad regimes:

Base case: wider Safe Harbor adoption. Over the next 12 months, more DeFi protocols add Safe Harbor clauses to their governance frameworks, and more white hats register as authorized responders. Legal clarity and preset bounties make intervention more attractive. For exploits that are visible to these responders and routed through cooperative builders, user recovery rates improve, especially for protocols that adopt tighter SLAs such as Immunefi’s six-hour requirement.

Bull case: a professionalized rescue layer. In a more optimistic trajectory, protocols go further and integrate Safe Harbor directly into their operational stack. They configure dedicated recovery vaults, compress SLAs into single-digit hours, and pre-negotiate bounty schedules with known white hat teams. Builders, in turn, integrate Safe Harbor registries into their transaction-ordering logic, automatically routing qualifying rescued funds to protocol-specified addresses without ad hoc decision-making. In this world, the “who decides who gets repaid” question becomes more rules-based and less dependent on individual builders’ discretion.

Bear case: hardened builder dependence. At the other end of the spectrum, relay and builder concentration deepen, private order flow expands, and Safe Harbor adoption lags. Exploit rescue becomes an opaque negotiation with a small number of powerful intermediaries who control order flow and custody. Protocols without pre-agreed frameworks find themselves bargaining after the fact with no defined SLA, no leverage, and uncertain jurisdictional recourse. In this regime, MEV builders are not just an emergency layer; they are effective gatekeepers for whether hacked users ever see their funds again.

The contrast between regimes can be summarized by how they answer a few key questions: Who is allowed to intervene? Where do rescued funds land? Is there an enforceable SLA? Are bounty terms predefined or improvised? And how transparent is accountability when something goes wrong?

Safe Harbor shifts those answers from “anyone who can win ordering, with funds stuck in builder-controlled custody and no SLA” toward “pre-authorized responders, protocol-designated recovery addresses, and time-boxed, rules-based terms.” Immunefi’s stricter six-hour implementation further compresses the window in which funds can sit in limbo, albeit with added operational pressure on responders.

What Builders and Protocols Should Watch Next

For DeFi traders, protocol teams, and security researchers, three metrics will signal where this landscape is heading:

• Adoption cadence. How quickly are protocols adding Safe Harbor-style frameworks to governance, and how many are registering with SEAL or similar registries? The breadth of adoption determines how often MEV-based rescues can be channelled into predictable outcomes rather than improvised ones.
• Operational SLAs. Are response windows tightening in practice? The gap between SEAL’s 72-hour baseline and Immunefi’s six-hour vault requirement suggests that turnaround time may become a competitive differentiator for security posture and user trust.
• Centralization pressure. Does MEV-Boost relay concentration remain high, or does it diversify? Do private order flow channels continue to grow, narrowing the set of actors who can even see potential rescue opportunities?

MEV bots and builders have already become crypto’s last line of defense in many exploit scenarios. Frameworks like Safe Harbor represent an attempt to turn an emergent, profit-driven rescue mechanism into something more predictable and accountable.

But that attempt ultimately depends on how builders behave, how quickly protocols adapt, and whether the underlying block-building pipeline remains concentrated in a few hands or opens up over time.

The Makina Finance exploit is a live example of what happens when those pieces are not fully aligned: the attacker failed, users avoided an outright loss—but their funds are now sitting in builder custody, with no clear, predefined path back to them.

For a sector built on the premise of trustless execution, that is an uncomfortable place to be.