First 10,000 blocks and new features

After an end of PoW on Ethereum some team members of our mining pool decided to pivot into relatively “new” area of block building. This lead to creation of builder0x69 and it started rapidly gaining popularity among searchers. We’ve just crossed first 10,000 slots won as block builder so wanted to clarify our stance and announce new features.

We want to make a builder which is advanced and listens to needs of our searchers yet is permission-less and reliable at the same time. But it’s equally important for us that our builder doesn’t make bad situation worse and preserves neutral nature of Ethereum.
Currently we’ve settled on following trade-offs:
1) Our builder will produce full blocks for relays which are permission-less, neutral towards transaction inclusion and fully open-sourced. We won’t take any fees in blocks produced for such relays.
2) We will create our own neutral relay(and open-source it of course) or donate towards infra costs for operating a reliable open/community run relay if someone else creates it.
3) Our blocks produced for any other relays which aren’t completely neutral towards transaction inclusion might contain a small builder’s fee.

This should create a financial incentive for validators to connect to open/neutral relay since at least our own blocks would not contain any fees on top of potentially having additional transactions.

Announcing new features

Our DMs are always open to all searchers and we’re happy to develop custom features. But part of the deal is that after such features are finished they’ll be available equally to be used by all searchers.
We recently developed a feature that multiple searchers have asked for
and want to present it publicly for everyone to use.

Updatable bundles

An updatable bundle is the same as a normal bundle in all aspects, except that you pass an additional uuid field inside to uniquely identify it (next to existing fields like blockNumber and maxTimestamp).
This field can be any arbitrary string, but don’t make it too simple since anyone can override bundle if they know its uuid.

Now, if you send a new bundle with the same value for the uuid field, it will replace the previous one in our builder memory. It means you can cancel a bundle entirely if you send us a bundle with empty list of transactions but the same uuid as the bundle you want to discard.

This is a best-effort solution: when we update/discard a bundle we try to make sure that the our subsequently sealed blocks will contain only the latest version of this bundle, but it’s still entirely possible that some old block that we’ve previously built will end up being proposed by validator.
Guarantees around bundle updates should improve significantly once relays implement: https://github.com/flashbots/mev-boost-relay/issues/51

In next posts we’ll also cover more features which are currently under development.