PERCH Proposal: Request for Lido operators to test TOOL on Hoodi

Proposals
1

PERCH Proposal: Request for Lido operators to test TOOL on Hoodi

Summary

This proposal asks Lido operators to integrate TOOL on the Hoodi network.

TOOL (Trustless Orderflow Operations Layer) is a protocol and network designed to transform Ethereum’s transaction supply chain.

TOOL aims to replace the current PBS framework on Ethereum Mainnet, while delivering sub-second execution guarantees and maintaining security and decentralization properties that are close to the Ethereum core p2p network.

It is out-of-the-box compatible with the mev-boost Relay API on the validator side and standard RPC methods on the user side, which provides a frictionless transition for Ethereum ecosystem participants.

Technical Specification

1-Second Execution on Ethereum

TOOL’s innovation is its ability to provide 1-second execution confirmations on Ethereum Mainnet without requiring any changes to the core protocol or consensus client software.

It achieves this by:

  • Sub-slot Architecture: Dividing each Ethereum slot into one-second sub-slots

  • Early Confirmations: Providing execution guarantees after each sub-slot finalization

  • L2-like UX: Delivering L2 user experience with L1 security and defi liquidity access

This effectively transforms Ethereum into a 1-second block time chain from the user and application perspective.

Key Features

End-to-End Orderflow Privacy

  • TEE Protection: All orderflow processing occurs within Trusted Execution Environments (Intel TDX is being used currently)

  • No Information Leakage: Transaction details remain private until execution is guaranteed

  • Sandwich Protection: Built-in protection against frontrunning and sandwiching

Execution Guarantees

  • 1-Second Confirmations: Sub-second trade confirmations on Ethereum Mainnet

  • State Visibility: Access to intermediate block states for transaction optimization

  • Feedback Loop: Clear inclusion/exclusion status with ability to adjust transactions

Credible Neutrality

  • TEE Enforcement: Transaction execution and inclusion rules enforced by hardware

  • Censorship Resistance: No entity can meaningfully affect execution of others

  • Transparent Rules: Open-source, auditable transaction processing logic

Unified Auctions

  • Blockspace Competition: All orderflow competes fairly for block inclusion and execution priority within 1-second subslots

  • MEV Distribution: Fair, dynamically controlled value distribution between validators and orderflow providers, that’d be strategically governed by DAO in the future.

  • Efficient Markets: Elimination of fragmented private orderflow silos

Seamless Integration

  • mev-boost Compatible: Drop-in replacement requiring only relay endpoint change on the validator side

  • No Protocol Changes: Works with existing consensus and execution clients

  • Application Ready: Out-of-the-box compatible with wallets, dApps, and infrastructure

Testing and Reliability

TOOL is covered by unit tests and undergoes end-to-end testing with a customized Kurtosis test suite (based on https://github.com/ethpandaops/ethereum-package) on every release.

Our existing Hoodi setup has been thoroughly tested with validators we have received from Ethereum Foundation, SSV, Rocketpool, Offchain Labs, RockwayX and Stakely.

At the moment of writing this post, TOOL has successfully landed more than 39,000 blocks. You can check blocks built with the following recipient address to see the up-to-date information: https://hoodi.etherscan.io/address/0xdd11751cdd3f6eff01b1f6151b640685bfa5db4a#mine

We are also preparing a dashboard that tracks connected validators, built blocks, and metrics such as missed slots, errors, and so on. We will update the community on its release.

Revenue and Governance Model

There are no additional costs associated with connection to TOOL.

TOOL projects to deliver a significant increase in proposer rewards compared to mev-boost after the mainnet launch. We are currently preparing documentation on our Mainnet roadmap and multiple research papers, showing consistent revenue boost for validators in a scenario of the orderflow parity.

Proposed Integration & Implementation

​To connect to the TOOL on Hoodi, Lido node operators must add the Relay API-compatible endpoint exposed from any available TOOL node running on the network, to their mev-boost config.

Right now, nuConstruct has a single node running, but we’re currently testing a p2p networking feature and as soon as we release it, validator operators will be able to spin up their nodes and connect to them directly, or pick any 3rd party operator as TOOL is fully permissionless.

https://0xa0f46566247ceb1f259a7189d5ac8bf2f0f07c135f081b0b5a9f226ef864bf6362c74306fcd02a87b7941f6feac57dc7@relay-hoodi.nuconstruct.xyz

  • No hardware upgrades or local software changes are required.

  • Integration takes effect immediately.

  • An operator should remove other relays from the config if it expects them to land blocks during TOOL uptime.

Ethics and Values

At nuConstruct, we aim to build a framework for a maximally neutral and decentralized value supply chain for Ethereum.

TOOL eliminates unnecessary reliance on intermediaries with pre-defined roles and lowers the entry barrier by providing a protocol that powers a permissionless, self-organizing TEE network owned by the community that does not have any centralized points that might lead to failures and information or power asymmetries.

It was built to provide an unmatched feature set that not only creates strong incentives for Ethereum operators and provides a transparent alignment framework, but also makes Ethereum competitive with alt-L1s from a UX perspective. This should strengthen its position as a primary hub for DeFi and other applications.

We plan to open source TOOL’s codebase upon our Mainnet release and are currently working on a private audit with one of the top independent firms.

Call to Action

We respectfully request Lido operators to connect to TOOL on Hoodi network. This integration represents an opportunity for setting up a positive track record for TOOL as a protocol that can enhance validator performance while maintaining Lido’s commitment to decentralization and security.

By connecting to TOOL, Lido operators will power 1-second execution confirmations, enhanced MEV capture, and improved user experience without any additional costs or technical complexity. We invite the Lido community to review our protocol’s architecture, examine our dashboard metrics (once available), and consider the strategic advantages TOOL offers for positioning Lido at the forefront of Ethereum’s infrastructure evolution.

For implementation, we recommend a phased rollout beginning with interested node operators who can add our relay endpoint to their mev-boost configuration and monitor performance. We stand ready to provide technical support, additional documentation, and answer any questions operators teams may have regarding this integration proposal.

Additional Resources

1 Like
2

Hey! We at P2P.org are interested in test participation here! I will try to apply the change in out infrastructure in Hoodi

3 Likes
3

Hey, Stakely has been testing TOOL on Hoodi with our Genesis validators, and we would like to participate in this initiative adding 1,000 Lido validators on Hoodi.

2 Likes
4

Hello! Chorus.one has also been testing TOOL on Hoodi and we’re interested in participating in this initiative :slight_smile:

2 Likes
5

Hey hey!
We at Everstake are interested in testing TOOL on Hoodi. We are at the stage of consideration and implementation

2 Likes
6

Thank you for the proposal and documentation. I have a few clarifying questions.

  1. When you say “replacing PBS” do you mean replacing mev-boost (or whatever relaying / PBS equivalent) software in validators / relays with new software under the TOOL protocol? Or is the idea more to augment / overlay existing infrastructure?
  1. How is TOOL’s architecture different from PBS + mev-boost? Especially on
    • Latency
    • Censorship resistance
  2. What are the risks/trade-offs, particularly around TEEs?
  3. On MEV distribution, how is the distribution determined in practice?
  1. Might be a little early, but is there preliminary data compare TOOL and PBS/mev-boost, in terms of proposer rewards, missed slots, transaction latencies?

Thank you.

2 Likes
7

Hey, thank you for your questions! There’s so much unpack :slight_smile:

  1. By “replacing PBS”, TOOL means to replace the underlying supply chain (block builders and relays) with a permissionless P2P network with nodes following the TOOL protocol.

  2. One of the key differences of TOOL from PBS/mev-boost is that it removes any pre-defined roles and the resulting ability to influence the execution of other participants.

    In addition to that, all TOOL nodes are TEE-attested, which yields the following properties for the network:
    a) linearly scalable as nodes do not do re-execution to verify results produced by other nodes. This removes any limitation on the network’s decentralization and significantly lowers minimal node requirements.
    b) latency- and bandwidth-optimized, as TEEs mitigate attack vectors (such as Eclipse attacks) that are solved by topology randomization in traditional P2P networks. As the network represents the end-to-end supply chain and avoids execution bottlenecks (present in the form of bundle pre-simulation queues inside OFAs/block builders), the latency measured from a user’s transaction event to the transaction’s potential inclusion is significantly lower compared to PBS.
    c) more censorship-resistant than PBS since the logic for all nodes is enforced by TEEs (unlike existing combinations of builders+mev-boost relays) and there’s no reliance on centralized actors, compared to PBS, where a few relays control the last mile of communication with proposers and can censor blocks or unequally treat blocks built by different builders, without facing any technical issues.

  3. TOOL has a strong, layered approach to security.
    Realistically, TOOL can only be breached by state-backed actors with physical access to servers inside datacenters that have TDX hardware available.
    There are two possible “worst-case” scenarios.

    In the first one, TOOL’s security in terms of transaction privacy will downgrade to a public mempool’s model.
    In the second, it will lead to a missed slot.

    The overall tradeoff that we took when designing TOOL is: reliance on major cloud providers with TDX offerings, in exchange for realtime compute (the same performance as normal cloud VMs) and best-in-class security.

    This tradeoff is reasonable as existing operators in the Ethereum supply chain (OFAs, block builders, relays) already host their nodes in the cloud, and as TOOL does not affect existing validator setups, it is strictly better in all aspects.

    There’s a much longer answer to this question, but I have decided to keep it short :slight_smile:

  4. We have a research-driven approach to the MEV distribution, and we have developed a dynamic controller that’d adjust the split based on the current market structure, yielding the best execution rewards to validators at all times, while optimizing for long-term rewards for orderflow providers.
    We’re going to publish this research closer to our full Mainnet release.

  5. We have a dedicated research team working on answering these questions and we’ll be publishing our results as we get closer to the full Mainnet release.
    But on the high level:
    a) We expect proposer rewards to be significantly higher compared to mev-boost in case of the orderflow parity.
    b) We expect the percentage of missed slots to remain the same, as most of the time, these are caused by issues on the proposer’s side.
    c) As TOOL offer 1-second tx execution for everyone, the transaction latencies for users will be superior to any other solution on the market. When it comes to other latencies, you can refer to the information in points 2.a and 2.b.

I hope that I addressed all of your questions!

1 Like
8

Hey! Blockscape is also interesting in join this and further test TOOL in Lido Hoodi.

3 Likes
9

I feel rather strongly that Lido should not allow NOs to use TOOL, and in general, NOs should understand how TOOL, if adopted, would be a disastrous direction for Ethereum.

1 – TOOL fails to meet either Lido’s or (even worse) Ethereum’s requirements for how the block producer market should function. This is not an implementation detail, but rather a fundamental aspect of its design.

TOOL is effectively just a single builder-relay that validators must connect to exclusively. As such, it removes the open market for block proposing, which has been the hallmark of Ethereum’s roadmap (mev-boost → ePBS → APS).

2 – Let’s remember why PBS is important for Ethereum: It removes the incentive for validators and builders to vertically integrate.

I can tell you precisely what happens if we open the door for block builders to circumvent PBS and lobby validators for exclusivity – every existing block builder is forced to do the same. If Lido allows NOs to use TOOL, next week you will receive the same proposal from Titan, BuilderNet, and Rsync, each requesting their own exclusive access.

The result is that block building becomes a game of who can lobby NOs better – with less competition, less innovation, and worse censorship resistance for Ethereum.

3 – The main “benefit” behind TOOL is giving 1s preconfirmations to swappers, but not only are preconfs controversial – many Ethereum researchers and core developers favor speeding up Ethereum through shorter block times – TOOL’s design is also the most centralizing way to implement preconfs.

Apart from these preconfs, TOOL is simply an inferior copy of BuilderNet.

3 Likes
10

Addressing Hasu’s points, I want to highlight that:

  1. TOOL is an open, permissionless framework that does not rely on centralized intermediaries, such as block builders or relays. It resembles Ethereum’s native p2p network, but with focus on performance, TEE-enforced orderflow privacy and neutrality.

  2. TOOL does not have any slashing mechanisms that can harm validators, and they’re free to opt-in and opt-out at any time.

  3. TOOL hosts an open, unified and competitive orderflow and blockspace market that is more efficient than any solution currently available to Node Operators.

  4. TOOL provides a new option for validators, being an alternative to mev-boost and self-building. While being a part of TOOL, validators can keep other options as a fallback, but can naturally only land blocks produced by the chosen solution.

Please note that there might be a conflict of interest due to Hasu’s position as Strategy Lead at Flashbots, the developer of the mev-boost framework, which is a competing solution.

According to his personal page (hasu.blog):

At the moment, I divide my time about 90% in Flashbots and 10% in Lido.

We’re currently working on comprehensive protocol documentation and will release the results of an ongoing audit by Sigma Prime - founders of the Lighthouse consensus client, early next year, followed by a source code release.

We’re always open to community feedback and will be happy to answer any questions about TOOL.

2 Likes
11

In spirit of disclosures, I personally have a small exposure to nuconstruct via cyber*fund. Below is not a legal endorsement, just personal opinion. The way I see the situation is:

  • there are legitimate concerns about how market could develop around TOOL, voiced by, among others, Hasu and Flashbots folks who I respect deeply
  • there are legitimate reasons to be excited about TOOL voiced by, among others, pretty prominent folks in Ethereum ecosystem, like a recent tweet by Potuz
  • many of them are mostly theoretical second order effect and I don’t think we as a community are that good at predicting second order effects; I certainly am not.

So my personal approach would be to err on side of more experiments rather than less; avoid one-way door decisions; and see how exciting are exciting parts and how real are second order effects. I think Lido’s PERCH is really good for that.

4 Likes
12

Thank you to both @Hasu and @0xprincess for the thoughtful input.

Speaking as a Lido contributor working closely with APMs, I want to briefly summarize how I currently see TOOL after reviewing the design, documentation, and community feedback.

Protocol Design & Ethereum Alignment

It’s true that TOOL currently runs through a single relay on testnet. From our conversations with the team, this looks like a bootstrap phase rather than the intended end state. The roadmap targets a permissionless P2P network of TEE-attested nodes that validators can connect to directly, removing reliance on a single operator.

That decentralization, however, is not yet in place. Any Lido pilot would require multiple independent operators with public attestation, reachable through the standard mev-boost interface. If it can meet those decentralization expectations, there’s no reason to stop any experimentation. In that context, TOOL can be treated as optional, like any other APM (and not a replacement for PBS).

On the broader concern: we agree that exclusive arrangements with any builder or relay would set a harmful precedent. The APM Committee intends to maintain an open, competitive builder market and would not support a configuration that undermines it.

Preconfirmations & Centralization Risks

TOOL’s 1-second confirmations and sub-slot design are interesting, but preconfirmation schemes remain early and controversial. Even user demand is still uncertain.

Our view is that TOOL (or any similar middleware) should remain optional and complementary to Ethereum’s roadmap (ePBS, APS, block-time improvements), not competitive with it. As with all other APMs, any evaluation will hinge on mainnet performance, reliability, and decentralization data and interest from Node Operators using the protocol.

Novelty & Comparisons

It seems to also be true TOOL shares goals with BuilderNet, but it does introduce additional primitives like TEE-enforced privacy and a sub-slot execution pipeline. These are worth examining, but Lido’s assessment will rely on independently verifiable evidence: security audits, real-world scenarios, and usage to drive recommendations.

In summary, we view TOOL as an innovative step in orderflow privacy and preconfirmations and are open to supporting mid-term experimentation on testnet if there’s enough NO demand.

As an extra note, we think including or expanding on a few additional points would enable a more thorough assessment by the APM Committee:

Some suggestions
  • Operator optionality: NOs must retain standard mev-boost connectivity, with no TOOL-only setups.
  • Decentralized infrastructure: multiple independent TOOL operators with on-chain TEE attestations, plus a functioning P2P client to remove reliance on a centralized relay.
  • Fallback and exit: a defined rollback path to baseline relays.
  • Auction market: a functional auction mechanism, demonstrating TOOL’s economic viability
  • Governance clarity: clarity on how MEV-split decisions (builder/validator) will be made.

We welcome continued dialogue with the TOOL team and the broader research community as the protocol matures.