# BuilderNet documentation > BuilderNet is a block building network for Ethereum. Refunds minimise execution costs; private transactions, bundles and propAMM quote updates go directly to the builder. This file contains all documentation content in a single document following the llmstxt.org standard. ## API Reference ### Orderflow BuilderNet provides these APIs to send orderflow: - [`eth_sendBundle`](#eth_sendbundle) - [`eth_sendRawTransaction`](#eth_sendrawtransaction) - [Priority updates](#priority-updates) Market data is available from the read-only [quote stream](#state-stream-). --- #### `eth_sendBundle` You can use `eth_sendBundle` to send a bundle of transactions to BuilderNet. You can also use it to replace or cancel past bundles. Transactions sent with `eth_sendBundle` are eligible for refunds. :::info[What is a bundle] A bundle is a list of signed transactions that are executed atomically. If any transaction in the bundle fails, the entire bundle fails. This is useful for sending multiple transactions that depend on each other. ::: ##### Request ```json { "id": 1, "jsonrpc": "2.0", "method": "eth_sendBundle", "params": [{ txs // Array[String], A list of signed transactions to execute in an atomic bundle. blockNumber // String, A hex encoded block number for which this bundle is valid on. // Optional fields createdAtMs // Number (non-negative integer), Sender-provided bundle creation time, in milliseconds since the Unix epoch. replacementUuid // String, UUID that can be used to cancel/replace this bundle. replacementNonce // Number, Used to order bundles sharing the same replacementUuid. Bundles received with a lower replacementNonce than the latest accepted one are ignored. revertingTxHashes // Array[String], A list of tx hashes that are allowed to revert. droppingTxHashes // Array[String], A list of tx hashes that can be removed from the bundle if it's deemed useful (but not revert). refundTxHashes // Array[String], A list of tx hashes (max 1) that should be considered for MEV refunds. If empty, defaults to the last transaction in the bundle. minTimestamp // Number, The minimum timestamp for which this bundle is valid, in seconds since the unix epoch. maxTimestamp // Number, The maximum timestamp for which this bundle is valid, in seconds since the unix epoch. refundPercent // Number (integer between 1-99), How much of the total priority fee + coinbase payment you want to be refunded for. refundRecipient // String, The address that the funds from refundPercent will be sent to. If not specified, they will be sent to the from address of the first transaction. delayedRefund // Boolean, If true, `refundPercent` refund is processed asynchronously via BuilderNet refund pipeline rather than in the same block. refundIdentity // String, Address that BuilderNet refunds should be sent to instead of the bundle signer. disableCrossRegionSharing // Boolean, If true, prevents BuilderNet from forwarding this bundle to other regions. Defaults to false. // Target pools (requires "version": "v2") version // String, Bundle format version. Set to "v2" to use the target pool fields below. desiredState // String, Desired placement of the bundle. Set to either "BottomOfBlock" for consideration at only the bottom of the block or "AnyPosition" for consideration intrablock and bottom of the block. targetAddresses // Array[String], A list of contract addresses (e.g., AMM pools) whose state this bundle targets. targetSlots // Array[Array[String]], Hex encoded storage slots to target per address, index-aligned with targetAddresses. An empty array targets all slots of that address. }] } ``` **Notes:** - `blockNumber` can be: 1. A specific block number, hex encoded (e.g. `0x1361bd3`) 2. For next block only: `"0x"` or `null` or missing field - `uuid` is supported as alias for `replacementUuid`. **Compatibility methods:** For compatibility with other builders, BuilderNet also accepts `eth_sendEndOfBlockBundle` (alias `eth_sendBobBundle`). It takes the same bundle object as `eth_sendBundle`, with `targetPools` as an alias for `targetAddresses`: ```json { "id": 1, "jsonrpc": "2.0", "method": "eth_sendEndOfBlockBundle", "params": [{ txs // Array[String], A list of signed transactions to execute in an atomic bundle. blockNumber // String, A hex encoded block number for which this bundle is valid on. targetPools // Array[String], (Optional) A list of pool addresses this bundle targets. }] } ``` - With `targetPools`, the bundle is considered at any position in the block, equivalent to `desiredState: "AnyPosition"`. - Without `targetPools`, the bundle is only considered at the bottom of the block. - `targetPools` must be set inside the bundle object. If it is passed as a separate positional parameter, it is ignored and the bundle is only considered at the bottom of the block. We recommend `eth_sendBundle` with `"version": "v2"` instead, which lets you choose `desiredState` and target specific storage slots with `targetSlots`. **Bundle replacement and cancellation:** - **Replacing bundles**: Send another bundle with the same `replacementUuid` , and it will override any previous one. - **Cancelling bundles**: Send another bundle with the same `replacementUuid` and an empty list of transactions. **MEV Refunds:** When a searcher makes money by using some user tx, it pays the builder to be included in the block. Part of that payment is refunded to the user. To determine how much the searcher paid the builder, we check the delta in the builder's balance before and after executing a particular tx in the bundle. By checking this delta, we are considering gas payments and also explicit transfers from the searcher to the builder. These refunds should not be confused with [redistributions](./refunds.mdx). - `refundTxHashes` field (optional): Specifies which transaction in the bundle should be analyzed to measure the payment to the builder. - If present, specifies which transactions in the bundle should be considered for refund calculations. - If empty or not specified, defaults to the last transaction in the bundle. - Currently limited to a maximum of 1 transaction hash. - `refundPercent` field: - (Optional) An integer between 1-99 which defines how much of the total priority fee + coinbase payment you want to be refunded for. - Example: If a bundle pays 0.2 ETH of priority fee plus 1 ETH to coinbase, a refundPercent set to 50 will result in a transaction being appended after the bundle, paying 0.59 ETH back to the EOA. This is assuming the payout tx will cost BuilderNet 0.01 ETH in fees, which are deducted from the 0.6 ETH payout. ##### Response The response always contains the bundles unique hash which can then be used to query refunds. It also contains `receivedTimestampMs`, a Unix timestamp in milliseconds indicating when BuilderNet received the bundle. The value is a number and may include fractional milliseconds for microsecond precision. ```json { "id": 1, "jsonrpc": "2.0", "result": { "bundleHash": "0x...", "receivedTimestampMs": 1718030000123.456 } } ``` ##### Example request ```bash curl https://rpc.buildernet.org \ --header 'Content-Type: application/json' \ --header 'X-Flashbots-Signature: :' \ --data '{ "id": 1, "jsonrpc": "2.0", "method": "eth_sendBundle", "params": [{ "blockNumber": "0x1361bd3", "txs": [ "0x100000...", "0x200000..." ] }] }' ``` See [this example Golang code](https://github.com/flashbots/go-utils/blob/main/examples/send-multioperator-orderflow/main.go) for sending a transaction with a signed request. ##### Request signature and authentication `eth_sendBundle` requests require a `X-Flashbots-Signature` header for authentication and for the signer to receive [refunds](refunds): ``` X-Flashbots-Signature: : ``` The signature is calculated by taking the EIP-191 hash of the json body encoded as UTF-8 bytes. Any valid [ECDSA secp256k1](https://en.bitcoin.it/wiki/Secp256k1) key (i.e. any Ethereum key) can be used to sign the payload. The address associated with this key will be used for [Redistribution](refunds). For more details and examples on signing the payload, see the [documentation here](https://docs.flashbots.net/flashbots-auction/advanced/rpc-endpoint#authentication). ##### Example Golang code See [this example Golang code](https://github.com/flashbots/go-utils/blob/main/examples/send-multioperator-orderflow/main.go) for sending a signed transaction to a builder node. ##### Bundle Hash "bundle hash" is a unique identifier for a specific bundle of transactions sent to BuilderNet. It is returned as response of the `eth_sendBundle` RPC call. You can use this hash to look up refunds for a specific bundle by using the [buildernet_getFeeRefundsByBundle](#buildernet_getfeerefundsbybundle) API. See the [reference implementation in FlowProxy](https://github.com/BuilderNet/FlowProxy/blob/07c4e33af664098a29be45807e8d9f0a48b85749/src/primitives/mod.rs#L95). Note that the implementation may change over time, and we recommend to use the hash returned by the `eth_sendBundle` RPC call directly. --- #### `eth_sendRawTransaction` You can use `eth_sendRawTransaction` to send a single signed transaction to BuilderNet. Transactions sent with `eth_sendRawTransaction` are NOT eligible for refunds. Transactions sent this way are: - _not_ sent to the mempool. - propagated to other BuilderNet builder nodes. - tried to include for up to 5 blocks. ###### Request ```json { "id": 1, "jsonrpc": "2.0", "method": "eth_sendRawTransaction", "params": ["0x000000..."] } ``` ###### Response The response contains the transaction hash: ```json { "id": 1, "jsonrpc": "2.0", "result": "0x000000..." } ``` ###### Request signature and authentication `eth_sendRawTransaction` requests also require a `X-Flashbots-Signature` header for authentication. For more details, see the [relevant section for `eth_sendBundle`](#request-signature-and-authentication-). --- #### Priority updates A priority update is a transaction that BuilderNet includes ahead of other transactions accessing the same state. Market makers use priority updates to run propAMMs (proprietary AMMs): onchain pools whose quotes are refreshed offchain many times per slot. The builder guarantees that takers trade against the freshest posted quote. **Priority update transactions must post data through the [Priority Update Registry](https://github.com/flashbots/priority-update-registry), which scopes the state an update can write.** These updates can be configured in one of two modes: * **Conditional:** the update lands only if a transaction consuming it is also included in the same block, so the maker pays gas only on fills. Conditional updates are not guaranteed to be at the top of the block. This is the main way to use priority updates. * **Top-of-Block:** the update lands at the top of the next block, unconditionally. The maker pays gas every block the update lands. The implementation is new and exact behaviour is subject to change. Feedback welcome. When multiple updates for the same state are available at the time a block is built, the builder will prioritise the latest update. The mode is set per API key. This requirement may be dropped in future. Updaters needing both modes can request multiple keys. Reach out to get API keys (see [How to participate](how-to-participate)). ##### Pricing Priority update transactions pay no priority fees. Makers are charged a volume-based fee on filled trades. Reach out for pricing. ##### Taker speed bump A taker transaction that touches priority-update state is only eligible for inclusion once the builder has held it for at least 50 ms. This protects makers from takers attempting to snipe stale quotes. ##### How conditional inclusion works Each maker registers one or more event signatures (a contract address and an event topic) that identify the event their pool emits when a swap consumes a quote. A conditional update is included only when a transaction in the block emits a matching log. What this means for integrators: - **Makers:** register your consumption events when your conditional API key is provisioned. Without a registered event, conditional updates never land. We plan to upgrade the event registration flow soon. - **Pool authors:** emit a distinct event on the fill path, not in view or quote paths. - **Takers and routers:** nothing. Consumption is detected from the fill's logs automatically. The optional `asset_pairs`, `quote_address` and `pool_addresses` request fields are recorded as metadata and do not currently affect inclusion. ##### Endpoints Priority updates are submitted over WebSocket on the same hosts as the JSON-RPC endpoints (see [BuilderNet endpoints](send-orderflow#buildernet-endpoints)) at the path `/ws/sendquoteupdate`, e.g. `wss://rpc.buildernet.org/ws/sendquoteupdate`. ##### Request Messages are protobuf-encoded: ```proto message PWebsocketQuoteUpdateV1Args { bytes tx = 1; // RLP-encoded quote tx (empty for cancellation) uint64 block_number = 2; // Target block bytes replacement_uuid = 3; // 16-byte quote identifier uint64 replacement_seq_number = 4; // Monotonic sequence (>0) bool disable_cross_region_sharing = 5; // Optional PropAMM metadata. // Pairs affected by this update. Each entry is 40 bytes: token0 || token1. repeated bytes asset_pairs = 6; // 20-byte address a taker must touch to receive a quote. bytes quote_address = 7; // Pool addresses whose swaps require this update. Each entry is 20 bytes. repeated bytes pool_addresses = 8; } ``` **Replacement and cancellation:** - **Replace**: send a new message with the same `replacement_uuid` and a higher `replacement_seq_number`. - **Cancel**: same as replace, but with an empty `tx`. ##### Response ```proto message PWebsocketQuoteUpdateV1Response { bytes replacement_uuid = 1; uint64 replacement_seq_number = 2; uint64 timestamp = 3; // RPC receive time (UNIX nanos) string error = 4; // Error details on failure } ``` ##### Authentication Set the API key in the `Authorization` header when establishing the WebSocket connection. ##### Submission best practices - Use one `replacement_uuid` per quoted instrument and increase `replacement_seq_number` monotonically. The builder keeps only the highest sequence number for each uuid, so refresh a quote by replacing it rather than creating a new uuid. - Target the next block in `block_number` and resend on each new head. Updates for past blocks are dropped. ##### State stream You can subscribe to a read-only stream of the priority update state the builder would apply to the next block. Only priority updates that opt in to publishing are included in the stream. Appearing in the stream does not guarantee inclusion: conditional updates still land only when a matching consumption event is emitted. The stream is exposed over WebSocket on the same hosts as the JSON-RPC endpoints (see [BuilderNet endpoints](send-orderflow#buildernet-endpoints)) at the path `/ws/pamm_quote_stream`. No API key is required, e.g. `wss://rpc.buildernet.org/ws/pamm_quote_stream`. Each message is a JSON snapshot describing the aggregated state overrides for the next block: ```json { "slot": 14372440, "blockNumber": 25137544, "timestamp": 1779293304512809332, "0x0000000000000000000000000000000000000000": { "stateOverride": { "0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640": { "stateDiff": { "0x0000000000000000000000000000000000000000000000000000000000000000": "0x00014402d302d301f2030bdf000000000000547eda875f9cf4410635a0b28154", "0x0000000000000000000000000000000000000000000000000000000000000002": "0x0000000000000000000000000000170574a8b2439b6436f669cd2f061bd02bc2", "0x0000000000000000000000000000000000000000000000000000000000000003": "0x00000000000000000012ed16f4d0744000000000000000000000000001f1ab12" } } } } } ``` | Field | Description | | --- | --- | | `slot` | Target slot for the snapshot. | | `blockNumber` | Target block number. | | `timestamp` | Snapshot time (UNIX nanoseconds). | | `0x…` (address keys) | A venue's stream address (see the table below); most venues have one key, Metric has one per oracle. Each maps to a `stateOverride` object describing the storage the builder would apply for that venue's priority updates. | The addresses in a message play different roles: - **Top-level keys** are stream addresses: a stable identifier each venue's overrides are published under (see the table below). Use them to select which venue's state to consume. - **Keys inside `stateOverride`** are the contract accounts whose storage the pending updates modify. The object uses the standard Ethereum state-override format: each account maps to a `stateDiff`, which maps 32-byte storage slots to their 32-byte values. It can be passed directly as the state-override parameter to `eth_call` or `eth_simulateV1` to quote against next-block state. ##### propAMM stream addresses Venues that use the shared Priority Update Registry write `0xDa7AfEeD021EAFC1c1Af9C362dE477DaD0396B81`, which replaced `0xda7afeed01fe625cf15d187a19f94b45f00b8c5f` on 2026-09-15; the others write their own pricing contract. `buildernet_getPammStateOverrides` on `https://rpc.buildernet.org/pamm/rpc` returns the current snapshot on demand. Venues (as of 2026-09-29): | Venue | Stream address (top-level key) | State override target | | --- | --- | --- | | FermiSwap | `0x5979458912F80B96d30D4220af8E2e4925A33320` (pool and router) | `0x0109AA912B58508886a2a707204B0F8C8b164CCc` (pricing engine) | | Tempest | `0x00000003f1EC2379e79F58E12eC6c4F51ee92149` | `0xDa7AfEeD021EAFC1c1Af9C362dE477DaD0396B81` (Priority Update Registry) | | Bebop | `0xB09999A44e3240193193Be9dD99CC73c8cc945A6` (pricing contract; swaps on `0xB09AAA8933626d7E4C48D65dAd2D77021CFBCA9a`) | `0xDa7AfEeD021EAFC1c1Af9C362dE477DaD0396B81` (Priority Update Registry) | | Kipseli | `0xC9A956b5196DFe110DEBE8781857Bc8B97d32091` (price oracle; router `0x342b8458161137d0203605Fa51E4363c1445ADCD`) | `0xDa7AfEeD021EAFC1c1Af9C362dE477DaD0396B81` (Priority Update Registry) | | El Zorro | `0xcf211b4dd0d2be5c173ea57bcf938fc61d1d3bd3` (pool and router) | `0xDa7AfEeD021EAFC1c1Af9C362dE477DaD0396B81` (Priority Update Registry) | | TaurusFi | `0x217d58931a8549ca539426aa8152e33dafc3d95a` | `0xDa7AfEeD021EAFC1c1Af9C362dE477DaD0396B81` (Priority Update Registry) | | Metric | one key per oracle: `0xe844701934d9c6085b292e428f41b911cc0b3872` (CompressedOracleV1) and `0x30a88bf894d1b806125a23ebf23d715496fd7102` (PythOracle) | the same oracle | Superseded addresses, no longer used: Bebop `0xB0999914B3DE1be58Ef2416af09Bd2E7F8AaD03C`, Kipseli `0xfe3d12b21d2602868223e83149bdbbfb5d11e185`, and the previous registry instance `0xda7afeed01fe625cf15d187a19f94b45f00b8c5f`. ##### Routing against propAMMs propAMM liquidity is ordinary onchain liquidity, and any contract can fill against it. The [IPropAMM](https://github.com/lambdaclass/propamm-router-contracts/blob/main/src/interfaces/IPropAMM.sol) interface provides a common way to discover, quote, and swap against propAMMs. The Lambda Class [PropAMMRouter](https://github.com/lambdaclass/propamm-router-contracts) is a reference integration: a single-hop router that quotes and executes against a propAMM and falls back to Uniswap V3 when the propAMM can't fill. We are also building just-in-time routing: route selection at block building time, so takers get filled against the freshest propAMM quotes and onchain state. This leads to tighter spreads and lower revert rates. Reach out if you want to integrate early. --- ### Refunds :::note Refund APIs should be queried at `https://relay.flashbots.net`. ::: BuilderNet provides these APIs to check refunds data: - [`buildernet_getFeeRefundTotalsByRecipient`](#buildernet_getfeerefundtotalsbyrecipient) - [`buildernet_getFeeRefundsByRecipient`](#buildernet_getfeerefundsbyrecipient) - [`buildernet_getFeeRefundsByBlock`](#buildernet_getfeerefundsbyblock) - [`buildernet_getFeeRefundsByBundle`](#buildernet_getfeerefundsbybundle) - [`buildernet_setFeeRefundRecipient`](#buildernet_setfeerefundrecipient) - [`buildernet_getDelayedRefunds`](#buildernet_getdelayedrefunds) - [`buildernet_getDelayedRefundTotalsByRecipient`](#buildernet_getdelayedrefundtotalsbyrecipient) --- #### buildernet_getFeeRefundTotalsByRecipient The `buildernet_getFeeRefundTotalsByRecipient` JSON-RPC method returns the total amount of fee refunds that have been earned by a specific address. ```json { "jsonrpc": "2.0", "id": 1, "method": "buildernet_getFeeRefundTotalsByRecipient", "params": [ recipient, // String, the address to query for fee refunds ] } ``` The response contains three fields: ```json { "pending":"0x17812ea4fbbe314", "received":"0x108d1b27b63a213", "maxBlockNumber":"0x13ddb08" } ``` - `pending`: the total amount of fee refunds that have been earned but not yet received by the recipient - `received`: the total amount of fee refunds that have been received by the recipient - `maxBlockNumber`: the highest block number for which fee refunds have been processed #### buildernet_getFeeRefundsByRecipient The `buildernet_getFeeRefundsByRecipient` JSON-RPC method returns detailed information about [fee refunds](./refunds.mdx) that have been earned by a specific address. Our refund process usually calculates these values with a 4 hour delay. ```json { "jsonrpc": "2.0", "id": 1, "method": "buildernet_getFeeRefundsByRecipient", "params": [ recipient, // String, the address to query for fee refunds cursor, // [optional] String, the cursor to continue from ] } ``` Responses are paginated and contain the following fields: ```json { "refunds": [ { "hash": "0x...", "amount": "0x...", "blockNumber": "0x13ddaa4", "status": "sent", "recipient": "0x...", "refundTxHash": "0x...", "refundTxBlockNumber": "0x...", "refundTxStatus": "confirmed" }, ... ], "cursor": "0x..." } ``` The `"refunds"` field contains an array of per-order fee refunds, each with the following fields: - `hash`: the bundle hash or transaction hash associated with the fee refund - `amount`: the amount of the fee refund, in wei - `blockNumber`: the block number the order was contained in - `status`: the status of the fee refund, either "pending" or "sent" - `recipient`: the address the fee refund is credited to, either the bundle signer or transaction sender - `refundTxHash`, `refundTxBlockNumber`, `refundTxStatus`: the payout transaction, once the fee refund has been sent The `"cursor"` field is only included if there are more fee refunds to fetch. To continue fetching fee refunds, include the cursor as the second argument in the next request. NOTE: This API currently only returns details for bundles included in block 20802497 and later. To see total fee refunds processed for a specific address since inception, use the `buildernet_getFeeRefundTotalsByRecipient` method. #### buildernet_getFeeRefundsByBundle The `buildernet_getFeeRefundsByBundle` is similar to `buildernet_getFeeRefundsByRecipient` but returns result for the given bundle. ```json { "jsonrpc": "2.0", "id": 1, "method": "buildernet_getFeeRefundsByBundle", "params": [ bundle_hash, // String, the hash of the bundle ] } ``` #### buildernet_getFeeRefundsByBlock The `buildernet_getFeeRefundsByBlock` is similar to `buildernet_getFeeRefundsByRecipient` but returns result for the given block. ```json { "jsonrpc": "2.0", "id": 1, "method": "buildernet_getFeeRefundsByBlock", "params": [ block_number, // String, hex-encoded block number (e.g. 0x15d0280) ] } ``` #### buildernet_setFeeRefundRecipient The `buildernet_setFeeRefundRecipient` JSON-RPC method allows a user to "delegate" their [fee refunds](./refunds.mdx) to a specific wallet address. Two addresses must be provided, the first is the address associated with the signing key used to authenticate your request, while the second is the address to send refunds to. ```json { "jsonrpc": "2.0", "id": 1, "method": "buildernet_setFeeRefundRecipient", "params": [ "0xD2824D2D7D6399a4b9A47F258B870D2AFb213948", "0xa273A268CE96E54cF6a7D879B7d016F57E396F48" ] } ``` If the first address matches the authentication signature, then a response with `from` and `to` fields in the result will be returned: ```json { "jsonrpc": "2.0", "id": 1, "result": { "from":"0xd2824d2d7d6399a4b9a47f258b870d2afb213948", "to":"0xa273a268ce96e54cf6a7d879b7d016f57e396f48" } } ``` If the signature is invalid or does not match the first address, an appropriate error will be returned instead. #### buildernet_getDelayedRefunds The `buildernet_getDelayedRefunds` JSON-RPC method returns detailed information about delayed refunds. ```json { "jsonrpc": "2.0", "id": 1, "method": "buildernet_getDelayedRefunds", "params": [ { recipient, // String, the address that receives delayed refunds blockRangeFrom, // [optional] String, hex-encoded block number for the start of the range (inclusive) blockRangeTo, // [optional] String, hex-encoded block number for the end of the range (inclusive) cursor, // [optional] String, the cursor to continue from hash, // [optional] String, bundle hash; if provided, you must also set both blockRangeFrom and blockRangeTo } ] } ``` Responses are paginated and contain the following fields: ```json { "refunds": [ { "amount": "0x...", "blockNumber": "0x13ddaa4", "hash": "0x...", "recipient": "0x...", "status": "pending" }, ... ], "nextCursor": "0x...", "indexedUpTo": "0x..." } ``` The `"refunds"` field contains an array of per-order fee refunds, each with the following fields: - `amount`: the amount of the delayed refund, in wei - `blockNumber`: the block number the order was contained in - `hash`: the bundle hash that generated delayed refund - `status`: the status of the delayed refund, either "pending" or "received" - `recipient`: the address the delayed refund is credited to The `"nextCursor"` field is only included if there are more delayed refunds to fetch, or if more data might become available in the future. To continue fetching, pass its value as the `cursor` field in the next request. If the response is empty but contains `nextCursor`, retry later. `"indexedUpTo"` contains maximum block number for which delayed refunds are indexed #### buildernet_getDelayedRefundTotalsByRecipient The `buildernet_getDelayedRefundTotalsByRecipient` JSON-RPC method returns the total amount of delayed refunds that have been earned by a specific address. ```json { "jsonrpc": "2.0", "id": 1, "method": "buildernet_getDelayedRefundTotalsByRecipient", "params": [ { recipient, // String, the address to query for delayed refunds blockRangeFrom, // [optional] String, hex-encoded block number for the start of the range (inclusive) blockRangeTo, // [optional] String, hex-encoded block number for the end of the range (inclusive) } ] } ``` The response contains three fields: ```json { "indexedUpTo":"0x13ddb08", "pending":"0x17812ea4fbbe314", "received":"0x108d1b27b63a213" } ``` - `indexedUpTo`: the highest block number for which delayed refunds have been processed - `pending`: the total amount of fee refunds that have been earned but not yet received by the recipient - `received`: the total amount of fee refunds that have been received by the recipient --- ## How to participate #### Users, Wallets, and Apps Use [Flashbots Protect](https://protect.flashbots.net/) to transact securely through BuilderNet and receive refunds for your transactions. See the [Protect documentation](https://docs.flashbots.net/flashbots-protect/overview) for more details. For advanced users: send orderflow directly to a BuilderNet node. See the advanced [documentation](send-orderflow) for more information. --- #### Searchers and Solvers Submit bundles [directly to BuilderNet](send-orderflow) to be eligible for refunds. Learn more about how to optimize your bundles for refunds [here](https://collective.flashbots.net/t/refund-rule-wat-dis-how-to-and-faq/4049) and find historical data for your signer [here](https://app.hex.tech/9eb1e790-53f7-4c16-be76-4a22c1aa7d17/app/0c2d34ef-1304-481a-b3d6-b773ce9e0e19/latest). --- #### Market makers (propAMMs) If you operate a proprietary AMM (propAMM), stream your quote updates to BuilderNet as [priority updates](api#priority-updates). Depending on the mode set for your API key, the builder places an update at the top of the block or includes it only when a transaction in the block emits a consumption event registered for your key. Updates are sent over WebSocket and go through the [Priority Update Registry](https://github.com/flashbots/priority-update-registry). API keys are issued on request; message the team on Telegram (see below). Aggregators and solvers that route against propAMM liquidity can read the pending quote state from the [quote stream](api#state-stream-). No key is needed. --- #### Developers Contribute to [rbuilder](https://github.com/flashbots/rbuilder), the open source block builder that BuilderNet's builder is derived from. Join the conversation in the [Telegram group](https://t.me/flashbots_rbuilder). --- #### Researchers Contribute to the security and design of decentralized block building through initiatives like [zero trust execution environments](https://writings.flashbots.net/ZTEE), applications of software cryptography in MEV (eg. [MPC](https://writings.flashbots.net/backrunning-private-txs-MPC), [FHE](https://writings.flashbots.net/blind-arbitrage-fhe)), and more on our [research forum](https://collective.flashbots.net/c/research/20). Apply for grants from teams like Flashbots and the PBS Foundation to research new proposals like [TEE-Boost](https://collective.flashbots.net/t/tee-boost/3741). We are interested in establishing robust benchmarks for decentralization that can be used to measure BuilderNet’s progress and bring transparency to the community, and welcome input on the [forum](https://collective.flashbots.net/). --- :::note If you'd like to discuss BuilderNet directly, reach out to our team on Telegram ([@sketsdever](https://t.me/sketsdever)). ::: --- Join the discussion in the [Flashbots forum](https://collective.flashbots.net/c/buildernet/31)! --- ## Open-source software BuilderNet's block builder is derived from [rbuilder](https://github.com/flashbots/rbuilder). Production runs a Flashbots-maintained version with additional components, including bidding and orderflow ingress, which are not open source. --- #### Core services | Repository | Description | | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | [github.com/flashbots/rbuilder](https://github.com/flashbots/rbuilder) | The open source block builder BuilderNet is derived from | | [github.com/sigp/lighthouse](https://github.com/sigp/lighthouse) | CL client | | [github.com/paradigmxyz/reth/](https://github.com/paradigmxyz/reth/) | EL client | --- ## Public identification #### Key identifiers Blocks built by BuilderNet nodes expose these key identifiers: | Identifier | Description | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Extra data | `BuilderNet` (earlier blocks used `BuilderNet ()`) | | Coinbase signing key | For signing the block and the proposer payment transaction. Also to accrue MEV value, which is later [redistributed to users](refunds). Currently the coinbase signing key is common across builder instances and has the address [`0xdadB0d80178819F2319190D340ce9A924f783711`](https://etherscan.io/address/0xdadB0d80178819F2319190D340ce9A924f783711) (ENS: [`buildernet.eth`](https://etherscan.io/name-lookup-search?id=buildernet.eth)). | | Relay submission keys | BuilderNet uses multiple BLS keys to sign bids submitted to relays, one per region. | | Refund transactions | Refunds are sent from address [`0x62A29205f7Ff00F4233d9779c210150787638E7f`](https://etherscan.io/address/0x62A29205f7Ff00F4233d9779c210150787638E7f) (ENS: [`refunds.buildernet.eth`](https://etherscan.io/name-lookup-search?id=refunds.buildernet.eth)) | --- #### BLS keys for submitting blocks to MEV-Boost relays | Status                              | Signing key address | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | Active | `0x850b00e055388c1b56f137e0852bc02d8b05534e9f96dd1d11cff8cf0481b800ecc2e708cdc158cd95b7cfdaa6840ee7`, `0x853b0078c722ade5dd089dd9ce2eea3890dcc825213231600b3023ab92aa3e835c5325f31515b82a9a0559c881a14cde`, `0x857b00388fc623b52cec21b5dde4f0e543dd824db41d30480bbd6d1885f9c69833745a0396573aa1013ecacda3c118d7` | | Retired | `0x851b00b12f73770337fbd219b439aba7bd8e770dbdea16a3b0df030d971bc0d824d470d7868e5d93355f501bfe892947`, `0x856b00042301181ccf5277309c6f44595e343a284187bfe9868d6812e46fba21831fecbe8b0e6814c1463ba540ac3f46` | | Retired | `0x852b0070e2522fcb06dcb159fabcdc7a4b5e1221cc2a56b083577cce03e50afe1b699c5a1111eb3bb1b8684aa90a8333`, `0x855b00e6b2c5dd524d2689bd43e0a965262810cbd7a2c71166f53594fb01bba8151bdd6a09ddb0408f7063b17eb3742e` | --- ## Refunds BuilderNet refunds MEV value to the parties who contribute orderflow 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 privately submit transactions or bundles to BuilderNet receive refunds based on the value their orderflow adds. 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 refund rule is outlined below. For further details about how to bid and interact with the refund rule, read the [explainer](https://collective.flashbots.net/t/refund-rule-wat-dis-how-to-and-faq/4049/2). 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 :::note The flat tax rule as described here is indicative only. We customise our implementation for some customer needs, and have made modifications for DoS protection and scalability. ::: - **$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 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 and users 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](https://collective.flashbots.net/). ### Data Refund data is available through the [BuilderNet APIs](./api.mdx#refunds). ### Refund wallet Refund transactions are sent from address [`0x62A29205f7Ff00F4233d9779c210150787638E7f`](https://etherscan.io/address/0x62A29205f7Ff00F4233d9779c210150787638E7f) (ENS: [`refunds.buildernet.eth`](https://etherscan.io/name-lookup-search?id=refunds.buildernet.eth)). --- ## Resources Important articles, forum posts, and technical discussions about BuilderNet's architecture, features, and research directions. | Resource | Date | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | | [Priority Update Registry (GitHub)](https://github.com/flashbots/priority-update-registry) | March 2026 | | [The Evolution of Remote Attested TLS - TEE - Trusted Execution Environment](https://collective.flashbots.net/t/the-evolution-of-remote-attested-tls/5383) | November 2025 | | [Combined refunds](https://collective.flashbots.net/t/combined-refunds/5270) | September 2025 | | [Moving away from aTLS](https://collective.flashbots.net/t/moving-away-from-atls/5176) | August 2025 | | [Building Trust Through Reproducibility ](https://collective.flashbots.net/t/building-trust-through-reproducibility/5111) | July 2025 | | [The Free Option Problem in ePBS, Part II - Research - The Flashbots Collective](https://collective.flashbots.net/t/the-free-option-problem-in-epbs-part-ii/5145) | August 2025 | | [The Free Option Problem in ePBS](https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115) | July 2025 | | [Announcing the First BuilderNet Community Call](https://collective.flashbots.net/t/announcing-the-first-buildernet-community-call/5013) | June 2025 | | [TEE service governance and provisioning framework](https://collective.flashbots.net/t/tee-service-governance-and-provisioning-framework/4995) | June 2025 | | [Geographic Decentralisation Research Directions](https://collective.flashbots.net/t/geographic-decentralisation-research-directions/5040) | June 2025 | | [Updated MEV-Boost relay settings](https://collective.flashbots.net/t/updated-mev-boost-relay-settings/4881) | April 2025 | | [Announcing multi-client support for rbuilder](https://collective.flashbots.net/t/announcing-multi-client-support-for-rbuilder/4895) | April 2025 | | [Beyond Yocto: Exploring Mkosi for TDX Images](https://collective.flashbots.net/t/beyond-yocto-exploring-mkosi-for-tdx-images/4739) | March 2025 | | [Network-level Censorship: Understanding the Problem](https://collective.flashbots.net/t/network-level-censorship-understanding-the-problem/4769/1) | March 2025 | | [The Block Auction Infrastructure Race](https://collective.flashbots.net/t/the-block-auction-infrastructure-race/4734) | March 2025 | | [Refund rule: wat dis, how to and FAQ](https://collective.flashbots.net/t/refund-rule-wat-dis-how-to-and-faq/4049) | November 2024 | | [Searching in TDX](https://collective.flashbots.net/t/searching-in-tdx/3902) | September 2024 | | [Decentralized crypto needs you: to be a geographical decentralization maxi](https://collective.flashbots.net/t/decentralized-crypto-needs-you-to-be-a-geographical-decentralization-maxi/1385) | March 2023 | --- ## Roadmap BuilderNet is a work in progress. We intend to incrementally upgrade the network be more permissionless, distributed, and resilient -- and we welcome collaboration and input throughout this process. ### Goals **Permissionlessness**: Anyone must be able to operate and use BuilderNet. This will lower the barrier for new parties to enter the network and remove single points of failure, making it more resilient to capture and faults. **Maximum participation**: BuilderNet should not just *allow* anyone to participate, it should intentionally maximize the number of parties that contribute to each block. Coordinating across many parties with different skills and locations will increase its resilience and unlock more economically valuable interactions. **Capture resistance**: Finally, BuilderNet must prevent a few parties from gaining a position of value extraction or control within the network. This will ensure that powerful economic actors cannot capture its governance, censor transactions, or seek rent — keeping BuilderNet itself decentralized, so that it can do the same for Ethereum. ### Milestones --- ## How to send orderflow Orderflow sent to [Flashbots Protect](https://protect.flashbots.net), [Flashbots Bundle Relay](https://docs.flashbots.net/flashbots-auction/advanced/rpc-endpoint) and [MEV-Share](https://docs.flashbots.net/flashbots-mev-share/introduction) is automatically shared with BuilderNet. Advanced users can send orderflow directly to BuilderNet nodes. --- :::note The instructions in this document are intended for advanced technical users. As a regular user, you can simply use [Flashbots Protect](https://protect.flashbots.net) to transact securely through BuilderNet and get refunds for your transactions. ::: ### Sending orderflow to BuilderNet directly The global endpoint `rpc.buildernet.org` automatically routes requests to the closest available BuilderNet node. To target a specific region (e.g. US or EU), use the corresponding regional endpoint. Submitted orderflow is propagated to all other BuilderNet nodes, including those in other regions, by default. Using a regional endpoint does not restrict sharing to that region. To disable cross-region sharing for a bundle, explicitly set `disableCrossRegionSharing` to `true` in your [`eth_sendBundle`](api#eth_sendbundle) request. For best performance, reuse a single long-lived connection instead of opening a new one per request — this avoids repeating the TCP and TLS handshakes on every submission. Prefer HTTP/2, which multiplexes many requests over one connection. On HTTP/1.1, keep the connection open with the `Connection: keep-alive` header and reuse it across requests. #### BuilderNet endpoints | Region | Endpoint | Orderflow Port | | ------------- | ---------------------------------- | -------------- | | Global | `https://rpc.buildernet.org` | 443 | | United States | `https://direct-us.buildernet.org` | 443 | | Europe | `https://direct-eu.buildernet.org` | 443 | | Asia Pacific | `https://direct-ap.buildernet.org` | 443 | #### Supported API methods 1. [`eth_sendBundle`](https://docs.flashbots.net/flashbots-auction/advanced/rpc-endpoint#eth_sendbundle) 2. [`eth_sendRawTransaction`](https://docs.metamask.io/wallet/reference/json-rpc-methods/eth_sendrawtransaction/) 3. [Priority updates](api#priority-updates) — quote updates from propAMM market makers (WebSocket, API key required) 4. [Quote stream](api#state-stream-) — read-only WebSocket with the pending propAMM quote state (no key required) See also the [API reference](api) for more details on the API methods. --- #### Rate limits The following rate limits apply per client when sending requests to the BuilderNet RPC endpoints: - New TCP connections per second: 10 - Concurrent TCP connections: 10 - Bandwidth in: 600 MB/min (~10 MB/s) - HTTP request rate: 1000 per 10s (~100/s) If you need increased limits, reach out to us in the Telegram group: [t.me/buildernet_general](https://t.me/buildernet_general). --- #### Example `curl` request This request sends a signed transaction to BuilderNet: ```bash curl https://rpc.buildernet.org \ --header 'Content-Type: application/json' \ --header 'X-Flashbots-Signature: :' \ --data '{ "id": 1, "jsonrpc": "2.0", "method": "eth_sendBundle", "params": [{ "blockNumber": "0x1361bd3", "txs": [ "0x100000...", "0x200000..." ] }] }' ``` See [this example Golang code](https://github.com/flashbots/go-utils/blob/main/examples/send-multioperator-orderflow/main.go) for sending a transaction with a signed request. #### Request authentication JSON-RPC requests (`eth_sendBundle`, `eth_sendRawTransaction`) need a `X-Flashbots-Signature` header. The signature is calculated by taking the EIP-191 hash of the json body encoded as UTF-8 bytes. Any valid [ECDSA secp256k1](https://en.bitcoin.it/wiki/Secp256k1) key (i.e. any Ethereum key) can be used to sign the payload. The address associated with this key will be used for [Redistribution](refunds). For more details and examples on signing the payload, see the [documentation here](https://docs.flashbots.net/flashbots-auction/advanced/rpc-endpoint#authentication). #### Example Golang code See [this example Golang code](https://github.com/flashbots/go-utils/blob/main/examples/send-multioperator-orderflow/main.go) for sending a signed transaction to a builder node. --- Join the discussion in the [Flashbots forum](https://collective.flashbots.net/c/buildernet/31)! --- ## What is BuilderNet ## Welcome to BuilderNet BuilderNet is a block building network for Ethereum. It's a secure, performant, and globally distributed network for collaborative Ethereum block building. Transactions are optimised by a competitive market of searchers without compromising on transaction privacy, and MEV value is permissionlessly redistributed to users. By maximizing participation in block building, BuilderNet reinforces the continued decentralization and resilience of public blockchains like Ethereum. Read the full mission statement [here](/blog/introducing-buildernet). :::info BuilderNet is currently transitioning to a new security model. During this period BuilderNet nodes are not running in TEEs, but backrunning and routing services continue to run in TEEs. Updates are posted to [the forum](https://collective.flashbots.net/c/buildernet/31). ::: ### Key Features 1. Multiple block builder instances, based on the open source [rbuilder](https://github.com/flashbots/rbuilder). 2. Instances share orderflow and coordinate their bids with each other. 3. TEEs let searchers compete to execute trades efficiently without compromising user privacy. 4. Users are refunded the value their orderflow contributes to the final value of the blocks. 5. Anyone can audit and [contribute](/docs/how-to-participate) to rbuilder. ### Resources - For more information about the mission of BuilderNet, read the [mission statement](/blog/introducing-buildernet) - For where BuilderNet is headed, see the [roadmap](/docs/roadmap) During a test period, BuilderNet landed the first mainnet block on November 12, 2024 at slot `10,383,036`, block number `21,172,097`, with block hash `0xb1e93268b92b9526e1ca0288e00e799362c8be6dcac72b7da1330f0f2b7ca670` and extra_data `Illuminate Dmocrtz Dstrib Prtct`. BuilderNet launched publicly on November 26, 2024, with extra_data set to `BuilderNet ()`. The first mainnet block after launch was at slot `10,483,748`, block number `21,272,327`, with block hash `0x86a32583045f379cfd483b8a5ddeaf927c73cc8c510785113c05caf35f0190e8`. --- ## Introducing BuilderNet Introducing BuilderNet — A decentralized block building network for Ethereum that runs on TEEs and shares MEV with the community. ![Cover image](/img/buildernet-cover-photo-m.jpg) 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](https://www.flashbots.net/), [Beaverbuild](https://beaverbuild.org/), and [Nethermind](https://www.nethermind.io/). 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](https://writings.flashbots.net/introducing-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](https://0x.org/post/measuring-the-impact-of-hidden-dex-costs), 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](https://noteforms.com/forms/flashbots-whitehat-intake-form?notionforms=1) to gasless transactions in [Bitget](https://www.bitget.com/) wallet to revenue sharing in oracle feeds like [Oval](https://uma.xyz/oval). And they drive a [4x increase in execution layer rewards](https://ethresear.ch/t/is-it-worth-using-mev-boost/19753) for validators in [90% of Ethereum blocks](https://mevboost.pics/). 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](https://ethcc.io/archives/a-keynote-with-vitalik-buterin) 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](https://ethereum.org/en/roadmap/danksharding/), to supporting coprocessing, [statelessness](https://ethereum.org/en/roadmap/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](https://bitcoinmagazine.com/print/operation-choke-point-2-0-how-u-s-regulators-fight-bitcoin-with-financial-censorship-) 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](https://www.relayscan.io/) 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](https://writings.flashbots.net/the-future-of-mev-is-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](https://www.binance.com/en/square/post/11663492262641) — 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](https://docs.flashbots.net/flashbots-mev-share/introduction) and [TEE searching](https://collective.flashbots.net/t/searching-in-tdx/3902)), to distributed block building (e.g. [MEVM](https://writings.flashbots.net/mevm-suave-centauri-and-beyond)), to secure hardware and cryptography (e.g. [TEE block builders](https://writings.flashbots.net/block-building-inside-sgx), [TEE relays](https://collective.flashbots.net/t/tee-boost/3741), [MPC](https://writings.flashbots.net/backrunning-private-txs-MPC) and [FHE](https://writings.flashbots.net/blind-arbitrage-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](https://vitalik.eth.limo/general/2024/10/20/futures3.html), 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. **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](https://github.com/flashbots/rbuilder) 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](https://buildernet.org/docs).** The first release of BuilderNet is operated by Flashbots, Beaverbuild, and Nethermind. ![Multioperator release](/img/multioperator-release.jpg) ### 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](https://docs.flashbots.net/flashbots-auction/advanced/gas-fee-refunds#how-are-refunds-calculated) 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](https://protect.flashbots.net/). ### 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](https://buildernet.org/docs/how-to-participate) bundles to BuilderNet today. For more, read the [FAQ](https://collective.flashbots.net/t/refund-rule-wat-dis-how-to-and-faq/4049), search your refunds in the [dashboard](https://app.hex.tech/9eb1e790-53f7-4c16-be76-4a22c1aa7d17/app/0c2d34ef-1304-481a-b3d6-b773ce9e0e19/latest), and join other experiments [here](https://collective.flashbots.net/t/searching-in-tdx/3902). ### 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](https://www.relayscan.io/builder-profit?t=7d), 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](https://buildernet.org/docs/refunds) and share thoughts [here](https://collective.flashbots.net/). 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](https://docs.unichain.org/whitepaper.pdf), 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](https://writings.flashbots.net/introducing-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](https://collective.flashbots.net/t/searching-in-tdx/3902) 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. ![Roadmap](/img/buildernet-roadmap.jpg) 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](https://buildernet.org/docs/). 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.* --- ## BuilderNet v1.2 We are excited to release BuilderNet v1.2, a significant upgrade that streamlines operator onboarding and enhances the security and performance of the BuilderNet infrastructure. 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](https://github.com/flashbots/terraform-module-azure-confidential-vm/) 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](https://github.com/flashbots/builder-hub). 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](https://github.com/flashbots/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](https://github.com/flashbots/meta-confidential-compute/blob/f1b1770d80946ea8d879632a8d572dacadb3edc4/recipes-core/system-api/files/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](https://collective.flashbots.net/t/searching-in-tdx/3902) 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](https://opencontainers.org/) (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](https://github.com/flashbots/buildernet-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](https://github.com/containers/podman), which we have now fixed [[1]](https://github.com/flashbots/meta-custom-podman/commit/bc9c4735461f591cbcd4bff8f12b67e98cd32d06) [[2]](https://github.com/flashbots/meta-custom-podman/commit/a48177738b6216f4ef828f0fa7ab7a41081bb186). The main entry point for the image builds is the [flashbots/yocto-manifests](https://github.com/flashbots/yocto-manifests) repository, and for this release specifically the [v1.2.1 tag](https://github.com/flashbots/yocto-manifests/releases/tag/v1.2.1) ([commit `da661d4`](https://github.com/flashbots/yocto-manifests/commit/da661d4ade92bc282d73f35289adacc0f381e2e8)). To reproducibly build it, clone the repository, check out the tag and build it with Docker/Podman: ```bash 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](https://measurements.buildernet.org) one: ```bash 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 ![Root Hash Metrics](/img/post-bnet12/root-hash-1.png) ![Root Hash Metrics](/img/post-bnet12/root-hash-2.png) **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 ![Finalize Time Metrics](/img/post-bnet12/finalize-time-1.png) ### Version Details BuilderNet is based on [v1.2.1](https://github.com/flashbots/yocto-manifests/releases/tag/v1.2.1) tag ([commit `da661d4`](https://github.com/flashbots/yocto-manifests/commit/da661d4ade92bc282d73f35289adacc0f381e2e8)) of Yocto Manifests, our BuilderNet TDX image build toolchain. #### Artifacts Signed artifacts are stored [here](https://downloads.buildernet.org/buildernet-images/), and the specific VM image file is [buildernet-v1.2.1-azure-tdx-5ddf9cba5dfe0e3ac097b005145ad789bcfdf262231382909062b02db3d461d4.wic.vhd](https://downloads.buildernet.org/buildernet-images/buildernet-v1.2.1-azure-tdx-5ddf9cba5dfe0e3ac097b005145ad789bcfdf262231382909062b02db3d461d4.wic.vhd) ([checksum](https://downloads.buildernet.org/buildernet-images/buildernet-v1.2.1-azure-tdx-5ddf9cba5dfe0e3ac097b005145ad789bcfdf262231382909062b02db3d461d4.wic.vhd.sha256), [signature](https://downloads.buildernet.org/buildernet-images/buildernet-v1.2.1-azure-tdx-5ddf9cba5dfe0e3ac097b005145ad789bcfdf262231382909062b02db3d461d4.wic.vhd.minisig)). #### Measurements These are the new [live](https://measurements.buildernet.org/) measurements for v1.2.1: ```bash { "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 | Service | Version | | ------------------------------------------------------------------------ | ------- | | [Lighthouse](https://github.com/sigp/lighthouse) | v5.3.0 | | [Reth](https://github.com/paradigmxyz/reth) | v1.0.8 | | [Orderflow Proxy](https://github.com/flashbots/orderflow-proxy) | v0.2.6 | | [Rbuilder-Operator](https://github.com/flashbots/rbuilder-operator/tags) | v0.1.5 | | [System-API](https://github.com/flashbots/system-api) | v0.7.0 | | [CVM-Proxy](https://github.com/flashbots/cvm-reverse-proxy) (client) | v0.1.0 | | [CVM-Proxy](https://github.com/flashbots/cvm-reverse-proxy) (server) | v0.1.0 | --- Join the conversation [on the BuilderNet forum](https://collective.flashbots.net/c/buildernet/31) and the [Telegram group](https://t.me/buildernet_general)! --- ## BuilderNet v1.3 BuilderNet v1.3 is the culmination of close collaboration with searchers, OFAs, and other orderflow providers to integrate BuilderNet directly with their production workflows. This release improves both the user experience for sending bundles to BuilderNet nodes, and the testing, observability, and deployment experience for operators to facilitate faster iteration in the future. ### 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: | Field | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `droppingTxHashes` | A list of transaction hashes contained in the bundle, that are allowed to be removed from the bundle (but not allowed to revert). This feature is typically used to allow the builder to merge multiple OFA backruns together. | | `refundPercent` | An integer between 1-99, which indicates much of the total priority fee + coinbase payment to refund. A payout transaction transferring the refund amount will be appended immediately following the bundle in the same block. The cost of the payout transaction is deducted from the overall refund. | | `refundRecipient` | An address that the funds from `refundPercent` will be transferred to in the payout transaction. If not specified, they will be sent to the `from` address of the first transaction. | 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](https://beaverbuild.org/docs.html) and [Titan](https://docs.titanbuilder.xyz/api/eth_sendbundle). :::info See the [BuilderNet API Reference](https://buildernet.org/docs/api) for more information and details. ::: #### 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. ![e2e latency improvement](/img/post-bnet13/e2e_latency.jpg) 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: ![e2e p99 metrics](/img/post-bnet13/e2ep99.jpg) #### 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](https://github.com/flashbots/buildernet-playground/) codebase which integrates BuilderNet images with [Builder Playground](https://github.com/flashbots/builder-playground/) (this is an alpha state and work-in-progress) - TDX VM images in [qcow2 format](https://docs.redhat.com/en/documentation/red_hat_virtualization/4.3/html/technical_reference/qcow2), which can be used to run locally in QEMU. - Configurable [BuilderHub](https://github.com/flashbots/builder-hub/) URL for image builds. The local devnet is based on this [Builder Playground](https://github.com/flashbots/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`)](https://github.com/flashbots/yocto-manifests/releases/tag/v1.3.0). | Project | New Version | Commit | | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | [rbuilder-operator](https://github.com/flashbots/rbuilder-operator/tags) | [`v1.0.1`](https://github.com/flashbots/rbuilder-operator/releases/tag/v1.0.1) (prev `v0.1.5`) | [43b7902](https://github.com/flashbots/rbuilder-operator/commit/43b7902925316c1fcadff67c4b2f6e078e064194) | | [orderflow-proxy](https://github.com/flashbots/orderflow-proxy) | [`v0.3.3`](https://github.com/flashbots/buildernet-orderflow-proxy/releases/tag/v0.3.3) (prev `v0.2.6`) | [7c84264](https://github.com/flashbots/buildernet-orderflow-proxy/commit/7c8426426083f829e88947c7222be626c8de1f21) | | [CVM Proxy](https://github.com/flashbots/cvm-reverse-proxy) | [`v0.1.6`](https://github.com/flashbots/cvm-reverse-proxy/releases/tag/v0.1.6) (prev: `v0.1.0`) | [8e5c9a1](https://github.com/flashbots/cvm-reverse-proxy/commit/8e5c9a13278f4864d05a6f1e7493e99f98053cea) | | [Operator API](https://github.com/flashbots/system-api) | no change, still [`v0.7.0`](https://github.com/flashbots/system-api/releases/tag/v0.7.0) | [a8296e4](https://github.com/flashbots/system-api/commit/a8296e4ccd355f5fac805828ad8e474381a6c5a2) | | Reth | no change, still `v1.0.8` | | | Lighthouse | no change, still `v5.3.0` | | | HAProxy | no change, still `v3.0.6` | | #### Changes & Pull Requests | Project | Changes | | ---------------------------- | ----------------------------------------------------------------------------------------------------------- | | rbuilder / rbuilder-operator | [v0.1.5...v1.0.1](https://github.com/flashbots/rbuilder/compare/v0.1.5...v1.0.1) (83 PRs) | | orderflow-proxy | [v0.2.6...v0.3.3](https://github.com/flashbots/buildernet-orderflow-proxy/compare/v0.2.6...v0.3.3) (24 PRs) | | cvm-reverse-proxy | [v0.1.0...v0.1.6](https://github.com/flashbots/cvm-reverse-proxy/compare/v0.1.0...v0.1.6) (13 PRs) | #### Services Configuration | Service | Configuration | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Operator API](https://github.com/flashbots/meta-confidential-compute/blob/d8bcb394310f896f98f8b83b29732678792d101e/recipes-core/system-api/files/systemapi-config.toml.mustache) | [meta-confidential-compute@d8bcb39](https://github.com/flashbots/meta-confidential-compute/blob/d8bcb394310f896f98f8b83b29732678792d101e/recipes-core/system-api/files/systemapi-config.toml.mustache) | | [HAProxy](https://github.com/flashbots/meta-evm/blob/bd51f7e9e7271970651d05282a000acf933b106c/recipes-nodes/haproxy/haproxy.cfg.mustache) | [meta-evm@bd51f7e](https://github.com/flashbots/meta-evm/blob/bd51f7e9e7271970651d05282a000acf933b106c/recipes-nodes/haproxy/haproxy.cfg.mustache) | | [Lighthouse](https://github.com/flashbots/meta-evm/blob/bd51f7e9e7271970651d05282a000acf933b106c/recipes-nodes/lighthouse/init#L37-L57) | [meta-evm@bd51f7e](https://github.com/flashbots/meta-evm/blob/bd51f7e9e7271970651d05282a000acf933b106c/recipes-nodes/lighthouse/init#L37-L57) | | [Orderflow Proxy](https://github.com/flashbots/meta-evm/blob/bd51f7e9e7271970651d05282a000acf933b106c/recipes-nodes/orderflow-proxy/files/orderflow-proxy.conf.mustache) | [meta-evm@bd51f7e](https://github.com/flashbots/meta-evm/blob/bd51f7e9e7271970651d05282a000acf933b106c/recipes-nodes/orderflow-proxy/files/orderflow-proxy.conf.mustache) | | [Rbuilder](https://github.com/flashbots/meta-evm/blob/bd51f7e9e7271970651d05282a000acf933b106c/recipes-nodes/rbuilder/config.mustache) | [meta-evm@bd51f7e](https://github.com/flashbots/meta-evm/blob/bd51f7e9e7271970651d05282a000acf933b106c/recipes-nodes/rbuilder/config.mustache) | | [Reth](https://github.com/flashbots/meta-evm/blob/bd51f7e9e7271970651d05282a000acf933b106c/recipes-nodes/reth/init#L41-L59) | [meta-evm@bd51f7e](https://github.com/flashbots/meta-evm/blob/bd51f7e9e7271970651d05282a000acf933b106c/recipes-nodes/reth/init#L41-L59) | ### 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](https://measurements.buildernet.org/) measurements for BuilderNet v1.3.0: ```json { "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](https://github.com/flashbots/yocto-manifests) repository, and for this release specifically the [yocto-manifests@v1.3.0 (commit `05638f3`)](https://github.com/flashbots/yocto-manifests/releases/tag/v1.3.0). To reproducibly build it, clone the repository, check out the tag and build it with Docker/Podman: ```bash 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](https://measurements.buildernet.org/) one: ```bash 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](https://collective.flashbots.net/c/buildernet/31) and the [BuilderNet Telegram group](https://t.me/buildernet_general)! --- ## Beaverbuild -> BuilderNet Beaverbuild is retiring their centralized block builder to work full time on BuilderNet, a decentralized mempool and block building platform for Ethereum. 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](https://beaverbuild.org/buildernet.txt). --- ## BuilderNet v1.4 BuilderNet v1.4 is the Pectra-ready version of BuilderNet. This release includes newer versions of Reth and Lighthouse, as well as a few minor bug fixes and improvements. 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`)](https://github.com/flashbots/yocto-manifests/releases/tag/v1.4.0): #### Updated services | Project | New Version | Commit | Previous Version | | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------- | | [Reth](https://github.com/paradigmxyz/reth) | `v1.3.12` | [`6f8e725`](https://github.com/paradigmxyz/reth/commit/6f8e7258f4733279080e4bd8345ce50538a40d6e) | `v1.0.8` | | [Lighthouse](https://github.com/sigp/lighthouse) | `v7.0.1` | [`e42406d`](https://github.com/sigp/lighthouse/commit/e42406d7b79a85ad4622f3a7440ff6468ac4c9e1) | `v5.3.0` | | [rbuilder-operator](https://github.com/flashbots/rbuilder-operator/tags) | [`v1.1.0`](https://github.com/flashbots/rbuilder-operator/releases/tag/v1.1.0) | [`4f4d1f2`](https://github.com/flashbots/rbuilder-operator/commit/4f4d1f231ea133cd37a2e490fa34eda97d52541b) | `v1.0.1` | | [orderflow-proxy](https://github.com/flashbots/orderflow-proxy) | [`v0.3.5`](https://github.com/flashbots/buildernet-orderflow-proxy/releases/tag/v0.3.5) | [`6fd93f8`](https://github.com/flashbots/buildernet-orderflow-proxy/commit/6fd93f883e453e1e15d97bd455bb3f66cd085aeb) | `v0.3.3` | #### Not updated services | Project | Version | Commit | | ----------------------------------------------------------- | ------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- | | [CVM Proxy](https://github.com/flashbots/cvm-reverse-proxy) | [`v0.1.6`](https://github.com/flashbots/cvm-reverse-proxy/releases/tag/v0.1.6) | [`8e5c9a1`](https://github.com/flashbots/cvm-reverse-proxy/commit/8e5c9a13278f4864d05a6f1e7493e99f98053cea) | `v0.1.0` | | [Operator API](https://github.com/flashbots/system-api) | [`v0.7.0`](https://github.com/flashbots/system-api/releases/tag/v0.7.0) | [`a8296e4`](https://github.com/flashbots/system-api/commit/a8296e4ccd355f5fac805828ad8e474381a6c5a2) | `v0.7.0` | | [HAProxy](https://github.com/haproxy/haproxy) | `v3.0.6` | #### Changes & Pull Requests | Project | Changes | | ---------------------------- | ---------------------------------------------------------------------------------------------------------- | | reth | [v1.0.8...v1.3.12](https://github.com/paradigmxyz/reth/compare/v1.0.8...v1.3.12) (2711 PRs) | | lighthouse | [v5.3.0...v7.0.1](https://github.com/sigp/lighthouse/compare/v5.3.0...v7.0.1) (339 PRs) | | rbuilder / rbuilder-operator | [v1.0.1...v1.1.0](https://github.com/flashbots/rbuilder/compare/v1.0.1...v1.1.0) (42 PRs) | | orderflow-proxy | [v0.3.3...v0.3.5](https://github.com/flashbots/buildernet-orderflow-proxy/compare/v0.3.3...v0.3.5) (5 PRs) | #### Services Configuration | Service | Configuration | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Operator API](https://github.com/flashbots/meta-confidential-compute/blob/d8bcb394310f896f98f8b83b29732678792d101e/recipes-core/system-api/files/systemapi-config.toml.mustache) | [meta-confidential-compute@d8bcb39](https://github.com/flashbots/meta-confidential-compute/blob/d8bcb394310f896f98f8b83b29732678792d101e/recipes-core/system-api/files/systemapi-config.toml.mustache) | | [HAProxy](https://github.com/flashbots/meta-evm/blob/1a40c40ed08c2ff27450f398ac040ff2902fbcf7/recipes-nodes/haproxy/haproxy.cfg.mustache) | [meta-evm@bd51f7e](https://github.com/flashbots/meta-evm/blob/1a40c40ed08c2ff27450f398ac040ff2902fbcf7/recipes-nodes/haproxy/haproxy.cfg.mustache) | | [Lighthouse](https://github.com/flashbots/meta-evm/blob/1a40c40ed08c2ff27450f398ac040ff2902fbcf7/recipes-nodes/lighthouse/init#L37-L57) | [meta-evm@bd51f7e](https://github.com/flashbots/meta-evm/blob/1a40c40ed08c2ff27450f398ac040ff2902fbcf7/recipes-nodes/lighthouse/init#L37-L57) | | [Orderflow Proxy](https://github.com/flashbots/meta-evm/blob/1a40c40ed08c2ff27450f398ac040ff2902fbcf7/recipes-nodes/orderflow-proxy/files/orderflow-proxy.conf.mustache) | [meta-evm@bd51f7e](https://github.com/flashbots/meta-evm/blob/1a40c40ed08c2ff27450f398ac040ff2902fbcf7/recipes-nodes/orderflow-proxy/files/orderflow-proxy.conf.mustache) | | [Rbuilder](https://github.com/flashbots/meta-evm/blob/1a40c40ed08c2ff27450f398ac040ff2902fbcf7/recipes-nodes/rbuilder/config.mustache) | [meta-evm@bd51f7e](https://github.com/flashbots/meta-evm/blob/1a40c40ed08c2ff27450f398ac040ff2902fbcf7/recipes-nodes/rbuilder/config.mustache) | | [Reth](https://github.com/flashbots/meta-evm/blob/1a40c40ed08c2ff27450f398ac040ff2902fbcf7/recipes-nodes/reth/init#L41-L59) | [meta-evm@bd51f7e](https://github.com/flashbots/meta-evm/blob/1a40c40ed08c2ff27450f398ac040ff2902fbcf7/recipes-nodes/reth/init#L41-L59) | ### 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](https://measurements.buildernet.org/) measurements for BuilderNet v1.4: ```json { "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](https://github.com/flashbots/yocto-manifests) repository, and for this release specifically the [yocto-manifests@v1.4.0 (commit `170d166`)](https://github.com/flashbots/yocto-manifests/releases/tag/v1.4.0). To reproducibly build it, clone the repository, check out the tag and build it with Docker/Podman: ```bash 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](https://measurements.buildernet.org/) one: ```bash 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](https://collective.flashbots.net/c/buildernet/31) and the [BuilderNet Telegram group](https://t.me/buildernet_general)! --- ## BuilderNet v1.5 BuilderNet v1.5 introduces EVM caching, an (even) faster root hash, and trusted TLS certificates to improve the security and experience of submitting orderflow. ### Changelog - [Even faster root hash](https://github.com/flashbots/rbuilder/pull/634) - [EVM caching](https://github.com/flashbots/rbuilder/pull/573) - [Reth upgrade, fixing possible root-hash issue](https://github.com/paradigmxyz/reth/releases/tag/v1.4.8) - [Trusted TLS certificates (using Let’s Encrypt, TLS termination now by HAProxy)](https://github.com/flashbots/meta-evm/pull/83) 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`)](https://github.com/flashbots/yocto-manifests/releases/tag/v1.5.0): #### Updated services | Project | New Version | Commit | Previous Version | | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | [Reth](https://github.com/paradigmxyz/reth) | [`v1.4.8`](https://github.com/paradigmxyz/reth/releases/tag/v1.4.8) | [`127595e`](https://github.com/paradigmxyz/reth/commit/127595e23079de2c494048d0821ea1f1107eb624) | [`v1.3.12`](https://github.com/paradigmxyz/reth/releases/tag/v1.3.12) | | [rbuilder-operator](https://github.com/flashbots/rbuilder-operator/tags) | [`v1.2.6`](https://github.com/flashbots/rbuilder-operator/releases/tag/v1.2.6) | [`964aecf`](https://github.com/flashbots/rbuilder-operator/commit/964aecf2795d6cc87c0b95a9543e2375ba8ce3c7) | [`v1.1.0`](https://github.com/flashbots/rbuilder-operator/releases/tag/v1.1.0) | | [orderflow-proxy](https://github.com/flashbots/orderflow-proxy) | [`v0.5.4`](https://github.com/flashbots/buildernet-orderflow-proxy/releases/tag/v0.5.4) | [`e179462`](https://github.com/flashbots/buildernet-orderflow-proxy/commit/e1794622f086864c5f69c6f1867138647669fa1d) | [`v0.3.5`](https://github.com/flashbots/buildernet-orderflow-proxy/releases/tag/v0.3.5) | | [acme.sh](https://github.com/acmesh-official/acme.sh) | `3.1.1-25-g42bbd1b4` | [`42bbd1b`](https://github.com/acmesh-official/acme.sh/commit/42bbd1b44af48a5accce07fa51740644b1c5f0a0) | - | #### Not updated services | Project | Version | Commit | | ----------------------------------------------------------- | ------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- | | [Lighthouse](https://github.com/sigp/lighthouse) | `v7.0.1` | [`e42406d`](https://github.com/sigp/lighthouse/commit/e42406d7b79a85ad4622f3a7440ff6468ac4c9e1) | | [CVM Proxy](https://github.com/flashbots/cvm-reverse-proxy) | [`v0.1.6`](https://github.com/flashbots/cvm-reverse-proxy/releases/tag/v0.1.6) | [`8e5c9a1`](https://github.com/flashbots/cvm-reverse-proxy/commit/8e5c9a13278f4864d05a6f1e7493e99f98053cea) | | [Operator API](https://github.com/flashbots/system-api) | [`v0.7.0`](https://github.com/flashbots/system-api/releases/tag/v0.7.0) | [`a8296e4`](https://github.com/flashbots/system-api/commit/a8296e4ccd355f5fac805828ad8e474381a6c5a2) | | [HAProxy](https://github.com/haproxy/haproxy) | `v3.0.6` | #### Changes & Pull Requests | Project | Changes | | ---------------------------- | ----------------------------------------------------------------------------------------------------------- | | reth | [v1.3.12...v1.4.8](https://github.com/paradigmxyz/reth/compare/v1.3.12...v1.4.8) (513 PRs) | | rbuilder / rbuilder-operator | [v1.1.0...v1.2.6](https://github.com/flashbots/rbuilder/compare/v1.1.0...v1.2.6) (36 PRs) | | orderflow-proxy | [v0.3.5...v0.5.4](https://github.com/flashbots/buildernet-orderflow-proxy/compare/v0.3.5...v0.5.4) (11 PRs) | #### Services Configuration | Service | Configuration | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Operator API](https://github.com/flashbots/meta-confidential-compute/blob/d8bcb394310f896f98f8b83b29732678792d101e/recipes-core/system-api/files/systemapi-config.toml.mustache) | [meta-confidential-compute@d8bcb39](https://github.com/flashbots/meta-confidential-compute/blob/d8bcb394310f896f98f8b83b29732678792d101e/recipes-core/system-api/files/systemapi-config.toml.mustache) | | [HAProxy](https://github.com/flashbots/meta-evm/blob/a0be2d70c447a571aa6d275b381cd9bdc282e7bd/recipes-nodes/haproxy/haproxy.cfg.mustache) | [meta-evm@a0be2d7](https://github.com/flashbots/meta-evm/blob/a0be2d70c447a571aa6d275b381cd9bdc282e7bd/recipes-nodes/haproxy/haproxy.cfg.mustache) | | [Lighthouse](https://github.com/flashbots/meta-evm/blob/a0be2d70c447a571aa6d275b381cd9bdc282e7bd/recipes-nodes/lighthouse/init#L37-L57) | [meta-evm@a0be2d7](https://github.com/flashbots/meta-evm/blob/a0be2d70c447a571aa6d275b381cd9bdc282e7bd/recipes-nodes/lighthouse/init#L37-L57) | | [Orderflow Proxy](https://github.com/flashbots/meta-evm/blob/a0be2d70c447a571aa6d275b381cd9bdc282e7bd/recipes-nodes/orderflow-proxy/files/orderflow-proxy.conf.mustache) | [meta-evm@a0be2d7](https://github.com/flashbots/meta-evm/blob/a0be2d70c447a571aa6d275b381cd9bdc282e7bd/recipes-nodes/orderflow-proxy/files/orderflow-proxy.conf.mustache) | | [Rbuilder](https://github.com/flashbots/meta-evm/blob/a0be2d70c447a571aa6d275b381cd9bdc282e7bd/recipes-nodes/rbuilder/config.mustache) | [meta-evm@a0be2d7](https://github.com/flashbots/meta-evm/blob/a0be2d70c447a571aa6d275b381cd9bdc282e7bd/recipes-nodes/rbuilder/config.mustache) | | [Reth](https://github.com/flashbots/meta-evm/blob/a0be2d70c447a571aa6d275b381cd9bdc282e7bd/recipes-nodes/reth/init#L41-L60) | [meta-evm@a0be2d7](https://github.com/flashbots/meta-evm/blob/a0be2d70c447a571aa6d275b381cd9bdc282e7bd/recipes-nodes/reth/init#L41-L60) | ### 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](https://measurements.buildernet.org/) measurements for BuilderNet v1.5: ```json { "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](https://github.com/flashbots/yocto-manifests) repository, and for this release specifically the [yocto-manifests@v1.5.0 (commit `d056865f34e0c52ceb9e0f524ea555db40a2762f`)](https://github.com/flashbots/yocto-manifests/releases/tag/v1.5.0). To reproducibly build it, clone the repository, check out the tag and build it with Docker/Podman: ```bash 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](https://measurements.buildernet.org/) one: ```bash 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](https://collective.flashbots.net/c/buildernet/31) and the [BuilderNet Telegram group](https://t.me/buildernet_general)! --- ## BuilderNet v1.6 BuilderNet v1.6 is a major release focused on consolidation, performance, and protocol readiness. This update brings a ground-up rewrite of our orderflow ingestion layer, merges rbuilder-operator into the main rbuilder codebase, and adds full support for the upcoming Fusaka hardfork. ### Highlights - **[FlowProxy](https://collective.flashbots.net/t/introducing-flowproxy/5341/1)** — 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`)](https://github.com/flashbots/yocto-manifests/releases/tag/v1.6.0): #### Updated services | Project | New Version | Commit | Previous Version | | ------------------------------------------------------ | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | [rbuilder](https://github.com/flashbots/rbuilder/tags) | [`v1.2.28`](https://github.com/flashbots/rbuilder/releases/tag/v1.2.28) | [`9a82891 `](https://github.com/flashbots/rbuilder/commit/9a82891d84874570bd0abcb0496a4e222f50ebaa) | [`v1.2.6`](https://github.com/flashbots/rbuilder/releases/tag/v1.2.6) | | [Reth](https://github.com/paradigmxyz/reth) | [`v1.9.3`](https://github.com/paradigmxyz/reth/releases/tag/v1.9.3) | [`27a8c0f`](https://github.com/paradigmxyz/reth/commit/27a8c0f5a6dfb27dea84c5751776ecabdd069646) | [`v1.4.8`](https://github.com/paradigmxyz/reth/releases/tag/v1.4.8) | | [Lighthouse](https://github.com/sigp/lighthouse) | [`v8.0.1`](https://github.com/sigp/lighthouse/releases/v8.0.1) | [`ced49dd`](https://github.com/sigp/lighthouse/commit/ced49dd265e01ecbf02b12073bbfde3873058abe) | [`v7.0.1`](https://github.com/sigp/lighthouse/releases/v7.0.1) | | [FlowProxy](https://github.com/buildernet/flowproxy) | [`v1.2.1`](https://github.com/BuilderNet/FlowProxy/releases/tag/v1.2.1) | [`3326911`](https://github.com/BuilderNet/FlowProxy/commit/33269118f4bdaf4239c4be5c7abdc4e5a6d4a7b0) | - | | [HAProxy](https://github.com/haproxy/haproxy) | [`3.2.8`](https://hub.docker.com/_/haproxy/tags?name=3.2.8) | [`9f4f467`](https://hub.docker.com/layers/library/haproxy/3.2.8/images/sha256-9f4f467bef28ee4f18a109e3678e8ae233410837adaa1cc53d8fac9d619b1927) | [`3.0.6`](https://hub.docker.com/_/haproxy/tags?name=3.0.6) | #### Not updated services | Project | Version | Commit | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- | | [CVM Proxy](https://github.com/flashbots/cvm-reverse-proxy) | [`v0.1.6`](https://github.com/flashbots/cvm-reverse-proxy/releases/tag/v0.1.6) | [`8e5c9a1`](https://github.com/flashbots/cvm-reverse-proxy/commit/8e5c9a13278f4864d05a6f1e7493e99f98053cea) | | [Operator API](https://github.com/flashbots/system-api) | [`v0.7.0`](https://github.com/flashbots/system-api/releases/tag/v0.7.0) | [`a8296e4`](https://github.com/flashbots/system-api/commit/a8296e4ccd355f5fac805828ad8e474381a6c5a2) | | [acme.sh](https://github.com/acmesh-official/acme.sh) | [`3.1.1-25-g42bbd1b4`](https://github.com/acmesh-official/acme.sh/commit/42bbd1b44af48a5accce07fa51740644b1c5f0a0) | [`42bbd1b4`](https://github.com/acmesh-official/acme.sh/commit/42bbd1b44af48a5accce07fa51740644b1c5f0a0) | #### Changes & Pull Requests | Project | Changes | | ---------- | -------------------------------------------------------------------------------------------- | | rbuilder | [v1.2.6...v1.2.28](https://github.com/flashbots/rbuilder/compare/v1.2.6...v1.2.28) (139 PRs) | | Reth | [v1.4.8...v1.9.3](https://github.com/paradigmxyz/reth/compare/v1.4.8...v1.9.3) (1570 PRs) | | Lighthouse | [v7.0.1...v8.0.1](https://github.com/sigp/lighthouse/compare/v7.0.1...v8.0.1) (414 PRs) | #### Services Configuration | Service | Configuration | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [Operator API](https://github.com/flashbots/meta-confidential-compute/blob/06de303f2076991da9110a9c8a1c73b80df1d420/recipes-core/system-api/files/systemapi-config.toml.mustache) | [meta-confidential-compute@06de303](https://github.com/flashbots/meta-confidential-compute/blob/d8bcb394310f896f98f8b83b29732678792d101e/recipes-core/system-api/files/systemapi-config.toml.mustache) | | [HAProxy](https://github.com/flashbots/meta-evm/blob/fb265a0ca11e95048d023f7edaf7a555a71d7c8c/recipes-nodes/haproxy/haproxy.cfg.mustache) | [meta-evm@fb265a0](https://github.com/flashbots/meta-evm/blob/fb265a0ca11e95048d023f7edaf7a555a71d7c8c/recipes-nodes/haproxy/haproxy.cfg.mustache) | | [Lighthouse](https://github.com/flashbots/meta-evm/blob/fb265a0ca11e95048d023f7edaf7a555a71d7c8c/recipes-nodes/lighthouse/init#L37-L57) | [meta-evm@fb265a0](https://github.com/flashbots/meta-evm/blob/fb265a0ca11e95048d023f7edaf7a555a71d7c8c/recipes-nodes/lighthouse/init#L37-L57) | | [FlowProxy](https://github.com/flashbots/meta-evm/tree/fb265a0ca11e95048d023f7edaf7a555a71d7c8c/recipes-nodes/flowproxy) | [meta-evm@fb265a0](https://github.com/flashbots/meta-evm/tree/fb265a0ca11e95048d023f7edaf7a555a71d7c8c/recipes-nodes/flowproxy) | | [Rbuilder](https://github.com/flashbots/meta-evm/blob/fb265a0ca11e95048d023f7edaf7a555a71d7c8c/recipes-nodes/rbuilder/config.mustache) | [meta-evm@fb265a0](https://github.com/flashbots/meta-evm/blob/fb265a0ca11e95048d023f7edaf7a555a71d7c8c/recipes-nodes/rbuilder/config.mustache) | | [Reth](https://github.com/flashbots/meta-evm/blob/fb265a0ca11e95048d023f7edaf7a555a71d7c8c/recipes-nodes/reth/init#L41-L60) | [meta-evm@fb265a0](https://github.com/flashbots/meta-evm/blob/fb265a0ca11e95048d023f7edaf7a555a71d7c8c/recipes-nodes/reth/init#L41-L60) | ### 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`](https://downloads.buildernet.org/buildernet-images/v1.6.0/buildernet-1.6.0-azure-tdx.wic.vhd) ### Measurements These are the new [live](https://measurements.buildernet.org/) measurements for BuilderNet v1.6: ```json { "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](https://github.com/flashbots/yocto-manifests) repository, and for this release specifically the [yocto-manifests v1.6.0 (commit `68962ce`)](https://github.com/flashbots/yocto-manifests/releases/tag/v1.6.0). To reproducibly build it, clone the repository, check out the tag and build it with Docker/Podman: ```bash 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](https://measurements.buildernet.org/) one: ```bash 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](https://collective.flashbots.net/c/buildernet/31) and the [BuilderNet Telegram group](https://t.me/buildernet_general)!