InfraEvaluation stage⏱ 4 min read

Private Mempool Endpoints: Routes, Limits, and Tests

**Answer first** - A private endpoint reduces intentional public pre-inclusion broadcast, but the label covers different products. A wallet-protection RPC, an Ethereum searcher bun

Private transaction routing review with fallback and confirmation checks
FR
FRB TeamMEV Specialists
Last updated
#Private Mempool#RPC#Flashbots#Jito#Execution

Answer first - A private endpoint reduces intentional public pre-inclusion broadcast, but the label covers different products. A wallet-protection RPC, an Ethereum searcher bundle API, and a Solana bundle route have different payloads, visibility, fallback, and confirmation rules. Choose the route by its current documentation, simulate the exact payload, and verify the final result on-chain.

Three route classes that should not be combined

Route class Typical payload Primary user Evidence to verify
Private transaction RPC One signed transaction Wallet user or application Rebroadcast policy, cancellation, replacement, expiry
Ethereum bundle API Ordered signed transactions Searcher or execution system Target block, permitted reverts, builder selection, bundle status
Solana bundle route Ordered signed Solana transactions Solana execution system Slot handling, tip policy, bundle status, signature confirmation

Flashbots Protect documents a user-protection route on Ethereum. Flashbots bundles are a separate searcher workflow. Jito documents a Solana bundle model. These sources describe different systems; one provider name should not be used as evidence for another route.

What private submission changes

Private submission can limit public pre-trade visibility before inclusion. It does not by itself prove:

  • universal secrecy from relays, builders, validators, or infrastructure operators;
  • inclusion in a block or slot;
  • a better execution price;
  • protection from contract behavior, state changes, or every form of transaction ordering;
  • profitability or a fixed reduction in slippage.

An included transaction is public on-chain. The relevant privacy question is who receives the payload before inclusion and what the service can do after expiry or non-inclusion.

Evaluation matrix

Use the same fields for every candidate route.

Dimension Question to answer from primary documentation
Network and method Which chain, RPC method, and payload format are supported?
Visibility Which relay, builder, validator, or service can inspect the payload?
Fallback Can the payload reach a public path, and under which condition?
Simulation Which state reference is used and how are reverts reported?
Expiry When does the request stop being eligible?
Replacement Can a transaction be replaced or cancelled?
Selection Which builders or leaders can receive the request?
Confirmation Which status call, transaction hash, signature, and receipt prove the result?
Data handling What do the current terms say about logs, retention, and sharing?

Do not copy a provider comparison table that contains unattributed latency, inclusion, or protection scores. Measure those properties from the intended deployment region with an identical workload.

A safe test workflow

  1. Record the exact endpoint documentation URL and review date.
  2. Confirm the network, method, authentication, fallback, and expiry rules.
  3. Build the intended transaction or bundle without exposing signing material in logs.
  4. Simulate against a recorded state reference.
  5. Submit a low-risk test through one route.
  6. Store the response identifier and timestamps.
  7. Verify the transaction hash or signature on-chain.
  8. Classify the outcome as included, expired, rejected, reverted, replaced, or not found.
  9. Repeat under the same test conditions before comparing routes.

The response from an RPC endpoint is operational evidence, not final settlement evidence. The chain remains the source of truth for inclusion and execution.

Where FRB Agent fits

FRB Agent is a non-custodial Windows execution assistant for user-configured EVM and Solana workflows. Signing remains local. The operator chooses the supported execution route and remains responsible for permissions, simulation, provider policy, fees, and confirmation.

FRB is not a relay, builder, validator, wallet-protection guarantee, or replacement for provider documentation. Its useful role is to keep route review, local signing, simulation, submission, and reconciliation in one operator-controlled workflow.

Methodology and limitations

This guide compares documented route semantics, not provider performance. Interfaces, builder coverage, fallback policies, and data terms can change. Re-check each primary source before production use and retain raw test evidence. No route should be described as universally private, protected, or guaranteed to land.

Use the documented relay map to identify the correct provider category. For Ethereum, compare the broader private RPC decision guide with the provider-specific Flashbots Protect setup guide before configuring a route.

FAQ

Does a private endpoint make a transaction confidential?

No. The service processing the submission can see the payload, included transactions become public on-chain, and provider policies define any fallback or sharing.

Is a private transaction RPC the same as a bundle API?

No. A user-protection RPC usually accepts a single signed transaction, while a searcher bundle API accepts an ordered group with target and expiry rules.

Does an accepted request prove inclusion?

No. Verify transaction hashes and receipts on-chain and reconcile expired, rejected, reverted, or missing submissions.

Next step: review the private-bundle workflow, then use the simulation guide before testing any route with value.

Frequently asked questions

Does a private endpoint make a transaction confidential?

No. The service processing the submission can see the payload, included transactions become public on-chain, and provider policies define any fallback or sharing.

Is a private transaction RPC the same as a bundle API?

No. A user-protection RPC usually accepts a single signed transaction, while a searcher bundle API accepts an ordered group with target and expiry rules.

Does an accepted request prove inclusion?

No. Operators must verify transaction hashes and receipts on-chain and reconcile expired, rejected, reverted, or missing submissions.

Related Articles

Further reading & tools

Discussion

No notes yet. Add the first observation, or share the link with your team on X (@MCFRB).

Leave a note
Notes are stored locally in your browser only.
Control the Pulse

Expand Your Execution

Maximize your edge by exploring the full FRB toolkit. From institutional-grade telemetry to ready-to-export strategy scripts.

Blog → App Bridge

Ready to deploy this strategy? Open the dashboard and monitor execution.

Ready to Evolve?

Take the Next Step

Whether you're verifying terminal security or launching your first bundle, the FRB journey starts here.

Recommended

Install FRB Agent

Secure Windows build. Verified via SHA-256 for maximum integrity.

Recommended

Read Docs Quick Start

Master the setup in 15 minutes. From wallet pairing to first bundle.

Recommended

Launch Dashboard

Monitor your Ops Pulse and manage transaction routes in real-time.