Today, MEV builders have settled on a standardized system for routing
bundles, blocks, and proposer payments that we call MEV-Boost.
MEV Boost
Relays have the job of evaluating how much money a proposer will earn
from a block, which is measured simply by the balance delta of the
proposer's address.
In early July, I was flipping through Etherscan as per usual, looking
for interesting things, when I took a closer look at these
builder-to-proposer payments, which are typically the last transaction
in each MEV-Boost block.
What I noticed was that these payments were completely ordinary ETH
transfers, using 21,000 gas, which made me curious about a replay
attack. If the block was published and subsequently forked out, the
payment could be included in the next block, and the builder would lose
a small amount of money.
Interestingly, I also noticed that sponsored bundles were vulnerable
to this attack. However, I could not conceive of a way it would be
exploitable, aside from blindly including them in every block in the
hope that one would be forked out.
Checking the forked block page on Etherscan, I could see, as
expected, that forked blocks were occurring 6 to 12 times a day. I
started scraping data and saw that major builders were vulnerable to
this a few times a day. However, the potential losses incurred were very
small (typically $100–200/day).
I found this mildly interesting, but not a major problem, so I
messaged a few block builders about it to double-check that they knew
about it.
As expected, every block builder I talked to said the same thing:
they knew, but just hadn't really cared to fix it, which was extremely
fair.
The Relay Reckoning
So, for the next month, I didn't really think much of this issue
until I happened to be looking at Titan's MEV-Boost relay
implementation, Helix. I saw this
line:
This immediately set off alarm bells in my head.
What this line meant was that the proposer of a slot could wait until
precisely t=4 in the broadcast window before the relay would no longer
be willing to publish the block.
However, if a block is received by beacon nodes past t=4, they will
refuse to accept it and instead attest to the previous head of the
chain. So, waiting until the last moment to sign gave the proposer the
opportunity to essentially guarantee that the MEV-Boost block would be
forked out.
Forced Forking
The attack I immediately came up with made use of sponsored bundles,
a feature of both the Titan
and Quasar
builders. Simply include many high-value transactions that would be
topped up by the builder, up to the limit of their coinbase balance,
perform the forced-forking attack, and collect the value of the
sponsored bundles by including their transactions in the next block.
This could easily be achieved in the next block by bribing for their
inclusion with a bundle, or simply bidding to become the builder for the
next slot.
Escalation
Seeing the danger of this, I immediately contacted Titan and Quasar
Builder to inform them of the attack. However, the vulnerable amount was
quite low. Both builders typically kept only 10–20 ETH in their coinbase
to limit the danger of attacks such as these. However, I was about to
discover a new variant of the attack that was far more dangerous.
The same attack could apply to proposer payments. However, there was
no easy way to bait a high proposer payment as there was with sponsored
bundles – or so I thought. I wondered if there was an easy way to spike
the value of a block and, more importantly, tune it to the precise value
of a builder's coinbase in order to target a specific builder and drain
it effectively.
The attack I came up with involved acting as three entities
simultaneously, working together to boost the value of the block and
target a specific builder.
Builders retain an internal view of how much the block is worth to
them, how much they are willing to bid up to that limit, and the other
top bids published by the top relays, allowing them to respond to
competition within the slot. If the true value of a block was 100 ETH,
the bid value of the block might not climb to that true value by the
time the proposer signed off on the block. Instead, builders prefer to
incrementally bid over one another, as this is generally a more
profitable strategy.
To hike a builder's bid for the block, we do two simple things: send
a bundle to the builder that transfers 100 ETH to their address,
instantly raising the true value of the block in their view, and send a
block to the relays they observe that transfers a large amount of money
to the proposer (who is us for this slot). The builder would then
automatically bid above this value. By adjusting which builder you send
the bundle to and the value of the bundle, you can precisely tune the
builder's bid to be just under their balance, draining the entire
amount.
Moreover, the downside risk for the proposer is extremely low, as the
maximum bound of their losses is the gap between whatever the builder
bids and the bait payment to the builder. If the block gets
canonicalized, their loss in the above diagram would be
100 - 99.5 = 0.5 ETH, versus the 100 ETH they
stand to gain. To defend against the risk of their own bribe payment to
the builder being included in another block, the proposer simply codes
the transaction such that it reverts if executed in the wrong slot. If
another builder never outbids them, they simply revert to local building
or pick a block from another relay.
Bid Adjustment
After escalating this issue to Flashbots and SEAL 911 as well,
c0ffeebabe came up with an attack that extended it to the ultrasound.money relay by
abusing the bid
adjustment feature, which I didn't know existed.
The ultrasound.money relay will, if it detects that a builder has
overbid, adjust the bid down to be just above the competition's value
and take a cut of the difference in exchange for facilitating this
process. In order to allow the relay to overwrite the bid, builders keep
large balances deposited with ultrasound.money. Using a slightly
modified version of the attack, we can bait the ultrasound.money relay
into performing bid adjustment, making these balances vulnerable as
well.
Simply provide an extra, lower block bid to another relay that
ultrasound.money monitors, baiting the relay into performing bid
adjustment. As usual, these amounts can be finely tuned to drain
specific account balances.
Scaring the Searchers
At this point, the total amount vulnerable across builders and
ultrasound.money relay accounts was close to $1,000,000 USD. In
practice, it would be difficult to steal this full amount, given that
you can only drain one account per proposer slot. Unless you had many
slots in fairly quick succession, builders and relays would shut down
operations before you could attack again. On the day of reporting, both
Beaverbuild and Buildernet each had >100 ETH in their coinbase, which
would have made them the first and most obvious targets.
After reporting, I came up with a highly theoretical attack against
searchers using this forced-forking method. It requires two sequential
proposer slots to profit from, but only one to execute and cause losses
for searchers. Many searchers use priority gas as a method of paying the
builder, as it is efficient and built in—no extra cost. However, this
means they could still be paying a pretty penny for transactions that
revert. The guarantee of a bundle and a builder, however, is that no
transactions will revert (unless the searcher allows it).
The attack, then, is fairly simple: create bait transactions coded to
target specific searchers who pay using priority gas. The bait
transactions would be very high value, causing a very high priority gas
fee. Then, fork out the block and include the published but reverting
transactions in the next block. If you happen to be the proposer for
that next block, you can collect these fees yourself; otherwise, they
would likely go to whoever the proposer is.
The total amount vulnerable in the searcher space here is hard to
estimate. There are many complexities and many MEV bots; it could be
anywhere from a few hundred thousand to a few million dollars, though I
believe it would be difficult to steal more than a few hundred thousand
with this extremely theoretical method.
Mitigation
The fixes were always fairly clear. c0ffeebabe wrote a contract using
raw bytecode, now deployed at 0xFEEEEEE44046c3f61a8CC081E0918eF0de0a7ffC,
which simply forwards whatever value is passed into it to the specified
destination address and reverts if it is not executed in the correct
slot, as determined by checking the timestamp. This is now used for both
proposer payments and sponsored bundles.
If you want to discuss MEV, security, privacy, cryptography, or
general blockchain engineering, please reach out via the channels on
this site. I'm always on the lookout for opportunities, both contracts
and roles, so if it sounds like I could help with your project, let me
know.
Proposer Boost: A million dollar MEV bug
2026 Aug 30 See all postsThanks to Flashbots, Titan Builder, Quasar Builder, Ultrasound.money, and c0ffeebabe of the Security Alliance for their help in getting this issue patched and for the bounties awarded.
MEV Boost and Payments
Today, MEV builders have settled on a standardized system for routing bundles, blocks, and proposer payments that we call MEV-Boost.
Relays have the job of evaluating how much money a proposer will earn from a block, which is measured simply by the balance delta of the proposer's address.
In early July, I was flipping through Etherscan as per usual, looking for interesting things, when I took a closer look at these builder-to-proposer payments, which are typically the last transaction in each MEV-Boost block.
What I noticed was that these payments were completely ordinary ETH transfers, using 21,000 gas, which made me curious about a replay attack. If the block was published and subsequently forked out, the payment could be included in the next block, and the builder would lose a small amount of money.
Interestingly, I also noticed that sponsored bundles were vulnerable to this attack. However, I could not conceive of a way it would be exploitable, aside from blindly including them in every block in the hope that one would be forked out.
Checking the forked block page on Etherscan, I could see, as expected, that forked blocks were occurring 6 to 12 times a day. I started scraping data and saw that major builders were vulnerable to this a few times a day. However, the potential losses incurred were very small (typically $100–200/day).
I found this mildly interesting, but not a major problem, so I messaged a few block builders about it to double-check that they knew about it.
As expected, every block builder I talked to said the same thing: they knew, but just hadn't really cared to fix it, which was extremely fair.
The Relay Reckoning
So, for the next month, I didn't really think much of this issue until I happened to be looking at Titan's MEV-Boost relay implementation, Helix. I saw this line:
This immediately set off alarm bells in my head.
What this line meant was that the proposer of a slot could wait until precisely t=4 in the broadcast window before the relay would no longer be willing to publish the block.
However, if a block is received by beacon nodes past t=4, they will refuse to accept it and instead attest to the previous head of the chain. So, waiting until the last moment to sign gave the proposer the opportunity to essentially guarantee that the MEV-Boost block would be forked out.
The attack I immediately came up with made use of sponsored bundles, a feature of both the Titan and Quasar builders. Simply include many high-value transactions that would be topped up by the builder, up to the limit of their coinbase balance, perform the forced-forking attack, and collect the value of the sponsored bundles by including their transactions in the next block. This could easily be achieved in the next block by bribing for their inclusion with a bundle, or simply bidding to become the builder for the next slot.
Escalation
Seeing the danger of this, I immediately contacted Titan and Quasar Builder to inform them of the attack. However, the vulnerable amount was quite low. Both builders typically kept only 10–20 ETH in their coinbase to limit the danger of attacks such as these. However, I was about to discover a new variant of the attack that was far more dangerous.
The same attack could apply to proposer payments. However, there was no easy way to bait a high proposer payment as there was with sponsored bundles – or so I thought. I wondered if there was an easy way to spike the value of a block and, more importantly, tune it to the precise value of a builder's coinbase in order to target a specific builder and drain it effectively.
The attack I came up with involved acting as three entities simultaneously, working together to boost the value of the block and target a specific builder.
Builders retain an internal view of how much the block is worth to them, how much they are willing to bid up to that limit, and the other top bids published by the top relays, allowing them to respond to competition within the slot. If the true value of a block was 100 ETH, the bid value of the block might not climb to that true value by the time the proposer signed off on the block. Instead, builders prefer to incrementally bid over one another, as this is generally a more profitable strategy.
To hike a builder's bid for the block, we do two simple things: send a bundle to the builder that transfers 100 ETH to their address, instantly raising the true value of the block in their view, and send a block to the relays they observe that transfers a large amount of money to the proposer (who is us for this slot). The builder would then automatically bid above this value. By adjusting which builder you send the bundle to and the value of the bundle, you can precisely tune the builder's bid to be just under their balance, draining the entire amount.
Moreover, the downside risk for the proposer is extremely low, as the maximum bound of their losses is the gap between whatever the builder bids and the bait payment to the builder. If the block gets canonicalized, their loss in the above diagram would be
100 - 99.5 = 0.5 ETH, versus the100 ETHthey stand to gain. To defend against the risk of their own bribe payment to the builder being included in another block, the proposer simply codes the transaction such that it reverts if executed in the wrong slot. If another builder never outbids them, they simply revert to local building or pick a block from another relay.Bid Adjustment
After escalating this issue to Flashbots and SEAL 911 as well, c0ffeebabe came up with an attack that extended it to the ultrasound.money relay by abusing the bid adjustment feature, which I didn't know existed.
The ultrasound.money relay will, if it detects that a builder has overbid, adjust the bid down to be just above the competition's value and take a cut of the difference in exchange for facilitating this process. In order to allow the relay to overwrite the bid, builders keep large balances deposited with ultrasound.money. Using a slightly modified version of the attack, we can bait the ultrasound.money relay into performing bid adjustment, making these balances vulnerable as well.
Simply provide an extra, lower block bid to another relay that ultrasound.money monitors, baiting the relay into performing bid adjustment. As usual, these amounts can be finely tuned to drain specific account balances.
Scaring the Searchers
At this point, the total amount vulnerable across builders and ultrasound.money relay accounts was close to $1,000,000 USD. In practice, it would be difficult to steal this full amount, given that you can only drain one account per proposer slot. Unless you had many slots in fairly quick succession, builders and relays would shut down operations before you could attack again. On the day of reporting, both Beaverbuild and Buildernet each had >100 ETH in their coinbase, which would have made them the first and most obvious targets.
After reporting, I came up with a highly theoretical attack against searchers using this forced-forking method. It requires two sequential proposer slots to profit from, but only one to execute and cause losses for searchers. Many searchers use priority gas as a method of paying the builder, as it is efficient and built in—no extra cost. However, this means they could still be paying a pretty penny for transactions that revert. The guarantee of a bundle and a builder, however, is that no transactions will revert (unless the searcher allows it).
The attack, then, is fairly simple: create bait transactions coded to target specific searchers who pay using priority gas. The bait transactions would be very high value, causing a very high priority gas fee. Then, fork out the block and include the published but reverting transactions in the next block. If you happen to be the proposer for that next block, you can collect these fees yourself; otherwise, they would likely go to whoever the proposer is.
The total amount vulnerable in the searcher space here is hard to estimate. There are many complexities and many MEV bots; it could be anywhere from a few hundred thousand to a few million dollars, though I believe it would be difficult to steal more than a few hundred thousand with this extremely theoretical method.
Mitigation
The fixes were always fairly clear. c0ffeebabe wrote a contract using raw bytecode, now deployed at
0xFEEEEEE44046c3f61a8CC081E0918eF0de0a7ffC, which simply forwards whatever value is passed into it to the specified destination address and reverts if it is not executed in the correct slot, as determined by checking the timestamp. This is now used for both proposer payments and sponsored bundles.Additionally, the Helix relay adjusted its cutoff time for getPayloadV1 to 3200ms.
During the vulnerable period, BuilderNet and BeaverBuild also reduced the amount held in their coinbases.
Bounties
For my findings, I was awarded a total of 3.5 ETH:
Quasar Builder: 1 ETH
Titan Builder: 1 ETH
Buildernet: 0.5 ETH
Ultrasound.money: 1 ETH
Fin
If you want to discuss MEV, security, privacy, cryptography, or general blockchain engineering, please reach out via the channels on this site. I'm always on the lookout for opportunities, both contracts and roles, so if it sounds like I could help with your project, let me know.