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 privately to BuilderNet will receive refunds for the value their orderflow adds to its blocks. The goal of the refund rule is to minimize the amount that each transaction or bundle pays to land onchain. 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 and retain the remainder to refund users.
• For each transaction in the landed block, BuilderNet retroactively 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.

The full refund rule is defined below and implemented in rbuilder. For further details about how to bid and interact with the refund rule, read the explainer.

Note that transactions seen in the public mempool, or bundles only containing transactions from the public mempool, do not receive refunds. Bundles sent by the same signer will be treated as non-competitive.

The Flat Tax Rule

• $B(T)$ is the most profitable block produced from bundles in $T$.
• $v(T)$ is the value of $B(T)$.
• $b_i(T)$ is the payment of all bundles sent by identity $i$ if block $B(T)$ is realized.
• $\mu_i(T) = \min\{b_i(T), v(T) - v(T \setminus \{i\})\}$ is the marginal contribution of all bundles sent by identity $i$ if $B(T)$ is realized. We bound the marginal contribution so that the net payment can't be negative.
• $c$ is the amount the builder pays to the proposer to win the block.

$$\phi_i(T, c) = \frac{\mu_i(T)}{\sum_j \mu_j(T)} \min\{v(B(T)) - c, \sum_j \mu_j(T)\}$$

So the net payment per identity (assuming it's included) is $p_i(T) = b_i(B(T)) - \phi_i(T, c)$.

Notice that if the block generates enough value after paying the proposer, everyone should be refunded their contribution, meaning everyone pays the minimum they need to pay to beat competition.

Identity constraint

To avoid the rule being gamed by submitting bundles from multiple identities, we impose an additional constraint that no set of identities can receive in total more refunds than they contribute to the block.

For each set of identities $I$ we define

$$\mu_I(T) = \min\{\sum_{i\in I} b_i(T), v(T) - v(T \setminus I)\},$$

to be the joint marginal contribution of the identities in $I$ to the block. Then we choose rebates that are minimally different from the flat-tax rule subject to the constraint that they don't rebate a set of bundles more in total than its joint marginal contribution. This means the vector of rebates $\psi(T, c)$ solves

$$\min_{r\in\mathbb{R}^n_+} \sum_i (r_i - \phi_i(T, c))^2$$ $$\text{subject to} \sum_{i\in I} r_i \leq \mu_I(T) \text{ for each } I \subseteq B(T),$$ $$\sum_i r_i \leq v(T) - c$$

where $\phi(T, c)$ are the orginal flat-tax rebates as defined above.

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).