Skip to content

Common integration layer

TOOL Integration Overview

This page is the common entrypoint for integrating with TOOL (specifically focused on Searcher Network/v0 Mainnet stage) as an Orderflow Provider (OFP), Searcher, or external PBS block builder. It explains the shared flow, shared terms, and common boundaries before the role-specific documents branch into details.

Shared Concepts

Concept Meaning
Source orderflow Private transactions or bundles submitted by an OFP or external builder.
Source commitment TOOL's commitment created from valid source orderflow.
Searcher bundle A native TOOL bundle that builds on one or more commitments and adds searcher transactions.
Solution A new commitment a searcher builds on existing ones: a backrun on one base, or a merge of several.
Base An existing commitment a solution builds on.
Top-of-block solution A searcher bundle without bases.
Callback The URL of the source (an OFP) that wants to receive solutions on its flow. A callback sees only its own source's transactions.
builders The allow-list of external block builders allowed to receive a commitment's bundle (returned as extBuilders in commitment JSON). Empty means never send to external builders. A solution gets the intersection of its bases' lists.
mixed-origin The callback marker of a solution whose bases do not all share the same callback. It is never delivered to a callback.
Relay merging node A TOOL node that builds a payload from pending commitments and submits it to an external relay.
Relay-only A solution with no callback and no builders. Relay merging nodes hand it to the external relay; other nodes reject it.
Quote flow The OFP flow where unsigned transactions are sent with ofp_sendUnsignedBundle, solutions come back as quotes, and the OFP finalizes with ofp_sendSignedBundle.
Unsigned commitment A quote-flow commitment whose user transactions are not signed yet.
Quote The callback message showing an OFP a candidate solution for its unsigned bundle.
Seal time The moment TOOL stops building the current block; waits for missing transactions end then.
Native TOOL path TOOL-side block production or relay delivery that does not require returning a bundle to an external source.
TEE verification Optional verification that private flow is being sent to an attested TOOL environment.

Common Flow

TOOL (in the Searcher Network/v0 stage) accepts private or pre-merged orderflow, converts valid submissions into Commitments, lets searchers build on the allowed Commitment view inside the TOOL network, and routes valid enriched bundles according to callback and block-production policy.

flowchart TB
  subgraph Sources["Source integrator boundary"]
    direction TB
    SourceClients["OFP and PBS builder clients<br/>private txs and bundles"]
    SourceAuth["Callback receiver<br/>verifies X-Flashbots-Signature"]
    Verifier["TEE verifier<br/>optional RA-TLS policy"]
  end

  subgraph ToolNetwork["TOOL network"]
    direction TB
    subgraph ToolTEE["TOOL node TEE environment"]
      direction TB
      Intake["Gateway and source intake<br/>eth_sendBundle / ofp_* / TOOL RPC"]
      Commitments["Commitment engine and feed<br/>origin tracking and timing"]
      Routing["Bundle API and routing policy<br/>simulate, submit, classify"]
      Native["Native block path<br/>subslot and relay delivery"]
      Intake -->|"form source commitments"| Commitments
      Commitments -->|"validated metadata"| Routing
      Routing -->|"accepted internal flow"| Native
    end

    subgraph SearcherTEE["Searcher context inside TOOL"]
      direction TB
      SearcherView["Allowed commitment view"]
      SearcherRuntime["Searcher / solver logic"]
      SearcherBundle["Native TOOL bundle<br/>source commitments + searcher txs"]
      SearcherView -->|"evaluate opportunities"| SearcherRuntime
      SearcherRuntime -->|"build and submit"| SearcherBundle
    end

    Commitments -->|"stream allowed commitments"| SearcherView
    SearcherBundle -->|"tool_simulateBundle / tool_sendBundle"| Routing
  end

  subgraph Delivery["Delivery contexts"]
    direction TB
    Callback["OFP callback<br/>solutions on its own flow"]
    Builders["External builders<br/>builders allow-list"]
    Relay["MEV-Boost relay path"]
    Validator["Validator"]
    Relay -->|"block proposal path"| Validator
  end

  SourceClients -->|"submit private txs / bundles"| Intake
  Routing -.->|"signed callback"| SourceAuth
  Verifier -.->|"verify attested endpoint"| Intake
  Routing -->|"same-callback solution"| Callback
  Routing -->|"intersection of builders"| Builders
  Native -->|"payload delivery"| Relay

  style Sources fill:#f8fafc,stroke:#64748b,stroke-width:2px
  style ToolNetwork fill:#edf7f5,stroke:#0f8b6f,stroke-width:2px
  style ToolTEE fill:#eef2ff,stroke:#315fbe,stroke-width:2px
  style SearcherTEE fill:#fff7ed,stroke:#a56812,stroke-width:2px
  style Delivery fill:#fff1f2,stroke:#b03a5b,stroke-width:2px

API Orientation

Different roles use different parts of the API surface. This overview names the relevant surfaces so each role can find the right integration path; Reference is the source of truth for schemas, examples, endpoint shapes, and method-level validation behavior.

Role Primary surfaces
OFPs and external builders eth_sendBundle for source ingress; ofp_sendUnsignedBundle and ofp_sendSignedBundle for the quote flow; the quote callback contract and the callback receiver contract when a callback is set.
Searchers tool_subscribe, tool_simulateBundle, tool_sendBundle, and tool_nextBlockParams.
Privacy-sensitive integrators tee_getAttestation before sending private flow or consuming sensitive commitment data.
Validators and relay clients MEV-Boost builder HTTP for status, registration, bid, and payload exchange.

Delivery Rules

Order flow reaches a node as a bundle or a plain transaction. The node turns it into a commitment: the transactions, their execution result and the block they target. Commitments live in the node's pool and are gossiped to all nodes. Searchers build solutions on top of them. Each commitment carries two delivery attributes: a callback and builders.

flowchart TB
  subgraph IN["Order flow"]
    A["eth_sendBundle"]
    B["eth_sendRawTransaction"]
    C["ofp_sendUnsignedBundle"]
    D["Mempool tx from peers"]
  end
  IN --> P[("Commitment pool + gossip")]
  S["Searchers: tool_sendBundle"] -->|"solutions on bases"| P
  P -->|"same callback on every base"| CB["OFP callback"]
  P -->|"intersection of builders"| BL["External builders"]
  P -->|"relay-only"| RM["Relay merging node"]
  RM --> RL["External relay"]
  1. Builders are an allow-list. An empty list means "never send to external builders".
  2. Defaults apply only where order flow enters. No callback and no builders: all builders. A callback and no builders: none. An explicit "builders": []: none.
  3. A solution reaches only the builders that every base allows (intersection).
  4. A callback sees only its own source's transactions. A solution keeps a callback only if all its bases have that same callback. Otherwise its callback becomes mixed-origin and it is never delivered to a callback.
  5. A solution with no callback and no builders is relay-only. Relay merging nodes create it and hand it to the external relay; other nodes reject it. A solution on an unsigned (quote-flow) bundle can never be merged with another source.
  6. Whether a new commitment is delivered right away depends on where it came from:

    Source Delivered right away
    Mempool transaction relayed by peers Nothing; only solutions on it are delivered
    OFP bundle with a callback Nothing; the OFP receives solutions and decides itself
    OFP bundle without a callback (including eth_sendRawTransaction) The bundle itself, to its builders
    Searcher solution, signed quote-flow bundle To its callback and its builders
  7. Delivery is best effort. A callback gets 5 seconds and is not retried; builder requests are asynchronous and their failures are only logged. Only ofp_sendSignedBundle waits for its callback and reports its error; everything else is delivered in the background. If raw transactions are missing, delivery waits for them until the block is sealed, and is dropped if a new block starts or the commitment leaves the pool.

What the rules do not promise

builders does not hide your transactions from TOOL nodes and searchers (see Delivery by Participant). Callbacks are only available on nodes running in callback mode.

Entry Points

Entry point Creates Builders Callback
eth_sendBundle A commitment The builders field Optional
eth_sendRawTransaction The transaction, also wrapped into a bundle All None
ofp_sendUnsignedBundle An unsigned commitment All (the request's builders is ignored) Required
ofp_sendSignedBundle A signed commitment without bases The request's, limited to the chosen solution's Optional
Mempool transactions from peers A commitment All None
tool_sendBundle A solution All without bases; the intersection otherwise From the bases (Callback and Builders of a Solution)
tool_simulateBundle Nothing is stored As tool_sendBundle As tool_sendBundle

Delivery by Participant

Pick your role to see only what applies to you: where your flow or solutions end up, and who can see them.

Terms used in every view:

  • Relay merging only: no callback and no external builder can receive it. Relay merging nodes include it in the payload they submit to the external relay; other nodes reject it with commitment has no delivery target.
  • Right away: sent as soon as the node accepts it, without waiting for a solution.
  • Every delivery is best effort (5 s, no retry) and is signed with the FlashbotsKey of the node that built it.

View as

Where your flow goes. Your bundle has two delivery settings, callbackUrl and builders. Together they decide what happens to the bundle itself and to the solutions searchers build on it. A solution built only on your flow keeps your settings; once it is merged with someone else's flow, your callback drops out and only the builders every merged bundle allows remain.

flowchart TB
  Bundle["Your bundle"] --> HasCb{"callbackUrl?"}
  HasCb -->|"no"| Direct["Bundle to your<br/>builders, right away"]
  HasCb -->|"yes"| Held["Bundle not<br/>forwarded"]
  Direct --> Sol["Searchers build<br/>solutions on it"]
  Held --> Sol
  Sol --> Own{"Only your<br/>flow?"}
  Own -->|"yes"| Yours["Your callback<br/>+ your builders"]
  Own -->|"no"| Shared{"Builder every<br/>bundle allows?"}
  Shared -->|"yes"| Common["Those builders,<br/>no callback"]
  Shared -->|"no"| Relay["Relay merging<br/>only"]
Your settings Your bundle itself Solutions on your flow only Solutions merged with other flow
No callback, builders omitted All builders, right away All builders Builders every merged bundle allows
No callback, ["titan"] titan, right away titan titan, if every merged bundle allows it
No callback, [] Nowhere: TOOL pool only Relay merging only Relay merging only
Callback, builders omitted Not forwarded Your callback Relay merging only
Callback, ["titan"] Not forwarded Your callback + titan titan, if every merged bundle allows it
Callback, ["*"] Not forwarded Your callback + all builders Builders every merged bundle allows

"Your flow only" means searcher transactions added to your bundle, or a merge of bundles that all carry your callback. eth_sendRawTransaction behaves like the first row.

Quote flow.

Stage Goes to
Unsigned bundle (ofp_sendUnsignedBundle) Nowhere. Solutions on it come back as quotes to your callback, only from the node you called.
A solution merging your unsigned bundle with other flow Rejected. You never see another source's transactions.
Signed bundle (ofp_sendSignedBundle) with builders: [] TOOL pool only.
Signed bundle with no builders and no callbackUrl The chosen solution's builders, right away.
Signed bundle with no builders and a callbackUrl Your final callback only. No builders.
Signed bundle with ["titan"] or ["*"] The listed builders that the chosen solution also allows, right away.
Signed bundle with a callbackUrl Also the final callback. It may differ from the quote callback, or be omitted.
Solutions on your signed bundle As in the table above, using the signed bundle's settings.

Who sees your flow.

Who Your signed transactions Your unsigned (quote) transactions Your callback URL
TOOL nodes and searchers Yes, always: builders does not hide them Hashes and execution effects; the bodies stay on the node you called A hash in JSON; clear text in node-to-node gossip and node logs
Your callback Solutions on your flow, with the searcher's transactions Quotes, then the signed bundle —
Other OFPs' callbacks Never Never No
Builders in your list The bundle if it has no callback, and solutions on it Only after signing No
Other builders No No No

A slow callback endpoint can delay and fail only your own ofp_sendSignedBundle call; it cannot affect searchers or builder delivery. Builders are external: some forward order flow to other parties, which builders cannot control.

Where your solution goes. It is decided by the bases you build on, never by a field you send. Read callbackUrl and extBuilders in the returned commitment to confirm (Submitting Solutions).

flowchart TB
  Bundle["Your bundle"] --> Bases{"Any<br/>bases?"}
  Bases -->|"no"| TOB["All builders"]
  Bases -->|"yes"| Unsigned{"Quote-flow<br/>base?"}
  Unsigned -->|"yes"| Q{"First, and<br/>callbacks match?"}
  Q -->|"yes"| Quote["Quote<br/>to OFP"]
  Q -->|"no"| Rej["Rejected"]
  Unsigned -->|"no"| Same{"Callbacks<br/>match?"}
  Same -->|"yes"| Keep["Callback +<br/>common builders"]
  Same -->|"no"| Common["Common<br/>builders only"]

With no callback and no common builders, the solution is relay merging only.

You send Delivered to
New transactions only (top-of-block) All builders
One base + your transactions (backrun) The base's callback and builders. If the base has neither, relay merging only.
Several bases sharing one callback That callback + the builders every base allows
Several bases whose callbacks differ, or where some have none The builders every base allows; if none, relay merging only. Never a callback.
A quote-flow base A quote to that OFP only. It must be the first base and every other base must share its callback; otherwise the bundle is rejected.

A base without a callback is not neutral: merging it with a callback base removes that callback.

Who sees your transactions.

Who Sees your transactions
TOOL nodes and searchers Yes: solutions are gossiped to all nodes
The OFP whose flow you built on Yes, in the quote and in the signed callback
Other OFPs Never
Builders allowed by every base Yes
Other builders No

What you can see. Every pooled commitment and its transactions, except quote-flow transactions (hashes and execution effects only; the bodies stay on the OFP's node) and callback URLs (a hash in JSON).

What reaches your endpoint. This view is about receiving bundles from TOOL. When you submit flow into TOOL with eth_sendBundle, you are a source: use the Orderflow provider view.

flowchart TB
  Now["Sent right away (if they list you)<br/>OFP bundles without a callback<br/>eth_sendRawTransaction<br/>Signed quote-flow bundles"] --> You["Your builder endpoint<br/>eth_sendBundle"]
  Later["Never sent themselves<br/>OFP bundles with a callback<br/>Mempool transactions"] -->|"solutions on them,<br/>if every base lists you"| You
Flow What you receive
OFP bundle without a callback that lists you (the default) The bundle, right away
eth_sendRawTransaction The transaction, right away
OFP bundle with a callback Never the bundle itself; solutions on it, if it lists you
Mempool transaction relayed by peers Never the transaction itself; solutions on it
Unsigned quote-flow bundle Never; the signed bundle, right away, if it lists you
Top-of-block searcher solution The solution
Solution on one or more bases The solution, if every base lists you
Solution no builder may receive Never; relay merging only

Request format. A JSON-RPC eth_sendBundle with every transaction (bases first), blockNumber, minTimestamp and maxTimestamp, and revertingTxHashes when not empty. It carries X-Flashbots-Signature from the node that built it (empty if that node has no FlashbotsKey). Each of your registered URLs gets its own request; failures are only logged on the node and not retried.

Who sees what you receive. All TOOL nodes and searchers see the same transactions; builders that a bundle does not list never receive it from TOOL. OFP callbacks receive only solutions on their own flow.

Shared Trust Model

Authentication and TEE verification are separate concerns.

Callback authentication

Callbacks are signed by the delivering node's FlashbotsKey in the X-Flashbots-Signature header; the receiver verifies the signer address. Quotes carry an empty signature header and must not require one. See the callback receiver contract.

TEE verification

Lets an integrator verify the TOOL environment before sending private flow or consuming sensitive commitment data. The stronger privacy setup is RA-TLS, where the TLS connection is bound to the attested service.

Public Endpoints

Nuconstruct-hosted TOOL endpoints are available for mainnet searcher-network testing, Hoodi RPC access, and Hoodi validator relay integration.

Searcher Network TOOL v0 Mainnet

Mainnet RPCs

https://tool-0.tool.limo:8545
https://tool-1.tool.limo:8545

Use either endpoint for Searcher Network / TOOL v0 Mainnet integration.

Hoodi Testnet TOOL v1

Testnet RPC

https://rpc-hoodi.nuconstruct.xyz/
wss://rpc-hoodi.nuconstruct.xyz/ws

Use these endpoints for TOOL v1 Hoodi Testnet JSON-RPC and WebSocket access.

Hoodi Validators MEV-Boost compatible

Relay API

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

Use this endpoint as the TOOL v1 MEV-Boost Relay API-compatible endpoint for Hoodi Testnet validators.

Onboarding

Orderflow Providers

Route private source flow into TOOL, choose a plain bundle or the quote flow, set a callback and builders, and verify signed callbacks.

Searchers

Subscribe to commitments and submit native TOOL bundles from inside the network participation model.

External PBS Builders

Submit existing bundle flow through eth_sendBundle and control delivery with builders.

Technical Reference

Use Reference for method schemas, field definitions, endpoint shapes, and error strings. Use Technical Architecture after the relevant integration path is clear for deeper node behavior, subslots, commitment internals, peer networking, and relay delivery.