There are still two centralized components:

• BuilderHub:
  • Handles node identity, key distribution, and peer discovery
  • Nodes boot with TEE attestation and request configuration from BuilderHub
  • BuilderHub verifies measurement + IP allowlist, then issues sensitive material such as coinbase keys and relay signing keys
• Redistribution Archive:
  • Stores orderflow, bids, and block results
  • Used for refund calculation and auditing
  • At a 50% win rate, storage is roughly 30GB/day

BuilderNet nodes are not Docker containers. They run as full Linux TDX VM images built with Yocto (in .vhd format), on TDX-capable infrastructure such as Azure TDX Confidential VM or Intel 4th Gen Xeon Scalable+ hardware.

Flow:

1. Start system services (network, filesystem, cron)
2. Start time sync via NTP daemon (improved after v1.2)
3. Start cvm-reverse-proxy for TEE attestation
4. Pull secrets and config from BuilderHub
5. Mount encrypted disk
6. Start Operator API (system-api on port 3535)
7. Start observability services (Prometheus/Fluentbit)
8. Start Lighthouse (consensus client)
9. Run Reth snapshot sync
10. Start Reth (execution client)
11. Start rbuilder, bidding service, and HAProxy
12. Start orderflow-proxy and begin receiving orderflow

The network is currently permissioned.

Flow:

1. Submit application
2. Flashbots review
3. Allowlist approval
4. Bring node online

Roadmap direction is permissionless, but that transition is not complete yet.

The key component is orderflow-proxy, running in two places:

• Flashbots infrastructure side (aggregation)
• Inside each TEE node (receive, broadcast, archive, forward)

• Transactions and bundles forwarded by orderflow-proxy
• MEV-Share hints
• Local Reth mempool

1. Simulation and validity checks (including gas constraints)
2. Bundle merge + ordering for value maximization
3. MEV extraction (backrun, arbitrage, etc.)
4. Compliance filtering based on operator blocklist
5. Gas optimization by transaction ordering

Packaging phase:

1. Apply withdrawals
2. Run post-block calls
3. Compute state root hash
4. Package full block

Submission phase:

1. Private bidding service computes bid price
2. Submit to multiple MEV-Boost relays
3. Write BuilderNet (operator_id) into extra_data for on-chain attribution

v1.3 highlights:

• Regional relay-only submission (about 50ms cross-region savings)
• Bundle cancellation support
• ~2x p99 end-to-end latency improvement

• Give users, wallets, apps, and searchers a more transparent MEV path
• Reduce per-transaction net cost to land on chain
• Keep network operations sustainable

1. BuilderNet competes in MEV-Boost auctions
2. If a winning block is bid below its true value, the gap becomes distributable remainder
3. For landed transactions from eth_sendBundle, mev_sendBundle, and eth_sendPrivateTransaction, BuilderNet estimates contribution by replay/simulation
4. Remainder is distributed proportionally to contribution

Note:

• This is different from the built-in refund field in eth_sendBundle

eth_sendBundle refund fields:

refundPercent   // Integer: 1-99
refundRecipient // String: refund recipient address

To prevent split-identity bundle strategies from extracting extra refunds, BuilderNet adds a joint marginal contribution constraint.

Given:

• v(T) = 10 ETH
• c = 7 ETH
• mu_A = 1.5 ETH
• mu_B = 1 ETH

Computation:

1. Remainder = v(T) - c = 3 ETH
2. sum(mu_j) = 1.5 + 1 = 2.5 ETH
3. Distributable = min(3, 2.5) = 2.5 ETH
4. Refunds:
   • phi_A = (1.5 / 2.5) * 2.5 = 1.5 ETH
   • phi_B = (1 / 2.5) * 2.5 = 1 ETH

If a participant's marginal contribution equals payment and remainder is sufficient, net payment can approach zero.

Tracking dashboards:

• BuilderNet Dashboard
• Flashbots Protect Dashboard
• BuilderNet APIs (subject to available endpoints)

Refund destination example:

Expected effects:

• Validators: limited short-term impact, possible long-term value shift toward orderflow providers
• Operators: future rules are expected to account for operating costs

Use attested-get:

go install github.com/flashbots/cvm-reverse-proxy/cmd/attested-get
attested-get \
  --addr=https://rpc.buildernet.org:7936/cert \
  --expected-measurements=https://measurements.buildernet.org \
  --out-response=builder-cert.pem

This validates TEE measurement during TLS handshake and exports a certificate bound to the VM image.

Each node exposes system-api on port 3535, typically behind HTTP Basic Auth + TLS.

# Restart rbuilder
curl --insecure --user admin:secret \
  https://ip:3535/api/v1/actions/rbuilder_restart

# Upload blocklist
curl --insecure --user admin:secret \
  --data-binary "@blocklist.json" \
  https://ip:3535/api/v1/file-upload/rbuilder_blocklist

Since blocklists are per-operator, a transaction filtered by one operator can still be included by another.

• rbuilder: block construction engine
• bidding service: private bidding logic
• orderflow-proxy: ingest, P2P broadcast, archival forwarding
• system-api: operator control plane
• HAProxy: traffic routing and high availability
• Prometheus/Fluentbit: metrics and logs

• Titan: more centralized path, usually lower latency
• BuilderNet: multi-operator shared orderflow with explicit refund mechanics

1. Exclusive orderflow relationships with major wallets/bots
2. Latency advantage from centralized architecture
3. Neutrality narrative (no searching) that attracts some bundle flow

Public analyses often note a significant fee share from exclusive flow channels.

Titan exposes a bundle status query (titan_getBundleStats), while BuilderNet currently lacks full parity.

curl -X POST -d '{"method":"titan_getBundleStats","params":[{"bundleHash":"0x..."}],"jsonrpc":"2.0","id":1}' \
  https://stats.titanbuilder.xyz

MEV-Boost is open-source middleware by Flashbots for PBS in Ethereum PoS. Validators can source higher-value blocks from a builder market instead of building entirely by themselves.

A common public metric is that most Ethereum blocks currently flow through MEV-Boost paths.

• Searcher: creates value-extracting bundles
• Builder: assembles candidate blocks and bids
• Relay: validates/escrows blocks and forwards highest bids
• Validator: blind-signs and broadcasts blocks

1. Validator registers with relay
2. At slot time, validator requests highest bid block header (no full tx body)
3. Validator blind-signs
4. Relay validates signature and returns full block
5. Validator broadcasts

Blind signing reduces validator ability to frontrun or replace block contents before commitment.

1. Aggregate submissions from multiple builders
2. Simulate and validate block correctness/payment constraints
3. Hide full contents before signature
4. Release and broadcast after signature
5. Provide historical data APIs

Some relays use optimistic mode for lower latency:

• return block first, complete parts of validation asynchronously
• if invalid, builder bears the penalty

• Builders usually submit to multiple relays to maximize win rate
• Relay policy differs on sensitive flow (for example OFAC-related addresses)
• Validators can reduce single-relay censorship exposure via multi-relay configs and min-bid

Relays are critical PBS infrastructure but still lack durable direct monetization in many setups.

1. bidding service computes bid
2. Block is signed with relay key
3. Submission fan-outs to multiple MEV-Boost relays
4. extra_data marks BuilderNet (operator_id)

• regional relay routing only
• bundle cancellation support
• about 2x p99 end-to-end latency improvement