Ethereum Private RPCs: Protection vs Bundle Submission
**Answer first** - "Private RPC" can describe two different Ethereum jobs. A wallet user may want a private transaction endpoint such as Flashbots Protect to reduce harmful pre-tra
Answer first - "Private RPC" can describe two different Ethereum jobs. A wallet user may want a private transaction endpoint such as Flashbots Protect to reduce harmful pre-trade exposure. A searcher may need a bundle API for ordered target-block execution. These routes have different methods, users, and failure semantics. Choose by documented behavior, not a single latency or popularity ranking.
Two jobs, two evaluations
| Job | Typical object | Primary question |
|---|---|---|
| User protection | One signed transaction | How is the transaction routed and what fallback can expose it? |
| Searcher submission | An ordered bundle | How is the bundle simulated, targeted, priced, and sent to builders? |
Flashbots Protect and the Flashbots builder API are related products but are not interchangeable endpoints.
Wallet protection route
Flashbots documents Protect as an Ethereum endpoint intended to reduce frontrunning and related harmful MEV for user transactions.
Before using any protection endpoint, verify:
- supported methods and networks;
- whether and when a transaction reaches the public mempool;
- cancellation and replacement behavior;
- fallback after timeout or non-inclusion;
- data retention and logging;
- builder or order-flow sharing;
- confirmation and support procedures.
Do not describe a private endpoint as complete protection. Contract behavior, state changes, builder policy, and fallback can still affect execution.
Searcher bundle route
Flashbots defines bundles as ordered groups of transactions submitted for a target block. Its APIs also support selecting multiple builders through documented parameters.
A bundle workflow should:
- Construct and sign the intended transactions.
- Simulate against the target state.
- Define target block, expiry, and permitted reverts.
- Set builder-selection and payment policy.
- Store request identifiers and responses.
- Verify transaction hashes on-chain.
- Reconcile every cost and expired attempt.
A successful API response is not proof of inclusion.
How to compare providers
Use a capability matrix:
| Dimension | Evidence required |
|---|---|
| Audience | Wallet user, searcher, or both |
| Method | Private transaction, bundle, or both |
| Visibility | Explicit rebroadcast and fallback policy |
| Builders | Current documented builder-selection behavior |
| Simulation | Supported method and state reference |
| Failure | Revert, expiry, replacement, and cancellation |
| Observability | Request ID, status method, and on-chain mapping |
| Terms | Data use, prohibited use, and support scope |
Only compare latency or inclusion after running the same workload, region, and observation window.
Where FRB fits
FRB Agent is a Windows execution assistant for user-configured EVM workflows. It does not replace Flashbots or another provider. Operators select endpoints and remain responsible for simulation, wallet permissions, builder policy, and confirmation.
Read the Flashbots private RPC guide for wallet configuration and Flashbots bundles explained for searcher mechanics.
FAQ
Which Ethereum private RPC is best?
There is no universal answer. First decide whether the user needs wallet protection or bundle submission, then verify the current route semantics.
Does builder multiplexing ensure inclusion?
No. It expands the builders selected to receive a submission. Inclusion still depends on validity, economics, and block construction.
Is a private transaction confidential forever?
No. Included transactions become public on-chain, and provider policies define pre-inclusion handling.
Primary sources
Related Articles
Further reading & tools
Discussion
No notes yet. Add the first observation, or share the link with your team on X (@MCFRB).