To accelerate the pace of development in BuilderNet, and offer better support to users, we intend to introduce a new public feed which shares the BuilderNet system logs on a 24 hour delay.
Motivation
Today, BuilderNet operators and contributors have very little visibility into the overall performance of the system. This makes it difficult for them to debug issues or develop and monitor new features for users.
Increasing observability into BuilderNet will make it easier for more parties to contribute to its development and drive better outcomes for users. For example:
- Optimizing block building performance to improve execution for trades
- Offering faster and more thorough support to users
- Shipping new features that improve the user experience
Change
During a given slot, each node in BuilderNet continuously builds new blocks. After each block building run, the node emits a system log containing a set of operational metrics such as the transaction count, block value, timestamps, and other performance indicators that are used to monitor and improve BuilderNet. These logs do not include raw bundle data or transaction contents, but rather aggregated statistics about system behavior.
Going forward, we intend to publish all of these system logs, generated by every BuilderNet node, over a public data feed. The logs will be delayed 24 hours to ensure that they do not leak pre-trade information that could be used to frontrun users before their transactions land onchain.
We will re-evaluate this proposal to determine if it should be replaced or deprecated no later than 6 months after it goes live.
Impact
This change will not affect pre-trade privacy in BuilderNet. Raw bundle data will remain private until the bundle either lands onchain or fails.
This change will increase the amount of visibility that the public has into historical activity within BuilderNet. This includes:
- The latency of certain operations within the system
- The relative performance of different block building strategies
- The aggregate value of all bundles in the system at a given point in time
We believe this information will make it dramatically easier for collaborators to identify and monitor improvements to the network.
Risks and mitigations
While increased observability will benefit development and support, we recognize that it also introduces potential risks. We’ve consulted with experts from the whitehat and MEV community to ensure this change will not compromise critical workflows. To protect users, we’re also implementing several safeguards, including:
- Filters to prevent sensitive information leakage into the logs
- A kill switch for emergency situations
- Enhanced operator upgrade capabilities for rapid responses to issues
We expect to begin testing this feed with operators in the coming weeks and roll it out publicly shortly after that. As always, questions and feedback are welcome.