After reading the BuilderNet documentations, I’d appreciate clarification on a few implementation details:
Are operators free to run their own custom block‑building logic, or is there a reference / default algorithm that most operators follow?
Is every transaction supposed to be shared across all operators, or could an operator keep a private mempool and only broadcast at the last moment?
Similarly, is it permissible to append very late‑arriving orders only to one’s own candidate block?
For the “best block minus one tx” refund calculation, does BuilderNet actually compute the optimal block after removing each transaction?
If so, is the algorithm used for that “best block” search publicly documented or open‑sourced?
Does the protocol assume active bid competition between builders?
If builders bid aggressively, wouldn’t the refundable margin be driven close to zero?
Conversely, if we assume little or no competition now, what happens when more builders join BuilderNet—will the proposer’s share fall sharply?
Which specific properties or constraints are verified inside the TEE? Could you outline the high‑level flow from order submission through TEE verification to block proposal?
How does the sender know that the recipient has indeed received and processed the order inside a TEE? Is there an attestation or other cryptographic proof provided back to the sender?
All nodes/operators run the same block-building logic with the default algorithms.
Every transaction is shared across all builder nodes. The orderflow-proxy service receives transactions and shares them with orderflow-proxy on all other instances, as well as with rbuilder. See also Operating system, services and reproducible builds | BuilderNet
BuilderNet does compute the optimal block after removing each transaction. For this, the transactions are stored in the redistribution archive (see also Architecture overview | BuilderNet)
Builder nodes don’t compete with each other, but they collaborate. They do not try to outbid each other, rather they are aware of each other’s bids, as well as of those of competitors.
Every builder node creates a local TLS certificate, of which the private key reside exclusively inside the TEE instance (and never leaves it).
Every builder node exposes a server to validate it’s TEE proof with aTLS. During TLS setup on this port, the TEE proof validation (attestation) is performed, which establishes a secure channel into a verified TEE instance. Over this secure verified channel, users receive the TLS certificate.
Users can use this TLS certificate which they received after the TEE proof validation to send orderflow to the instance (they can require the server to possess the private key for this certificate).
Hi, I recently switched to BuilderNet and I have a few questions as well:
About the refund rule, if I understand correctly I don’t have to do anything specific to receive a refund based on my bundle contribution. Is that correct? I have not received any refunded ETH yet (it’s been a few days) so I’m wondering if I’m missing something.
Moreover the dune query that tracks the refund batches that is linked in the BuilderNet documentation (query 4398421/7371992, can’t include link in post) shows that the last one was sent more than two months ago. Is the query outdated?
“Builder nodes don’t compete with each other, but they collaborate.” I don’t understand this part. In what way do they collaborate? And how does it benefit them?
Lastly, I have a broader question about BuilderNet itself: it looks amazing for searchers, but not so great for existing block builders. Titan and Beaverbuild make around 90% of the blocks, what are their incentives to become a BuilderNet node? It seems like this is just a losing move for them, as most of what they earn would be distributed back to searchers.
I know Beaverbuild made the switch already, I’d like to understand why. Similarly, is there any chance Titan makes the switch as well?
I don’t have to do anything specific to receive a refund based on my bundle contribution. Is that correct?
Yep that’s right. You don’t have to do anything to receive refunds right now. They’re disbursed every few months (the query is correct). Pending refund amounts are also updated ~daily in this dashboard: Hex
We want to move this to a claim-based model in the future, so you could fetch your refund whenever you want to.
In what way do they collaborate?
The nodes coordinate their bids to avoid paying more than necessary in the MEV-Boost auction. Instead of trying to out-bid each other, they only try to out-bid other external block builders. This allows them to retain more of the block value (and refund it to users).
And how does it benefit them?
There is no economic benefit to running a node in BuilderNet today.
it looks amazing for searchers, but not so great for existing block builders
Many block builders today are vertically integrated searchers.
I know Beaverbuild made the switch already, I’d like to understand why. Similarly, is there any chance Titan makes the switch as well?
Thanks for the reply! That brings one simple but important question: what’s the point for anyone to become a node operator?
As a searcher, can I include my own transactions in the blocks I build without sharing them with other node operators? If I can it’s definitely a good move for me, but that would bring the centralization problem back wouldn’t it? (with operators competing for orderflow and making private deals)
If I can’t, then I’m just losing money by maintaining a node for no benefit?
Orderflow sharing isn’t just to avoid centralization from exclusive deals, it also drives better censorship resistance and refunds/price. Both of which matter quite a lot to the searchers we’ve spoken with.
