Highlights​

• FlowProxy — Our new orderflow ingress and multiplexing system, completely rewritten in Rust. Faster, more reliable handling of incoming transactions and bundles.

• Fusaka-ready — Full support for the upcoming hardfork, including proper handling of system transactions. Required for mainnet compatibility when Fusaka activates.

• Optimistic v3 — New optimistic submission types for lower latency block submissions, helping you stay competitive in the bidding race.

• Simplified stack — The rbuilder-operator repository has been merged into rbuilder. One less component to deploy and maintain.

• Rebalancer service — Automates ETH movement between addresses, simplifying treasury management.

• Delay refunds (out of block payment) - Support for payments outside the main block.

• Performance improvements — Faster proof generation, improved bidding latency, and more efficient transaction ordering.

• DNS caching with DNSMASQ — Reduces latency and improves resilience by caching DNS lookups locally.

• Clickhouse on-disk backups — Buffers data locally to prevent loss during network issues or Clickhouse downtime.

Versions​

The build toolchain for BuilderNet v1.6 is based on yocto-manifests v1.6.0 (commit 68962ce):

Updated services​

Not updated services​

Changes & Pull Requests​

Services Configuration​

Artifacts​

Signed artifacts are stored at https://downloads.buildernet.org/buildernet-images/.

The specific TDX VM image for the BuilderNet v1.6 release is located at /v1.6.0/buildernet-1.6.0-azure-tdx.wic.vhd

Measurements​

These are the new live measurements for BuilderNet v1.6:

{
    "measurement_id": "buildernet-v1.6.0-azure-tdx.wic.vhd",
    "attestation_type": "azure-tdx",
    "measurements": {
        "4": {
            "expected": "bd5c5c469a57fdeae9a88ca8ef6682248f7aec1ba68173b6c09236d8dffbd8ae"
        },
        "9": {
            "expected": "b6d80052b6d6b655677ab464ef6485b47c139c4f2056665969b105398ae191c6"
        },
        "11": {
            "expected": "65711301762c58bbca51cfadd9b3b18cf662e5f38882a7150217fec4d7564663"
        }
    }
}

Reproducible Builds​

BuilderNet v1.6 supports fully reproducible TDX image builds. The image you build will produce the exact same TDX measurements as our reference builds.

The main entry point for the image builds is the flashbots/yocto-manifests repository, and for this release specifically the yocto-manifests v1.6.0 (commit 68962ce).

To reproducibly build it, clone the repository, check out the tag and build it with Docker/Podman:

git clone https://github.com/flashbots/yocto-manifests.git
cd yocto-manifests
git checkout v1.6.0
make image-buildernet

You can confirm that the hash of your build matches the expected one:

make measurements-buildernet

Build host specs:

• Ubuntu 22.04 x64 (Linux kernel 6.8.0-49-generic), fully updated system
• Intel Xeon Gold 6312U, 48vCPUs, 512GB memory

Join the conversation on the BuilderNet forum and the BuilderNet Telegram group!

Changelog​

• Even faster root hash
• EVM caching
• Reth upgrade, fixing possible root-hash issue
• Trusted TLS certificates (using Let’s Encrypt, TLS termination now by HAProxy) to enhance the security and experience for sending orderflow to BuilderNet and lay the groundwork for a geographically distributed orderflow ingress
• Subsidy auto-update to allow adjusting subsidies without manual intervention
• /readyz and /livez health check endpoints for better monitoring and automatic routing
• Detection of coinbase fund transfer to avoid side-effects on subsidy calculation when coinbase funds are moved to the BuilderNet multisig
• Discard mempool transactions when calculating profit
• Orderflow-proxy bugfixes and performance improvements

Versions​

The build toolchain for BuilderNet v1.5 is based on yocto-manifests@v1.5.0 (commit d056865f34e0c52ceb9e0f524ea555db40a2762f):

Updated services​

Not updated services​

Changes & Pull Requests​

Services Configuration​

Artifacts​

Signed artifacts are stored at https://downloads.buildernet.org/buildernet-images/.

The specific TDX VM image for the BuilderNet v1.5 release is buildernet-v1.5.0-azure-tdx.wic.vhd

Measurements​

These are the new live measurements for BuilderNet v1.5:

{
    "measurement_id": "buildernet-v1.5.0-azure-tdx.wic.vhd",
    "attestation_type": "azure-tdx",
    "measurements": {
        "4": {
            "expected": "cd9ade37fcd214d091c632ac558e58127adcf387e6b2ef7b093d87f3fbbd2182"
        },
        "9": {
            "expected": "5fa70d4bc380f0dbcb5b475b14cf1a06a6042db0fe915317537ca22533ac9cff"
        },
        "11": {
            "expected": "3408ca2a82fba046cdc00055a1f53475a7ebc5650cbb4b5e0fdb7c7e0d8e3818"
        }
    }
}

Reproducible Builds​

BuilderNet v1.5 supports fully reproducible TDX image builds. The image you build will produce the exact same TDX measurements as our reference builds.

The main entry point for the image builds is the flashbots/yocto-manifests repository, and for this release specifically the yocto-manifests@v1.5.0 (commit d056865f34e0c52ceb9e0f524ea555db40a2762f).

To reproducibly build it, clone the repository, check out the tag and build it with Docker/Podman:

git clone https://github.com/flashbots/yocto-manifests.git
cd yocto-manifests
git checkout v1.5.0
make image-buildernet

You can confirm that the hash of your build matches the expected one:

make measurements-buildernet

Build host specs:

• Ubuntu 22.04 x64 (Linux kernel 6.8.0-49-generic), fully updated system
• Intel Xeon Gold 6312U, 48vCPUs, 512GB memory

Join the conversation on the BuilderNet forum and the BuilderNet Telegram group!

One notable improvement is that TLS certificates for BuilderNet nodes are now persistent, where previously they were rotated on each service restart. This change is part of the ongoing effort to improve the user experience and security of the network.

Versions​

The build toolchain for BuilderNet v1.4 is based on yocto-manifests@v1.4.0 (commit 170d166):

Updated services​

Not updated services​

Changes & Pull Requests​

Services Configuration​

Artifacts​

Signed artifacts are stored at https://downloads.buildernet.org/buildernet-images/.

The specific TDX VM image for the BuilderNet v1.4 release is buildernet-v1.4.0-azure-tdx-5344f8aff0ed6753015d8ac6d157a7f8485aa22de4201cb233805ab9af3f37c7

Measurements​

These are the new live measurements for BuilderNet v1.4:

{
    "measurement_id": "buildernet-v1.4.0-azure-tdx-5344f8aff0ed6753015d8ac6d157a7f8485aa22de4201cb233805ab9af3f37c7.wic.vhd",
    "attestation_type": "azure-tdx",
    "measurements": {
        "4": {
            "expected": "4b73de8d71d6342ae3cfb5ce4e5601ec7e9dc49127a76916c8f0b4a8463b5d14"
        },
        "9": {
            "expected": "aeb9899553dba20e05cb5673930d609c2ce6e0ceb920e1a01baf21a155a2df04"
        },
        "11": {
            "expected": "7585ce8ec39ed48f7db95ee435870010ec8151b2ab3716cb9876e976a75cb31a"
        }
    }
}

Reproducible Builds​

BuilderNet v1.4 supports fully reproducible TDX image builds. The image you build will produce the exact same TDX measurements as our reference builds.

The main entry point for the image builds is the flashbots/yocto-manifests repository, and for this release specifically the yocto-manifests@v1.4.0 (commit 170d166).

To reproducibly build it, clone the repository, check out the tag and build it with Docker/Podman:

git clone https://github.com/flashbots/yocto-manifests.git
cd yocto-manifests
git checkout v1.4.0
make image-buildernet

You can confirm that the hash of your build matches the expected one:

make measurements-buildernet

Build host specs:

• Ubuntu 22.04 x64 (Linux kernel 6.8.0-49-generic), fully updated system
• Intel Xeon Gold 6312U, 48vCPUs, 512GB memory

Join the conversation on the BuilderNet forum and the BuilderNet Telegram group!

Beaverbuild has operated the largest block builder by market share on Ethereum since 2022. Starting today, Beaverbuild will onboard their users to BuilderNet and work closely with Flashbots to accelerate its roadmap as a development partner.

Together we will:

1. Make transactions cheaper and more private for everyone on Ethereum
2. Develop an HFT-grade TEE sequencing stack to scale the L1 & L2s
3. Remove the remaining centralized dependencies in PBS

Join us in creating a new MEV supply chain that anyone can verify, not trust.

Read more from the Beaverbuild team here.

Improvements​

Upgraded eth_sendBundle API​

BuilderNet v1.3 provides an upgraded eth_sendBundle API, which includes new fields for backrun OFAs that are widely supported by other block builders. This allows backrun OFAs to submit directly to BuilderNet with better performance and customization. Specifically, these new (optional) fields were added:

BuilderNet now also supports bundle cancellations with eth_sendBundle. To cancel a bundle, send a new eth_sendBundle request with the same replacementUuid and an empty list of transactions. This matches the standard behavior supported by Beaverbuild and Titan.

Improved cancellations​

In addition to these API-level changes, BuilderNet v1.3 also makes several upgrades to the performance and reliability of bundle cancellations. To ensure cancellations are correctly processed, v1.3 adds support for block level cancellations on MEV-Boost relays and continues bidding even when the block value decreases. To reduce the latency for processing cancellations, BuilderNet nodes now submit only to regional relays (shaving off an estimated ~50ms in network latency). We have also introduced a time limit to prevent slower bundle merging strategies from arbitrarily delaying cancellations, and an initial set of spam prevention techniques to reduce the load on the builder. The latter drove a 2x decrease in p99 e2e latency.

Together we expect these changes will make BuilderNet a much better venue for users that require fast updates to their bundles.

Additional end-to-end latency metrics​

rbuilder now includes additional e2e latency Prometheus metrics.

Here’s an screenshot of p99 e2e latency over a couple of days:

Prometheus metrics can be sent to multiple endpoints​

The v1.3 release supports multi-endpoint support for Prometheus metrics, allowing builder nodes to send monitoring data to multiple destinations simultaneously.

rbuilder on/off switch to simplify deployments​

The rbuilder on/off switch feature introduces a new configuration option that allows operators to safely control the builder's participation in block building. This switch can be toggled without requiring a full restart, making it particularly useful during maintenance windows, upgrades, or when troubleshooting issues.

When turned off, the rbuilder gracefully stops accepting new bundles and participating in block building, while maintaining its connection to the network. This enables smooth transitions during deployments and provides an additional safety mechanism for operators.

Configurable merging algorithms​

This release enables the dynamic configuration of merging algorithms, instead of requiring a new BuilderNet version release to change them.

Local devnet environment support​

BuilderNet release images are now capable of running in a local devnet mode. This allows developers to test and develop locally without needing to deploy on the main BuilderNet network. Specifially noteworthy improvements include:

• BuilderNet playground codebase which integrates BuilderNet images with Builder Playground (this is an alpha state and work-in-progress)
• TDX VM images in qcow2 format, which can be used to run locally in QEMU.
• Configurable BuilderHub URL for image builds.

The local devnet is based on this Builder Playground PR: https://github.com/flashbots/builder-playground/pull/101

We are actively working on the local devnet and expect to have more news around this soon.

Versions​

The reproducible build toolchain for BuilderNet v1.3 is based on yocto-manifests@v1.3.0 (commit 05638f3).

Changes & Pull Requests​

Services Configuration​

Artifacts​

Signed artifacts are stored at https://downloads.buildernet.org/buildernet-images/.

The specific TDX VM image for the BuilderNet v1.3 release is buildernet-v1.3.0-azure-tdx-d17a02695c1acc0800aff80e86efbe0e5919843184e6562d8d572894ab43d149

Measurements​

These are the new live measurements for BuilderNet v1.3.0:

{
    "measurement_id": "buildernet-v1.3.0-azure-tdx-d17a02695c1acc0800aff80e86efbe0e5919843184e6562d8d572894ab43d149.wic.vhd",
    "attestation_type": "azure-tdx",
    "measurements": {
        "4": {
            "expected": "966f0aa4b6f6952e601712cfe78f71a6ae61467a425a92d0800c754e98933d78"
        },
        "9": {
            "expected": "af03ec5b7f02f5b9779f04bc837b8cbbf85d5b0386d5f387d8b99e8f0d9a1fa4"
        },
        "11": {
            "expected": "3aede0e78b33f4197175b73468be54f168a46719c063b7c4f27c10984e614b38"
        }
    }
}

Reproducible Builds​

BuilderNet v1.3 supports fully reproducible TDX image builds. The image you build will produce the exact same TDX measurements as our reference builds.

The main entry point for the image builds is the flashbots/yocto-manifests repository, and for this release specifically the yocto-manifests@v1.3.0 (commit 05638f3).

To reproducibly build it, clone the repository, check out the tag and build it with Docker/Podman:

git clone https://github.com/flashbots/yocto-manifests.git
cd yocto-manifests
git checkout v1.3.0
make image-buildernet

You can confirm that the hash of your build matches the expected one:

make measurements-buildernet

Build host specs:

• Ubuntu 22.04 x64 (Linux kernel 6.8.0-49-generic), fully updated system
• Intel Xeon Gold 6312U, 48vCPUs, 512GB memory

Join the conversation on the BuilderNet forum and the BuilderNet Telegram group!

This release introduces fully automatic node bootstrapping, improved system management capabilities and authentication, and lays the groundwork for a more flexible, container-based architecture.

BuilderNet v1.2 represents an important step towards our goal of performant, decentralized and permissionless block building, while maintaining the highest standards of security and reliability.

Improvements​

Enhanced performance​

BuilderNet v1.2 significantly improves performance compared to BuilderNet v1.1. This is particularly noticeable in the key block-building metrics of root-hash calculation and block finalization time, which we were able to reduce by about 30-50% (see also metrics at the end of this post).

The improvements are due to a combination of software updates as well as infrastructure optimizations (most notably disk type and caching settings). These setting are automatically applied when creating the infrastructure with our new Terraform module!

Terraform module for infrastructure automation​

We are happy to release an open-source Terraform module to automatically setup the optimal cloud infrastructure for running a BuilderNet node.

For now, only Azure deployments are possible. Bare-metal support is planned for the next release!

Fully automatic bootstrapping​

BuilderNet v1.2 TDX image automatically bootstraps using configuration from BuilderHub. The process is completely automated, with no manual intervention needed from either the operator or Flashbots.

System API updates​

Inside the VM, we run a component called System API. It is capable of executing predefined commands, upload files to predefined locations, and exposes system events over HTTP.

We added a few new actions:

• Refresh configuration (pulled from BuilderHub)
• Restart selected services
• Reboot the instance
• Toggle debug SSH access (SSH is disabled by default, operators can choose to enable it)

Additionally:

• Requests are now encrypted with TLS
• We’ve added support for HTTP “Basic” authentication

Here’s the full system-api configuration for BuilderNet v1.2.1: systemapi-config.toml.mustache

Minimal base image​

Our goal is to make the VM image usable for other use-cases besides running services for BuilderNet. One such example is Bottom of Block arbitrage which also runs in TEEs.

We plan to create a base image that can be extended with the services suited for a particular scenario. Actual services will be configured as OCI containers (Docker/Podman).

As a step towards this direction in this iteration we replaced two services (private bidding logic and HAProxy) with Podman containers pulled in runtime. We’ll continue replacing baked in binaries with container definitions.

Bug fixes and quality of life improvements​

• Refactor disk encryption init script to wait for the disk to appear. The disk is attached after the VM is started and needs some time to appear in the system.
• Add Azure complete provisioning script that acknowledges Azure the VM is started in the absence of Azure agent inside the VM. Without it provisioning VM using Azure API (e.g., with Terraform) never completes and VM reports not ready status in the Azure dashboard.
• Bind SSH to a non-standard port (40192)
• Update checkpoint sync URL for Lighthouse
• Refactor reth-sync script: keep the main sync process running in background, run a monitor in foreground that continuously reports the download progress to System API. Once the main reth-sync PID is gone the foreground monitor shuts down continuing the rest of the boot sequence.
• Add Orderflow Proxy metrics
• Fix broken system reboots
• Avoid costly Reth DB snapshot sync when directory is not empty
• Allow puling the disk encryption key from BuilderHub, while we are exploring further privacy-preserving key-management solutions.
• Fix time synchronization. Instead of syncing the time once a minute run an NTP daemon
• Fix shipping logs from containers

Reproducible builds​

BuilderNet v1.2 supports fully reproducible TDX image builds, which lets you arrive at the exact same measurements as our reference builds. Previously there were some non-deterministic parts in the build process of Podman, which we have now fixed [1] [2].

The main entry point for the image builds is the flashbots/yocto-manifests repository, and for this release specifically the v1.2.1 tag (commit da661d4).

To reproducibly build it, clone the repository, check out the tag and build it with Docker/Podman:

git clone https://github.com/flashbots/yocto-manifests.git
cd yocto-manifests
git checkout v1.2.1
make image-buildernet

The first time, building takes a long time (~1h). Subsequent runs are faster because some of the build artifacts will then be cached.

You can confirm that the hash of your build matches the expected one:

make measurements-buildernet

Build host specs:

• Ubuntu 22.04 x64 (Linux kernel 6.8.0-49-generic), fully updated system
• Intel Xeon Gold 6312U, 48vCPUs, 512GB memory

Performance & Metrics​

We also wanted to share some key performance insights (data for four days, between Feb 15 and Feb 19, 2025).

Root Hash Time: Time spent calculating root hash of the final block. p50 does typically not require any disk access, and is mostly io/cpu/keccak calculation

Finalize Time (aka Block Sealing): Time spent finalizing blocks in milliseconds. Its applying withdrawals, doing the post block call and calculating state root hash of the block. p50 does typically not require any disk access, and is mostly io/cpu/keccak calculation

Version Details​

BuilderNet is based on v1.2.1 tag (commit da661d4) of Yocto Manifests, our BuilderNet TDX image build toolchain.

Artifacts​

Signed artifacts are stored here, and the specific VM image file is buildernet-v1.2.1-azure-tdx-5ddf9cba5dfe0e3ac097b005145ad789bcfdf262231382909062b02db3d461d4.wic.vhd (checksum, signature).

Measurements​

These are the new live measurements for v1.2.1:

{
    "measurement_id": "buildernet-v1.2.1-azure-tdx-5ddf9cba5dfe0e3ac097b005145ad789bcfdf262231382909062b02db3d461d4.wic.vhd",
    "attestation_type": "azure-tdx",
    "measurements": {
        "4": {
            "expected": "b5fee89a85bf5b168efc4468c18ec4718b26a5c9fc7854bdc34ce25b60add132"
        },
        "9": {
            "expected": "210d55d0e3bd00874faaf0ac45778d53a5fd13d84e3a76720cc19b72b0eefbbc"
        },
        "11": {
            "expected": "84b0ef2e25a43fae992d27602d9c35a3ec66c32fc3d7ea08df543dcc87f287e2"
        }
    }
}

Service versions​

Join the conversation on the BuilderNet forum and the Telegram group!

Two parties build 90% of blocks on Ethereum today. This centralization of power and its impact on the application and protocol layer directly threatens Ethereum’s resilience and neutrality.

BuilderNet is a decentralized path forward. It aims to neutralize exclusive orderflow deals, enhance Ethereum’s censorship resistance, and accelerate decentralization across rollups and apps.

The first release of BuilderNet is jointly operated by Flashbots, Beaverbuild, and Nethermind. To accelerate decentralization in block building, Beaverbuild and Flashbots will integrate their centralized block builders with BuilderNet in the coming months. In the future, BuilderNet will also be available as a drop-in solution for decentralized sequencing on L2s through Rollup-Boost.

The first release of BuilderNet is one step in a larger plan to decentralize block building across Ethereum. We’re sharing our progress and goals in the open to invite the community to join us.

Why decentralize block building​

Public blockchains like Ethereum promise to be the best global platform for finance and innovation. They provide a highly resilient ledger that can be permissionlessly updated by any user or app. In order to add new blocks to this ledger, they need a way to fairly resolve competition and optimize for complex coincidences of wants across the world. Over time it has become clear that the best way to handle this task is to outsource it to a sophisticated external party — the block builder.

Block builders extend Ethereum with a more performant and feature-rich platform for apps. They introduce private mempools that improve prices in DeFi, offer tools to reduce transaction costs, and can be programmed off-chain to support a wide range of intents. Today these features power everything from whitehat rescues via Flashbots to gasless transactions in Bitget wallet to revenue sharing in oracle feeds like Oval. And they drive a 4x increase in execution layer rewards for validators in 90% of Ethereum blocks.

Block builders benefit the protocol as well. By handling complex tasks off-chain and making the best block freely available, they relieve the pressure for validators to perform sophisticated tasks and keep the core protocol decentralized and lightweight. They also provide Ethereum with a sophisticated external market to execute its roadmap — from protecting validators from MEV, to helping rollups scale through larger blobs, to supporting coprocessing, statelessness, and real-time proving in the future.

But outsourcing sophisticated tasks to a separate market does not address the root issue of centralization within those roles, nor does it fully maximize the productive benefits that block builders can bring to Ethereum. We must proactively design new structures that coordinate between sophisticated off-chain actors, and effectively leverage their inherent economies of scale, to create the most robust and efficient system for advancing public blockchains. In other words, we must decentralize block building itself.

Decentralizing block building will make Ethereum the strongest foundation for apps like DeFi that need a neutral platform to coordinate financial activities around the world. By distributing the monolithic process of block building across a large network, we can prevent systemic chokepoints that invite censorship and rent extraction from users. This in turn will make it possible for more parties around the world to coordinate instead of competing with each other, creating more emergent value that can be internalized as better prices for users, or support the apps and wallets that onboard people to crypto.

Why now​

90% of blocks on Ethereum are built by just two parties today. Concentration in the block building market has tripled since 2022, when Flashbots first introduced a vision to decentralize block building with SUAVE. This trend has accelerated in the past year as major orderflow providers made exclusive orderflow deals with block builders to internalize their MEV. These opaque off-chain agreements have entrenched a duopoly in the builder market and created an unequal playing field for apps and users who do not have access to the same preferential treatment — eroding the overall neutrality, censorship resistance, and resilience of Ethereum. It is abundantly clear that the future of block building will be centralized, unless we act now.

In anticipation of these challenges, Flashbots and collaborators have spent the past 2 years experimenting with different ways to decentralize block building — from programmable privacy (e.g. MEV-Share and TEE searching), to distributed block building (e.g. MEVM), to secure hardware and cryptography (e.g. TEE block builders, TEE relays, MPC and FHE backrunning). Recent improvements in the performance and application of secure hardware in MEV show that it is now possible to implement a decentralized block builder that is sufficiently performant and secure.

This is a unique window of opportunity. As Ethereum considers changing the protocol to increase its censorship resistance, we believe it must also invest in decentralizing the power structures in block building that affect those properties. Addressing this challenge from both angles will complement proposer-level changes like inclusion lists and add more defense in depth.

Introducing BuilderNet​

Today we are excited to introduce a new step in this journey to decentralize block building — BuilderNet.

BuilderNet is a new way for many parties to collaborate in building blocks. It creates an open and neutral alternative to negative-sum orderflow games, and handles complex boilerplate activities that make it difficult and expensive to participate in block building today. This frees builders, searchers, and apps to focus on driving efficiency, finding new alpha, and innovating on user value at the edges. We believe this will transform the block building market into a positive-sum game that opens the door to new kinds of innovation and collaboration on Ethereum.

To advance these goals, the first release of BuilderNet introduces a “multioperator” system where many parties can operate the same block builder for the first time. Each operator runs an instance of an open source builder in a Trusted Execution Environment (TEE), which orderflow providers (like apps, wallets, users, and searchers) can verify and send encrypted orderflow to. Each instance shares the orderflow it receives with other instances in the network and submits blocks to MEV-Boost relays as usual. After a BuilderNet instance wins a block, refunds are calculated and distributed back to orderflow providers based on the value they added to the block.

A full description and technical documentation is here. The first release of BuilderNet is operated by Flashbots, Beaverbuild, and Nethermind.

BuilderNet for users, wallets, and apps​

Apps and wallets want to internalize their MEV and give their users a cheap, easy way to transact. Today it is common for apps and wallets to make deals with builders or aggregators that reclaim fees on their behalf. BuilderNet can meet these needs in a way that is more transparent, permissionless, and democratic than the opaque custom orderflow deals in the market today.

To this end, the first release of BuilderNet uses an open source refund rule to compensate all users for their contribution to its blocks. In the future we intend to upgrade this rule to ensure it accommodates each use case, make all aspects of calculating and receiving refunds fully permissionless, and ensure all participants in the network (e.g. TEE operators) are appropriately compensated for their contributions as well.

→ Users, wallets, and apps can access refunds by sending transactions to Protect. More data is available here.

BuilderNet for searchers and solvers​

It is impossible to land a bundle on Ethereum today without trusting a third party or running your own block builder. BuilderNet changes this. The network runs in Trusted Execution Environments (TEEs) to prevent operators from leaking data or tampering with their code. It also provides refunds to every searcher that contributes to its blocks. Together these features create an even playing field where independent searchers can receive the same financial outcomes and privacy that integrated searcher-builders do today.

Ultimately we believe that the most efficient block builder will be a distributed process where many specialized agents participate and coordinate off-chain. BuilderNet is designed to accelerate this future by solving the core challenges of aggregating orderflow and creating a safe platform for coordination — so that searchers, solvers, and other off-chain agents can focus on their strategies and alpha.

→ Searchers can get refunds and privacy by sending bundles to BuilderNet today. For more, read the FAQ, search your refunds in the dashboard, and join other experiments here.

BuilderNet for validators​

Block builders do not pay the full value of their blocks to validators today. They minimize their bids to capture a profit and pay for access to exclusive orderflow — retaining close to 1,000 ETH per week, almost all of which is refunded to exclusive orderflow providers. Given that this value is already withheld from validators, we do not expect that BuilderNet will significantly impact their economics at launch.

Over time, we do expect that BuilderNet will accelerate the transition to a new equilibrium where orderflow providers retain a greater percentage of the MEV they produce. We believe that this transition towards a simpler, cheaper gas market is both inevitable and essential to making Ethereum the best place to transact. We also believe it must be handled with maximum transparency and collaboration between all affected parties — through a decentralized, open source, community builder. We intend to monitor these dynamics and will collaborate with validators to ensure BuilderNet remains fair and balanced over time.

→ Validators can read more about the current refund rule here and share thoughts here. Teams working on BuilderNet are also actively collaborating with teams working on features like preconfirmations that may be of interest to validators.

BuilderNet for L2s​

A decentralized block builder can accelerate the Ethereum roadmap in many ways — not only on L1, but also on L2s. We believe it’s essential for BuilderNet to support the needs of rollups as users and financial activity increasingly migrate to those new domains, and we’ve designed it with this goal from the start.

Outsourcing block building to BuilderNet provides rollups with a highly available and resilient sequencer and accelerates their decentralization roadmap without major protocol changes on L1 or L2. In doing so, rollups can offer a more fair, global platform for DeFi and other apps that require strong censorship resistance properties. BuilderNet also gives rollups a straightforward way to redistribute MEV or enforce verifiable ordering rules, which can improve the economics and UX of their apps.

BuilderNet launches on L1 today. In the future we’re excited to bring these benefits and more to L2s through Rollup-Boost.

BuilderNet for block builders​

In addition to supporting BuilderNet as operators, Beaverbuild and Flashbots will integrate their centralized builders with BuilderNet in the coming months. This includes merging their software, infrastructure, and orderflow with the decentralized network.

Today, Beaverbuild is beginning this process by running instances of their builder in TEEs. This will allow Beaverbuild to incrementally adopt TEEs and join the decentralized network with minimal disruption for its users. It also can provide a model to progressively decentralize and integrate other block builders with BuilderNet in the future.

Tomorrow we believe that there will no longer be a discrete entity known as a “block builder” but rather a distributed process that produces blocks. The core boilerplate of block building will become a public utility which supports this decentralized network — involving today’s builders, searchers, and orderflow providers as well as new types of programs entirely. We invite each of these parties to join us in accelerating this future.

Roadmap​

The first release of BuilderNet is just one step in a larger plan to decentralize block building across Ethereum. We want to be clear about both the guarantees it offers today and its path to upgrade these guarantees over time.

Censorship resistance​

Each operator in BuilderNet chooses their own compliance policy. While they share all orderflow equally with other operators, they can choose to exclude transactions from certain addresses in their own blocks. This is an important step towards censorship resistance in block building because one operator can include transactions in their block even if another does not.

At launch, BuilderNet is operated by multiple different parties with different compliance policies. This means that its overall censorship resistance is greater than any individual centralized builder today, which strictly improves censorship resistance within the MEV-Boost market.

In the future, we intend to distribute the block building process in BuilderNet so that operators can extend each others’ blocks. In this model only one non-censoring operator would need to contribute to a block in order to prevent transactions from being censored even within that block. This will make BuilderNet significantly more censorship resistant than the current MEV-Boost market is, or likely ever can be — as each block will reflect the aggregate economic activity across the network, rather than the preferences or limitations of a single operator.

Architectural decentralization​

All block builders today are operated by centralized teams, which can be a point of failure, limitation, and control. BuilderNet makes it possible for many teams to operate instances of the same block builder.

At launch, all orderflow sent to Flashbots will be shared with BuilderNet. This will strictly increase the number of teams that participate in building blocks for Flashbots users. As other teams like Beaverbuild follow suit, BuilderNet will similarly increase the number of teams that participate in building blocks for their users.

But while BuilderNet can help increase architectural decentralization in certain aspects of the market today, the network itself is not fully decentralized at launch. Like all existing builders, BuilderNet relies on centralized infrastructure for functions like transaction ingress and data storage, and Operators currently need permission to join the network. In future releases, we intend to remove these dependencies, make all roles permissionless, and decentralize technical governance of BuilderNet.

Finally, architectural decentralization in BuilderNet will allow it to generate more value than centralized builders are today. We intend to let operators outsource computations to private searching and bundle merging programs, which can permissionlessly yet confidentially execute strategies that improve the value of its blocks and capture MEV.

This is an ambitious roadmap. We believe it is theoretically possible, practically tractable, and essential to build now.

Learn more about BuilderNet and participate here. You can also reach out on Telegram (@sketsdever).

Thank you to Vitalik, Viktor Bunin, Jon Charbonneau, and Barnabé Monnot for their feedback on this post.