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

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
- Record the exact endpoint documentation URL and review date.
- Confirm the network, method, authentication, fallback, and expiry rules.
- Build the intended transaction or bundle without exposing signing material in logs.
- Simulate against a recorded state reference.
- Submit a low-risk test through one route.
- Store the response identifier and timestamps.
- Verify the transaction hash or signature on-chain.
- Classify the outcome as included, expired, rejected, reverted, replaced, or not found.
- 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).