Who should write the rules of block building? BuilderNet as a policy test case

Every transaction that a public blockchain executes must be placed into a "block" — a batch of transactions the network processes together. Someone must decide which eligible transactions are included and in what order. That ordering power, when designed well, can be used to increase efficiency and reduce predation and predictable losses for users. But it can also be used to realize value from other participants or to censor disfavoured transactions. On Ethereum, specialist operators called "block builders" assemble most blocks through competitive auctions, and a small number of them produce the vast majority of blocks. The question of who writes the rules that govern their behaviour is both technically intricate and a live policy issue.

In this note I examine one prominent technical answer: Flashbots BuilderNet, a network of block builders that runs open-source software inside trusted execution environments (TEEs).[1]

I apply my earlier efficiency-focused analysis of MEV[2] — the value available to whoever controls transaction ordering within a block — to BuilderNet. I unpack what the "rules" of block construction are in practice, who writes them today, and whether having regulators write those rules would be practicable or desirable.

My conclusion is that attestable code can reduce opacity and constrain some forms of builder discretion when it sits inside a wider assurance system covering hardware, custody, networking, key management, updates, and incident response. Regulators should ordinarily avoid prescribing transaction-ordering algorithms. More proportionate duties concern honesty, disclosure, conflicts, protection of private order flow, and operational accountability — especially at the wallet, front-end, routing, and broadcasting layers that interface directly with users.

In the framework I have used previously, MEV can be disaggregated into "Monarch" EV (value from the power to order transactions, which may or may not be harmful), "Mafia" EV (value realized through information asymmetries, for example exploiting knowledge of pending transactions to front-run them), and "Moloch" EV (value destroyed through coordination waste, for example bidding wars that burn resources without benefiting users).[3]

BuilderNet is designed primarily to address the second and third of these. To the extent that it keeps transaction data confidential from operators, it can reduce opportunities for "Mafia" EV; to the extent that its nodes coordinate rather than duplicate bids against one another, it can reduce "Moloch" EV. It does not eliminate "Monarch" EV, and there is no general reason to think it should: the power to order transactions is intrinsic to producing blocks. The policy question is therefore not simply who orders transactions, but who can set, verify, update, and contest the rules under which ordering occurs.

A note on key technical concepts

For readers less familiar with blockchain infrastructure, I'll start by introducing several technical concepts.

Proposer-Builder Separation (PBS) is the de facto architecture by which most Ethereum blocks are produced today. Validators (sometimes called "proposers") propose blocks to the network but usually do not construct the block contents themselves. They outsource that task to specialist block builders that compete in an auction. Builders assemble a block and bid for the right to have it included; the validator selects a bid. Building is computationally demanding and benefits from access to private transaction flow, capabilities that have concentrated among a small number of professional builders. Builder production remains highly concentrated, although the ranking changes over time. During the seven days ending 23 July 2026, Relayscan attributed approximately 51% of captured MEV-Boost payloads to Titan, 23% to Quasar, 11% to BuilderNet, and 10% to Eureka.[4]

MEV-Boost is the off-chain software used to implement this de facto PBS arrangement. Intermediaries called relays mediate between builders and validators by receiving bids and payloads, checking them, and forwarding selected information. MEV-Boost is not part of Ethereum's core protocol.

Trusted Execution Environments (TEEs) are hardware-backed isolation mechanisms. A TEE creates an enclave or confidential virtual machine in which software can run with protections against observation or modification by the host. The hardware can produce attestation evidence identifying a measured workload and configuration. That evidence proves a narrower proposition than the trustworthiness of the whole service. Assurance also depends on the hardware and attestation provider, physical custody of the machine, host and firmware integrity, delivery of traffic to the enclave, key and secret provisioning, and timely update and revocation.[5] BuilderNet uses Intel TDX (Trust Domain Extensions), which isolates entire virtual machines. The intended guarantee is that users and counterparties can verify the measured builder workload and its declared configuration. Attestation does not prove that the code is correct, that every transaction reaches it, or that no component outside the measured environment can fail.

Enshrined PBS (ePBS) and FOCIL (Fork-Choice Enforced Inclusion Lists) are protocol-level proposals planned for upcoming Ethereum upgrades. ePBS would move trusted builder-proposer payment and payload-commitment functions into Ethereum's core protocol, removing the need to trust an external relay for those functions. It would not necessarily eliminate relay-like auction, aggregation, or information services.[6] FOCIL would let validator committees enforce transaction-inclusion lists, providing a protocol-level censorship-resistance mechanism. I discuss both in dedicated analyses on GoodCrypto: ePBS and legally credible neutrality and FOCIL and legally credible neutrality.[7] They matter here because they may relocate some control from private infrastructure to the protocol, without making intermediary infrastructure disappear.

A useful conceptual aid is Reid Yager's decomposition of the non-custodial wallet and DeFi-interface stack into three functional layers: signing, routing, and broadcasting.[8] The signing layer manages keys and produces signed transactions. The routing layer decides where to send them. The broadcasting layer submits them into the on-chain stack. Yager argues that much wallet monetisation — including priority-fee refunds, back-run auctions, and RPC-selection rents — concentrates at the routing and broadcasting layers rather than the signing layer. That decomposition is also a useful legal map: responsibility should track what an actor does, not merely the label attached to it.

What are the "rules" in BuilderNet?

BuilderNet is best understood as a network of cooperating builder instances running open-source software inside TEEs. It encrypts order flow for processing inside the enclave, attests the code and configuration that process that flow, shares order flow among peer builders, and returns a portion of realized value to order-flow providers according to a published refund rule.[9]

In practice, the "rules" comprise several layers:

  1. Consensus-level constraints. Ethereum's protocol determines what a valid block is and how blocks are finalized. It limits how much computation can be included in a block through the gas limit, but it does not yet comprehensively determine which valid transactions must be included or in what order. ePBS and FOCIL would add protocol constraints around builder-proposer commitments and transaction inclusion.

  2. BuilderNet node policy. Operators must boot an image that matches published allowed measurements or they are not recognized as BuilderNet peers.[10] Order flow is encrypted in transit and processed inside the enclave. A sender can verify a cryptographic binding between remote-attestation evidence and the authenticated endpoint or communication channel, but the precise protocol has evolved and involves trade-offs among freshness, caching, certificate rotation, revocation, security, and performance.[11][12] The algorithm that selects and orders transactions forms part of the measured builder image. That algorithm may itself recognize declared priority classes; attestation can show compliance with the declared policy, not neutrality between every transaction.

    BuilderNet is therefore better understood as replacing some opaque operator discretion with verifiable constraints and disclosed dependencies, not as eliminating trust. Attestation constrains what may happen inside the measured environment, but it does not ensure that the host delivers every transaction to it, establish physical custody, or validate every provider-specific component in the assurance chain.[13]

    Flashbots has acknowledged that a host can censor a block builder by controlling which network traffic reaches the enclave.[14] An operator can filter, delay, or drop traffic before it reaches the measured workload. A multi-operator design can mitigate that risk when order flow can reach genuinely independent routes, but operator count alone does not establish independence or confidentiality.

  3. Application-specific priority rules. BuilderNet's priority-update mechanism allows an authorised smart contract-related update to be placed ahead of other transactions accessing the same state.[15] The key issue is who decides: an application or smart contract owner can supply an ordering preference that the builder enforces. Attestation can make compliance with that preference verifiable, but it does not make the preference substantively neutral. Relevant disclosure questions include which smart contracts or state domains receive priority treatment, who may authorise an updater, how credentials are granted or revoked, and whether users can discover the rule before submitting a transaction.

  4. Bidding and coordination rules vis-à-vis MEV-Boost relays. BuilderNet nodes coordinate bids so that they do not pointlessly outbid one another. The aim is to compete against external builders and return part of the resulting margin through refunds.[16]

  5. The refund rule. BuilderNet computes refunds for eligible transactions and bundles that land in its blocks and distributes them on a periodic cadence, with a public archive intended to make the process auditable.[17] Cumulative refunds crossed the $1 million mark during 2025, and a delayed-refunds mode introduced in late 2025 lets users accumulate refunds asynchronously rather than receive per-block refund transactions.[18]

  6. Access and bootstrapping rules. Flashbots' BuilderHub manages identity, secret provisioning, peer discovery, and the Redistribution Archive during the transition to permissionlessness.[19] BuilderNet nevertheless remains permissioned. Its public documentation identifies three operators — Flashbots, Beaverbuild, and Nethermind — while its allowed measurements include Azure and GCP TDX configurations.[20] The public material does not show how production is distributed across operators, clouds, regions, or custody arrangements.

  7. Update, revocation, and incident rules. The assurance system also needs rules for patching, retiring unsafe measurements, revoking credentials, pausing confidential order flow, notifying counterparties, and resuming service. An April 2026 Flashbox incident — not a BuilderNet incident — illustrates the lifecycle by analogy: Flashbots paused order-flow streaming, patched and rebuilt affected images, and resumed after migration.[21] An attestation regime is only as credible as its ability to withdraw trust when the attested workload or its base image becomes unsafe.

Who writes those rules today?

There are at least six overlapping categories of rule-writers.

First, the protocol community adopts the rules of the core Ethereum protocol. BuilderNet cannot opt out of those rules without ceasing to build valid Ethereum blocks. If ePBS and FOCIL are adopted, they will reshape the environment in which BuilderNet operates by reducing trusted relay functions and adding protocol-enforced inclusion constraints.[22]

Second, BuilderNet's maintainers write the enclave code, publish allowed measurements, and decide which binaries count as compliant nodes. This includes code governing order-flow encryption, peer sharing, multiplexing, bidding, transaction selection, ordering, and refund calculation. Open source and reproducible builds let third parties compare source and build artifacts with published measurements, subject to the limits of the surrounding attestation chain.[23]

Third, node operators and the hardware, cloud, attestation, and custody providers on which they rely co-author the operational trust model. Operators control hosts, networking, deployment, and incident response. The attestation chain ultimately depends on hardware roots of trust and provider infrastructure. The October 2025 TEE.Fail disclosure, which demonstrated physical attacks capable of forging attestations on Intel TDX and AMD SEV systems, including a non-production BuilderNet laboratory instance, underscored the materiality of this dependency.[24]

Fourth, order-flow providers, wallets, front ends, and users influence the rules by choosing routes and parameters. Flashbots Protect, for example, routes order flow to BuilderNet and lets users set refund destinations and sharing percentages.[25] A wallet's routing decision affects which builders compete for a transaction, what information is revealed, and how any surplus is divided. User choice matters only to the extent that the interface exposes meaningful options and explains them.

Fifth, smart contract maintainers, together with authorised priority updaters, can write a limited class of ordering rules. As mentioned above, BuilderNet’s priority-update mechanism enables placing some transactions ahead of others - as long as the transactions are aiming to touch the same state (e.g. call on the same smart contract). [26]

Sixth, relays, proposers, auction or commitment providers, and rollup operators write contextual rules. Relays determine bid-delivery and validation policies; proposers choose which relays or channels to use and which bid to select; rollups define sequencing and preconfirmation rules. ePBS may remove the relay's trusted payment-and-payload-escrow role, but relay-like services may persist, and new commitment services may create their own liveness, censorship, and concentration risks.[27][28]

Multiple rule-writers can limit one actor's unilateral control, but they do not necessarily create substitutes or competitive decentralisation. At least four dimensions should be assessed separately: diversity of operators within a network, competition among builder networks, access to valuable order flow, and diversity of the ordering and refund policies users can choose. BuilderNet can improve the first dimension while leaving the others concentrated.[29] Geographic or cloud dispersion is likewise not a complete proxy for welfare or access. Theoretical work suggests that uncoordinated infrastructure may cluster around the same privately valuable sources rather than provide balanced coverage.[30]

A short regulatory bridge: interfaces and routing

Two 2026 developments reinforce the practical importance of the routing and interface layers. US SEC staff described a nonbinding, fact-specific position for certain interfaces dealing with crypto asset securities, conditioned in part on pre-disclosed and independently verifiable software parameters, objective route assessment, conflict controls, and protection of users' trading information.[31] In the United Kingdom, FCA CP26/13 proposes that an app or website giving users the means to place qualifying-cryptoasset orders may be arranging transactions, with no general exclusion merely because the service constitutes technical infrastructure.[32]

Neither instrument directly regulates block construction, and neither states final law: the SEC document is a staff position, while the FCA document is a consultation. Their relevance here is narrower. Interface regulation is likely to turn on function, discretion, compensation, conflicts, and user-facing claims. That supports targeted duties at the routing and broadcasting layers; it does not establish a case for prescribing builder-level ordering outcomes.

What would "regulators write the rules of block construction" mean?

The headline question could mean at least four very different things.

(A) Regulate ordering outcomes: "never sandwich", "include transaction X by slot Y", or "respect fairness algorithm Z". This would be the most intrusive route. It would require regulators to select a technical rule that must be expressed in code to be meaningful, and it is not obvious which legal hook would support a general mandate for builders that do not serve end-clients. If ePBS and FOCIL address some concerns at protocol level — especially trusted settlement and transaction inclusion — builder-level mandates may also be redundant for those concerns.[33] A theoretical model of block-building auctions supplies a further caution. The validator's share of MEV can depend materially on the thickness of searcher competition, so an ordering rule does not by itself determine who captures value.[34]

The intuitive case for option (A) often runs by analogy to regulated equity markets. NASDAQ applies price-time priority through a deterministic matching engine. Ethereum builders instead solve a constrained optimisation problem over transactions and bundles whose execution changes shared state. Fee-based priority creates a superficial parallel, but the analogy stops short of identity.[35] An Ethereum block has a gas limit; transactions can conflict or revert; and builders simulate arbitrary code against a changing state. NASDAQ broker-dealers also owe customers best-execution duties under FINRA Rule 5310, while a bare builder does not obviously occupy the same client-facing role. The closer legal analogue lies at the wallet, front-end, and execution-service layers.

Optimal block building is computationally difficult. It combines a capacity constraint resembling the Knapsack Problem with transaction conflicts that can be represented through graph problems, so production builders use multi-stage heuristics rather than a single deterministic priority rule.[36] A regulatory rule that replaces optimisation with one crude ordering principle could reduce packing efficiency precisely when congestion and state conflicts make intelligent construction most valuable.

Formal work suggests that strict time priority does not remove front-running and can induce a socially wasteful latency race.[37]

None of this rules out narrower, pattern-based prohibitions ("no sandwiching by the same beneficiary on front and back transactions"), which would operate as constraints inside the optimisation rather than replace it. It does, however, suggest that the most intrusive readings of (A), in which builder discretion is replaced wholesale with a mandated ordering algorithm, would be technically poor instruments even before the legal-hook and jurisdictional questions arise.

(B) Regulate process duties: require verifiable code paths, reproducible builds, disclosed dependencies, auditable refund procedures, and credible update and incident processes as conditions for making particular claims or serving users in a jurisdiction. Law would enforce verifiability and accountability rather than dictate the substance of block order. This is more practicable than an ordering mandate, but still faces jurisdiction-shopping and extraterritoriality constraints.

(C) Regulate adjacent actors: impose best-execution-like, conflict, and disclosure duties on wallet providers, DEX front ends, trading apps, and — where they exercise meaningful routing or broadcasting discretion — RPCs and other interfaces that control users' order flow. That is a promising legal vector because those actors have recognisable service relationships with users and communicate the relevant privacy, routing, and refund claims.[38]

(D) Rely on market-abuse frameworks: in the EU, MiCA Title VI applies its core prohibitions to "any person" engaging in specified conduct concerning crypto-assets admitted to trading. It also places detection and reporting duties on trading platforms and persons professionally arranging or executing transactions.[39] Those provisions could reach some block-building or sequencing conduct when the facts amount to manipulation, but the conclusion should follow from function and evidence, not from the label "MEV" alone.

My own prior work is a warning against (A) and supports cautious openness to (B) and (C), with (D) reserved for conduct that fits the legal elements and is supported by evidence of market or user harm.[40]

Practicability: could regulators meaningfully set the rules?

Technical practicability. With TEEs and attestation, a regulator could in principle condition a legal benefit or permission on running binaries that implement specified constraints, because the allowed-measurement list is a natural verification point. But if peer compatibility requires BuilderNet operators to run a common image, a jurisdiction-specific binary could force foreign peers either to adopt the same rule or to fragment the network. Order-flow sharing creates a similar problem. Regulation could therefore reduce the geographical or organisational diversity it seeks to promote and contribute to jurisdictional clustering.[41]

Legal practicability. Under frameworks such as MiCA, most positive duties attach to defined actors such as crypto-asset service providers and financial institutions. A block builder may fall outside those categories unless it also operates a trading platform or provides another regulated service to clients. The market-abuse prohibitions are broader because they can apply to any person, but that does not turn every ordering choice into manipulation.[42]

Governance practicability. BuilderNet remains in a bootstrapping phase. BuilderHub manages identities and secrets and maintains the Redistribution Archive, with a stated plan to decentralise. In this phase, "who writes the rules" includes whoever controls admission, measurements, secrets, and emergency updates. Regulatory hard-coding risks freezing the design, discouraging independent operators, and ossifying dependence on a particular vendor or enclave technology.[43]

Desirability: should regulators write the rules?

On the efficiency criterion used in my earlier framework, the principal policy targets are information asymmetries and wasteful coordination races, not the mere existence of block-ordering discretion.[44] BuilderNet is designed to reduce "Mafia" EV by processing private order flow inside attested environments and to reduce "Moloch" EV by coordinating its own nodes and redistributing some surplus through a declared refund rule.

BuilderNet's public refund mechanism demonstrates that redistribution occurs and makes at least part of it auditable. The available evidence does not establish that BuilderNet consistently retains lower margins than rival builders, improves users' execution overall, or makes the builder market more competitive. Live profitability estimates are sensitive to the observation window and may not capture off-chain payments. Recent empirical work also suggests that BuilderNet may have absorbed an incumbent's order-flow position without restoring competition between independent builders.[45][46]

Market efficiency should remain the central test for legal intervention. We still lack conclusive empirical answers on net efficiency effects of particular blockchain trading strategies. What we do have are strong prima facie reasons to think that attestable private order-flow handling, fewer duplicate bids, and predictable refunds improve execution quality for many users.[47]

One recent analysis illustrates why harm metrics matter. Data Always identified a thirty-day window in which three edge-case, low-liquidity sandwich attacks accounted for roughly 99% of reported sandwich-bot profits and 78% of reported user losses, while estimated economic profit was close to zero.[48] That observation does not establish that market-wide sandwich harm is overstated, but it shows that legal classification should not rely mechanically on public dashboards. At the same time, private routing is not a complete answer. A separate Data Always technical thread identified an evasive sandwich bot said to attack approximately 1,500 users per day, many through private mempools.[49] Those observations strengthen the case for routing-layer disclosure duties (option C) over builder-layer ordering mandates (option A).

Protocol constraints and deconcentration are generally more robust tools for censorship resilience than a legal ordering mandate directed at one builder. TEE-Boost and ePBS aim to reduce trusted relay functions, while FOCIL would turn some inclusion guarantees into protocol constraints.[50] Those mechanisms do not remove all intermediaries or all discretion, but they change where trust and control reside.

Attestation does not guarantee that code is correct, but it can show that a measured workload is running. Attestation also can't prevent a host from selectively dropping or delaying traffic before the workload receives it. Operator diversity can improve availability, integrity, and resistance to coordinated censorship, yet each independently operated environment that receives confidential order flow inside its enclave adds another confidentiality dependency. The relevant dimensions therefore include ownership, cloud and region, hardware and attestation chain, custody, key and provisioning control, least privilege, order-flow access, revocation, and incident response — not operator count alone.[51]

Blob transactions illustrate another limit. Blob sidecars impose propagation costs and can increase reorganisation risk, while current inclusion-list designs do not necessarily cover blobs.[52] A TEE can make the builder's declared blob policy more verifiable, but it cannot by itself prevent host-level filtering or profit-driven blob deprioritisation. This is a reason to preserve technical adaptability and to evaluate outcomes, not a reason to assume that an attested profit-maximising policy is neutral.

Finally, writing ordering rules for one chain misses the cross-chain and layer-two reality. Solana's Jito Block Assembly Marketplace (BAM) draws on a TEE-based design but adapts it to Solana's continuous production model and supports application-controlled execution.[53] Cosmos app-chains experiment with other builder and auction structures, while Flashbots' Flashblocks have moved TEE-based block-building and preconfirmation design into the layer-two setting.[54] A mandate aimed only at Ethereum L1 builders could displace activity to layers where the regulator has less visibility and where ordering is governed differently.

A note on exclusive order flow and what it does and does not show

A recurring criticism of BuilderNet, articulated by EigenPhi and examined empirically by Pahari and Canidio, is that exclusive order flow has not been eliminated but restructured.[55] In their sample, Pahari and Canidio find that 77–84% of fees in winning Ethereum blocks come from exclusive transactions, much of it structurally driven by timing, searcher bundles submitted to one builder, or latency rather than durable loyalty. BuilderNet's internal sharing can reduce exclusivity among its own nodes while leaving exclusivity between builder networks.

Structural exclusivity is not necessarily bad or welfare-reducing. It may arise without deception, breach of trust, or misuse of confidential information. It can nevertheless be a market-structure concern when privileged access to flow, scale economies, and switching costs make entry materially harder. A recent preprint using data through August 2025 argues that BuilderNet largely absorbed Beaverbuild's order flow and market share rather than restoring competition, and that its TEE requirement and cooperative structure may themselves raise entry barriers.[56] That is not a reason to prescribe an ordering algorithm, but it is a reason not to treat operator diversity as a sufficient response to builder concentration.

Policy approach that fits BuilderNet (and other chains)

If the goal is to reduce situations like breaches of trust, misuse of private information, and needless coordination waste, then regulators should prefer thin legal rules that support robust code-level guarantees.

  1. Put duties where routing discretion and user relationships sit. User-facing services that choose transaction routing or broadcasting channels should disclose material routing criteria, compensation, refund options, conflicts, priority treatment, and the limits of any privacy or MEV-protection claim. Duties should track function and discretion rather than software labels.[57]

  2. Use truth-based enforcement. Fraud and misrepresentation are squarely within existing law. If a router claims that it does not sell or exploit private order flow but does so, that can be addressed without inventing a general "MEV unfairness" offence. The same is true of misleading claims about refunds, neutrality, attestation, or censorship resistance.[58]

  3. Offer a rebuttable, process-based safe harbour for verifiable claims. A provider that claims to process private order flow under attested rules should: (i) publish reproducible code, current measurements, and the scope of the attested workload; (ii) cryptographically bind attestation evidence to the relevant endpoint or channel and disclose freshness, caching, certificate rotation, and revocation; (iii) disclose hardware, cloud, custody, operator, key, and secret-provisioning dependencies; (iv) publish priority classes, refund procedures, and material conflicts; and (v) maintain auditable patching, emergency suspension, incident-notice, revocation, recovery, and post-incident procedures.[59][60][61] The safe harbour should reward verifiable process.

  4. Apply market-abuse duties functionally. Under MiCA, the clearest surveillance and reporting duties attach to trading platforms and persons professionally arranging or executing transactions, while the core prohibitions can reach any person. Enforcement should focus on conduct that satisfies the legal elements and causes cognisable harm, regardless of whether it occurs in a builder, router, sequencer, application, or cross-venue strategy. Block-ordering mechanics should not become a compliance rulebook merely because they are technically visible.[62]

  5. Support credible neutrality by reducing choke points. Protocol mechanisms such as ePBS and FOCIL can move some guarantees into consensus and reduce the trusted functions of private intermediaries. Builder networks should also be assessed across factors like ownership, cloud and hardware dependencies, admission, and order-flow access.[63][64]

Conclusion: who should write the rules?

On a network like Ethereum, there is no single rule-writer for transaction routing, as well as its inclusion and ordering in a block. What regulators can do is write meta-rules that make deception costly, verifiable commitments valuable, and infrastructure contestable.

TEE attestation can show compliance with a disclosed rule, but it cannot establish that the rule is fair, efficient, or legally sufficient. On the present evidence, a general legally mandated ordering algorithm are not justified. The better strategy is to demand truthful and testable claims, credible update and incident processes, functional responsibility at user-facing layers, and scrutiny of concentration wherever control over order flow or rule-setting accumulates.

  1. BuilderNet, What is BuilderNet; Flashbots, Introducing BuilderNet (26 November 2024). ↩︎

  2. M Barczentewicz, MEV on Ethereum: A Policy Analysis (ICLE White Paper, 23 January 2023), especially 15–24 and 26–28. ↩︎

  3. The "Monarch/Mafia/Moloch" framework originates in Flashbots research and is analysed from a policy perspective in Barczentewicz, MEV on Ethereum: A Policy Analysis, 14–15. ↩︎

  4. Relayscan, MEV-Boost Relay & Builder Stats (seven-day window from 16 to 23 July 2026) accessed 23 July 2026. Relayscan attributes payloads using configured relay data APIs and builder extra_data labels; see Flashbots, relayscan accessed 23 July 2026. The figures are a short-window snapshot, not a longitudinal estimate. ↩︎

  5. Frieder Erdmann, Physical integrity, attestation, and the state of permissionless TEEs (Ethereum Research, 26 May 2026), especially sections 1, 3 and 7. The source is a technically detailed research post, not a peer-reviewed security audit. ↩︎

  6. Christoph Schlegel, 0xSybil and Minghao Pan, Trustless payments and relays (Flashbots Collective, 8 June 2026) accessed 23 July 2026. ↩︎

  7. M Barczentewicz, ePBS on Ethereum and legally credible neutrality (GoodCrypto); M Barczentewicz, FOCIL on Ethereum and legally credible neutrality (GoodCrypto). ↩︎

  8. Reid Yager, The Functional Layers of Non-Custodial Wallets and DeFi Interfaces (Flashbots Collective, 14 April 2026). Disclosure: Yager (Flashbots) gave feedback on an earlier draft of this paper; that feedback informs the actor map but did not extend to the regulatory analysis. ↩︎

  9. BuilderNet, What is BuilderNet; Flashbots, Introducing BuilderNet (26 November 2024). ↩︎

  10. BuilderNet, Downloads and measurements. ↩︎

  11. BuilderNet, How to send orderflow; Flashbots Collective, Questions about BuilderNet block-building, refund rule, and TEE guarantees; Flashbots Collective, Moving Away from aTLS. ↩︎

  12. peg, Attested TLS Protocol Redesign for Scale and Performance (Flashbots Collective, 25 June 2026), especially the benchmark discussion and conclusion. This is first-party engineering evidence rather than an independent security assessment. ↩︎

  13. Erdmann (n 5). ↩︎

  14. Flashbots, Network-level Censorship: Understanding the Problem (Flashbots Collective, March 2025). ↩︎

  15. BuilderNet, API Reference: Priority updates accessed 23 July 2026; Quintus, Vitaliy Drogan and Tymur Khrushchov, ERC-8324: Priority Update Registry (PUR) (Fellowship of Ethereum Magicians, 3 July 2026) accessed 23 July 2026. The latter is a draft proposal, not a final standard. ↩︎

  16. Flashbots Collective, Questions about BuilderNet block-building, refund rule, and TEE guarantees. ↩︎

  17. Flashbots, Gas Fee Refunds; BuilderNet, Flashbots infrastructure. ↩︎

  18. Flashbots, BuilderNet v1.6 (2 December 2025); Flashbots, BuilderNet dashboard. ↩︎

  19. BuilderNet, Flashbots infrastructure. ↩︎

  20. BuilderNet, Public identification; BuilderNet, Allowed TEE measurements, both accessed 23 July 2026. The measurement list establishes permitted configurations, not their actual use or the distribution of production among them. ↩︎

  21. Moe, Flashbox Incident Report: April 30, 2026 (Flashbots Collective, 30 April 2026). The report concerns Flashbox, not BuilderNet, and is used only as analogous first-party operational evidence. ↩︎

  22. Barczentewicz, ePBS on Ethereum and legally credible neutrality; Barczentewicz, FOCIL on Ethereum and legally credible neutrality. ↩︎

  23. BuilderNet, BuilderNet v1.4 — reproducible TDX image builds. ↩︎

  24. TEE.Fail (Georgia Tech and Purdue, October 2025); Flashbots, Why TEE.Fail is Bullish for BuilderNet: Hardening the Path to Permissionless Blockbuilding. ↩︎

  25. Flashbots, MEV Protection Overview; Flashbots, Protect settings guide. ↩︎

  26. BuilderNet, API Reference: Priority updates (n 15); Quintus, Drogan and Khrushchov, ERC-8324 (n 15). ↩︎

  27. Schlegel, 0xSybil and Pan (n 6). ↩︎

  28. Flashbots, TEE-Boost; Flashbots, Introducing Rollup-Boost — launching on Unichain; Uniswap Labs, Live on Unichain: fair transaction ordering and MEV protection; Optimism, Flashblocks: Deep Dive — 250ms preconfirmations on OP Mainnet. ↩︎

  29. Ao Zhang and others, Order Flow Exclusivity and Value Extraction Mechanisms: An Analysis of Ethereum Builder Centralization (arXiv:2605.04471, 6 May 2026) 1–2, 11–13. The study analyses transactions from September 2023 to August 2025 and is a preprint; its classifications and causal conclusions should be treated accordingly. ↩︎

  30. Burak Öz and others, The Price of Decentralization in Block Building (arXiv:2606.01874, 1 June 2026) 18–19. This is theoretical and simulation-based work, not an empirical map of BuilderNet's current deployment. ↩︎

  31. US Securities and Exchange Commission, Division of Trading and Markets, Staff Statement Regarding Broker-Dealer Registration of Certain User Interfaces Utilized to Prepare Transactions in Crypto Asset Securities (13 April 2026) 3–5, 8 n 13, accessed 23 July 2026. The statement is nonbinding, fact-specific, and does not create Commission-level law. ↩︎

  32. Financial Conduct Authority, CP26/13: Cryptoasset Perimeter Guidance (April 2026) para 2.11 and proposed PERG 19.8.3(6)–(9), accessed 23 July 2026. This is consultation material, not final guidance. ↩︎

  33. Barczentewicz, FOCIL on Ethereum and legally credible neutrality. ↩︎

  34. Akaki Mamageishvili, Christoph Schlegel, Benny Sudakov and Danning Sui, Searcher Competition in Block Building (arXiv:2407.07474, revised September 2025). ↩︎

  35. Nasdaq Market Center Systems Description (SEC filing); Burak Öz and others, Who Wins Ethereum Block Building Auctions and Why? (AFT 2024); Phil Daian and others, Flash Boys 2.0 (IEEE S&P 2020). ↩︎

  36. Block Building is not just knapsack! (Ethereum Research); Mohan and Khezr, Blockchains, MEV and the knapsack problem (arXiv, March 2024); Flashbots, New Block Building Algorithms; Flashbots, Parallel Block Building. ↩︎

  37. Flashbots, Can FCFS-Based Transaction Ordering Prevent Front-Running?; Daniel J Ferreira and David C Parkes, Buying Time: Latency Racing vs Bidding in Transaction Ordering (AFT 2023); Eric Budish, Peter Cramton and John Shim, ‘The High-Frequency Trading Arms Race: Frequent Batch Auctions as a Market Design Response’ (2015) 130 Quarterly Journal of Economics 1547. ↩︎

  38. Barczentewicz, MEV on Ethereum: A Policy Analysis, 21–24. ↩︎

  39. M Barczentewicz and A de Gândara Gomes, Crypto-Asset Market Abuse Under EU MiCA (2024) European Journal of Risk Regulation; Regulation (EU) 2023/1114 on markets in crypto-assets, Title VI, arts 86–94. ↩︎

  40. Barczentewicz, MEV on Ethereum: A Policy Analysis, 26–28. ↩︎

  41. Sen Yang, Burak Öz, Fei Wu and Fan Zhang, Geographical Centralization Resilience in Ethereum's Block-Building Paradigms (arXiv:2509.21475, updated 2026); Fei Wu, Prisoners of Geography 2.0: The Theory Behind Where Validators Want to Run (Flashbots Collective, April 2026). ↩︎

  42. Barczentewicz and de Gândara Gomes, Crypto-Asset Market Abuse Under EU MiCA. ↩︎

  43. BuilderNet, Flashbots infrastructure; Flashbots, TEE-Boost. ↩︎

  44. Barczentewicz, MEV on Ethereum: A Policy Analysis, 14–15. ↩︎

  45. BuilderNet, Refunds; Relayscan, MEV-Boost Builder Profitability (seven-day window ending 23 July 2026), both accessed 23 July 2026. Relayscan cautions that its balance-difference method may not capture alternative payment addresses, off-chain order-flow payments, or the interaction between searching profits and builder funds. ↩︎

  46. Zhang and others (n 29). ↩︎

  47. Barczentewicz, MEV on Ethereum: A Policy Analysis, 15–28. ↩︎

  48. Data Always, When Frontrunning is Alchemy (Flashbots Collective, 8 April 2026). The conclusion in the text is expressly limited to the reported observation window. ↩︎

  49. Data Always, Meet 0x841: a fresh sandwich bot lurking in the dark forest (X, 24 April 2026). This is a technical social-media thread rather than peer-reviewed empirical evidence. ↩︎

  50. Barczentewicz, ePBS on Ethereum and legally credible neutrality; Barczentewicz, FOCIL on Ethereum and legally credible neutrality; M Barczentewicz, Legally Credible Neutrality (SSRN, July 2024). ↩︎

  51. Erdmann (n 5). ↩︎

  52. A First Look at Ethereum Blob Revolution (arXiv:2411.03892); Blocknative, June 20th Blob Contention Event Retrospective; Ethereum Foundation, Protocol Update 002 (22 August 2025). ↩︎

  53. Jito, Introducing BAM; Jito, BAM Documentation. ↩︎

  54. Optimism and Flashbots, Optimism Partners with Flashbots (21 August 2025). ↩︎

  55. EigenPhi, BuilderNet and the Return of Exclusive Orderflow (July 2025); Pravesh Pahari and Andrea Canidio, How Exclusive are Ethereum Transactions? (arXiv:2509.16052, September 2025). ↩︎

  56. Zhang and others (n 29). ↩︎

  57. BuilderNet, BuilderNet v1.4; Flashbots, Protect settings guide; SEC Division of Trading and Markets, Staff Statement Regarding Broker-Dealer Registration of Certain User Interfaces; FCA, CP26/13. ↩︎

  58. Barczentewicz, MEV on Ethereum: A Policy Analysis, IV.B and V.A–B; M Barczentewicz, DEX self-regulation (GoodCrypto, 4 September 2024). ↩︎

  59. Erdmann (n 5). ↩︎

  60. peg (n 12). ↩︎

  61. Moe (n 21). ↩︎

  62. Barczentewicz and de Gândara Gomes, Crypto-Asset Market Abuse Under EU MiCA; Regulation (EU) 2023/1114, Title VI, especially arts 86 and 92. ↩︎

  63. Flashbots, TEE-Boost; Burak Öz and others, Who Wins Ethereum Block Building Auctions and Why? (AFT 2024); Barczentewicz, Legally Credible Neutrality. ↩︎

  64. Zhang and others (n 29). ↩︎