We’re trialing a new BuilderNet feature that orderflow providers (e.g. wallets, RPCs, orderflow auctions) can use to monetize their priority fees.
Today many block builders offer features that let orderflow providers capture a fixed percent of their priority fees via out-of-band payments. We’re exploring how to the meet market demand for this feature in the most robust and transparent way possible — starting with a modified version that does not rely on out-of-band payments.
Long term changes to BuilderNet refunds deserve thorough review, so the intent of this post to clarify the state of the market and kick off a dialog about how to move forward. Input welcome.
How fixed priority fee rebates work today
Top builders, including BuilderNet, support the refundRecipient and refundPercent fields in eth_sendBundle which deducts and refunds a percentage of a transaction’s priority fee before considering the bundle for inclusion and standard refunds.
Builders initially implemented these fields in 2023 to support orderflow auctions (e.g. MEVBlocker, MEV-Share) that allowed searchers to return backrun value to users. The refundPercent field specified the percentage of the searcher’s priority fee that should be returned to the user or orderflow provider. Starting in 2024, orderflow landing services (e.g. Blink, Merkle) began using these fields in a different way to help orderflow providers retain priority fees on user transactions as well. The refundPercent field specified the percentage of the user’s priority fee that should be returned to the orderflow provider.
Unlike backrun transactions with large priority fees, vanilla user transactions typically have low priority fees that may not cover the cost of the base fee for the refund transaction. To increase efficiency, these services required connected builders to delay the refund transactions and aggregate them into a single monthly out-of-band payment for the combined value (rather than paying each refund in the same block).
For example:
- Suppose a user pays a 10 ETH priority fee to land their transaction onchain, and their wallet uses an orderflow landing service which specifies
refundPercent= 60% - Block builders will treat the transaction as though it paid 4 ETH in priority fees, retaining 6 ETH to refund to the orderflow landing service
- Once a month, the block builder will send an out-of-band payment to the orderflow landing service for all refunds accrued during that period (including the 6 ETH)
Combined refunds trial
Recently, we’ve been trialing efficiency improvements for refundPercent bundles: orderflow providers who specify these parameters receive a single “combined refund” at the end of the block that pays for all exclusive transactions for a given refundRecipient, rather than after every transaction.
Here is the current logic:
- Orderflow providers submit an
eth_sendBundlerequest with therefundPercentandrefundRecipientfields specified - BuilderNet discounts each transaction’s priority fee by the specified
refundPercentbefore merging them into a block, and transfers the withheld fees to the specifiedrefundRecipientaddress - For each block, all refunds owed to the same
refundRecipientare combined into a single immediate refund transaction (amortizing the transfer costs) - Note: Combined refunds are only issued if at least one transaction’s net priority fees (after the
refundPercentdeduction) for therefundRecipientcover the refund transaction’s transfer cost
One key difference is that BuilderNet executes the combined refunds atomically in the same block they’re earned, rather than disbursing them out-of-band each month. This allows any orderflow provider to permissionlessly receive fees (no off-chain agreement required), and creates an on-chain audit trail. The disadvantage is that more frequent on-chain transfers increase costs for providers, especially if there are very few transactions in a block to amortize the transfer fee across or the L1 base fee is very high.
We’re exploring how to further leverage BuilderNet’s existing refund payment pipeline to disburse payments over configurable time periods while maintaining attribution and transparency.
Considerations
Discounted transactions may have lower block positions or take longer to land on-chain. Orderflow providers requiring fast inclusion should use lower refundPercent values or leverage BuilderNet’s native refund rule to maximize inclusion while receiving pro rata refunds.
Request for input
We’d love your feedback! Comment here or join the conversation in Telegram.