TOOL Introduction¶

Why TOOL Exists¶

Ethereum's transaction supply chain is increasingly shaped by private orderflow channels, builder concentration, relay trust, and delayed execution feedback. This creates a weaker market for many participants: users wait longer to know what happened, applications struggle to offer reliable execution, validators can miss value when auctions fragment, and orderflow providers often depend on bilateral integrations.

TOOL's goal is to create a shared orderflow layer where privacy, execution feedback, and value competition are part of the network design rather than side agreements between a few counterparties.

How TOOL Works At A High Level¶

TOOL runs as a network of TEE-backed participants.

• TEE-secured nodes allow integrators to verify that private orderflow is being handled by the intended code path.

• The Peer-to-peer nature of the network connects Orderflow Providers, Searchers, traders, and other participants directly on equal terms, decentralizing block production and increasing information exchange efficiency.

• 1-second subslot design enables earlier execution feedback for users and applications, effectively turning Ethereum into a high-frequency chain without compromising its CROPS properties.

• MEV-Boost-compatible delivery path makes it possible for validators to adopt TOOL without requiring Ethereum protocol changes.

Stakeholder View¶

What TOOL Enables¶

flowchart TB
  subgraph External["External orderflow sources"]
    direction TB
    Wallets["Wallets and applications"]
    OFPs["Orderflow providers"]
    Builders["External PBS builders"]
  end

  subgraph Network["TOOL network"]
    direction TB
    Intake["Source intake<br/>private txs and bundles"]
    Commitments["Commitment creation<br/>origin tracking and policy"]
    Searchers["Searcher logic<br/>inside TOOL"]
    Routing["Routing policy<br/>callback or native path"]
    Intake -->|"valid source flow"| Commitments
    Commitments -->|"allowed commitment view"| Searchers
    Searchers -->|"enriched bundles"| Routing
  end

  subgraph Delivery["Delivery"]
    direction TB
    Callback["Same-origin callback<br/>when enabled and safe"]
    Relay["MEV-Boost-compatible<br/>block delivery"]
    Validators["Validators"]
    Relay -->|"builder path"| Validators
  end

  Wallets -->|"transactions"| Intake
  OFPs -->|"private flow"| Intake
  Builders -->|"pre-merged bundles"| Intake
  Routing -->|"return source-owned private flow only"| Callback
  Routing -->|"keep inside TOOL block path"| Relay

  style External fill:#f8fafc,stroke:#64748b,stroke-width:2px
  style Network fill:#edf7f5,stroke:#0f8b6f,stroke-width:2px
  style Delivery fill:#fff7ed,stroke:#a56812,stroke-width:2px

This flow separates source orderflow from searcher competition without exposing raw private flow broadly. A source can submit flow to TOOL, searchers can add value around the resulting commitment, and callback-enabled sources can receive enriched bundles when the return path is safe for that source.

When no callback is available, or when a commitment should stay inside TOOL, the commitment can still contribute to TOOL-native block production.

What Is Different¶

Technical Roadmap¶

Implemented stages marked bold

Current Focus¶

Integration Paths¶

Start with the common integration page, then follow the branch that matches your role.

Technical Deep Dive¶

After choosing an integration path, use Reference for concrete method schemas and Technical Architecture for deeper protocol, node, consensus, security, and low-level API details.

In Short¶

TOOL is not just another builder, relay, OFA, or pre-confirmation service. It is a network layer for private orderflow processing and distributed block building, designed to make Ethereum execution faster, more private, and more competitive while preserving compatibility with the infrastructure Ethereum already uses.