Skip to main content

Refunds

BuilderNet uses a refund mechanism to share the value it creates with the parties who contribute to its blocks. The goal of this mechanism is to create an efficient, transparent way for orderflow providers to internalize their MEV, and to sustain the ongoing operations of the network.

For orderflow providers​

Users, wallets, apps, and searchers who submit transactions or bundles to BuilderNet will receive refunds for the value their orderflow adds to its blocks. Today all refunds are calculated according to a standard open source rule. The full definition of the current rule can be found here.

At a high level:

  • BuilderNet competes in the MEV-Boost auction to land a block.
  • If BuilderNet's block is more valuable than others, it may bid less than the true value of its block. It retains the remainder to refund users.
  • For each transaction in that block, BuilderNet simulates the most valuable block it could have produced with vs without the transaction. The difference is the transaction's contribution.
  • The remainder is split proportionally among users, based on their relative contribution to the block.

Transactions and bundles sent to Flashbots Protect, Flashbots Bundle Relay, or directly to a BuilderNet node will automatically receive refunds. Public mempool transactions do not receive refunds.

For operators​

In the future, the refund rule will be upgraded to compensate operators for their computation costs.

For validators​

Block builders rarely bid the full value of their blocks to validators in the MEV-Boost auction today. The remainder is either internalized by the builder or refunded to orderflow providers off-chain. The immediate goal of BuilderNet is to create a transparent and permissionless alternative to these off-chain agreements so that all parties -- orderflow providers, builders, and validators -- have equal access and visibility into how value is distributed.

We do not expect this to substantially impact outcomes for validators in the short term, given that similar behaviors are standard practice in the market today.

In the long term, there are a few differences between BuilderNet and the current market:

  • If BuilderNet is widely adopted, non-contentious transactions (e.g. simple transfers) will no longer compete for inclusion, reducing one form of MEV that is currently paid to validators
  • On the other hand, in this scenario BuilderNet will likely (1) lower the friction to transact and (2) generate more emergent value between transactions, increasing the overall MEV that can be shared by validators, users, and operators

We intend to monitor these dynamics and upgrade BuilderNet's approach to redistribution and bidding so that it remains maximally transparent, inclusive, and incentive compatible for all parties. We invite staking teams and validators contribute to this research and share their thoughts on the forum.

Data​

Refund data is available in the BuilderNet dashboard, Flashbots Protect dashboard, and through Flashbots APIs.

Refund wallet​

Refund transactions are sent from address 0x62A29205f7Ff00F4233d9779c210150787638E7f (ENS: refunds.buildernet.eth).