Engineering Update – October 2025

BuilderNet
1

We’ve shipped several major features this month and are making significant progress on performance and infrastructure improvements. Here’s what’s new and what’s coming next.

Launched Delayed Refunds

Delayed refunds allow users to accumulate refunds and have them processed asynchronously, instead of receiving a refund transaction in the same block (saving the transaction fees).

Delayed refunds are enabled by sending eth_sendBundle with delayedRefund set to true.

See also the eth_sendBundle documentation and the refund API docs for more information.

API Updates

See the full API reference here: API Reference | BuilderNet

New Refund APIs

We’ve added new APIs for users to query information about the refunds they can expect:

eth_sendBundle

  • delayedRefund field has been added: API Reference | BuilderNet
  • Considerations (for later):
    • multi-block support
    • removing required signature
    • please send your thoughts, feedback and ideas

Bundle Hash Update

BuilderNet migrated to a new, unique bundle-hash, which allows users to look up refund any specific bundle. See also the above paragraph about “New Refund APIs” for more details on the APIs.

  • Bundles sent to BuilderNet now receive a unique bundle-hash in the response.
  • You can find the bundle hash implementation here in the FlowProxy repository.
  • The previous Flashbots bundle-hash algorithm takes only the transactions into account, but not any of the other fields, making it inadequate for looking up refund information.

Azure Gen6 TDX Performance Woes

The mandatory upgrade from Azure Gen5 instances to Gen6 caused a significant negative impact on performance.

Preliminary benchmarks, not authoritative
Preliminary benchmarks, not authoritative805×943 19.7 KB

We are continuing to work with Azure Support. Even though we are on a paid service tier, Azure support is not very helpful and somewhat Kafkaesque.

To that end, we are expediting hosting diversity for BuilderNet nodes. Currently we are evaluating and benchmarking the following TDX hosting options and providers:

  1. Google Cloud - Confidential VM (not GCP TDX Bare-Metal though, too large instances only, and too expensive)
  2. OpenMetal - TDX Bare Metal
  3. OVH - TDX Bare Metal

We’ll post an in-depth comparison and overview here in the forum within two weeks.

TDX Benchmarks

The Nethermind team in collaboration with Flashbots benchmarked TDX performance across providers, as well as TDX vs non-TDX.

Tools used for benchmarking:

Here are initial results for comparing hosting providers:

Initial TDX benchmarking results
Initial TDX benchmarking results810×744 22.9 KB

Benchmarks of TDX vs non-TDX performance:

CPU performance
CPU performance1580×980 109 KB

IO performance
IO performance1580×980 115 KB

CM performance
CM performance1580×980 111 KB

You can find the shell script that runs all the tests, as well as an example output when running on OVH here: Instance Benchmark Script · GitHub

Performance improvements

We’ve made several significant performance improvements:

  • rbuilder (see also rbuilder PRs)
  • orderflow-proxy rewrite in Rust
  • Experiments with iceoryx2 for zero-copy IPC.

Orderflow Proxy Upgrade

Orderflow Proxy is the BuilderNet orderflow ingestion and multiplexing engine. It’s a key component that processes and validates orderflow sent by users, and sends it to all other builder nodes as well as the in-instance rbuilder service.

Since launch, BuilderNet used a Golang-based implementation that worked (code here). We’ve considered different options to increase performance (both processing as well as multiplexing), and decided to rewrite the service in Rust.

This culminated in yesterday’s release of FlowProxy!

We are seeing significant improvements in terms of performance, stability, reuse of components as well as development ergonomics.

Optimistic v3

Optimistic v3 allows block builders to send only the header of the bid to relays, and the relay request the payload afterwards. This allows bids to arrive at the relay with a single TCP round-trip, which significantly improves latency, especially if blobs are included.

We are testing Optimistic v3 on Hoodi right now.

mkosi

A lot of progress has recently been made towards replacing the existing Yocto-based VM images with mkosi built ones, which is based on Debian. For more information about motivation and additional context, see this post: Beyond Yocto: Exploring Mkosi for TDX Images

The final services are now being provisioned correctly inside mkosi-built images, and attestations are fully working. We are expecting a fully working staging instance to be up and running within the next week.

You can follow the progress here: GitHub - flashbots/flashbots-images at trunk/buildernet

Builder Playground

We are re-igniting work on GitHub - flashbots/builder-playground: Framework to deploy local end-to-end environment for block building.

Builder Playground will be the foundation for the BuilderNet end-to-end testing and automation infrastructure.

We expect to have a fully working local development environment ready in the next month. That devenv will allow mkosi-built builder nodes run as part of the builder-playground-provided L1 network (using QEMU). This will be a big unlock for release stability and velocity as well as for collaboration.

Questions or Feedback?

We’d love to hear from you—reach out on our forum or GitHub with any questions, suggestions, or issues you’re encountering.

4 Likes