Summary
A MEV blocker is an RPC endpoint that changes where your signed transactions go before they land in a block. Instead of broadcasting a raw transaction to the public mempool, you send it to a private relay or order-flow auction that hides it from frontrunning and sandwich bots, and in many designs returns part of the extracted value to the sender.
That makes a MEV blocker a routing decision, not a chain feature. You keep the same chain ID and the same signing flow; you swap the RPC URL your wallet or backend uses for eth_sendRawTransaction. Reads, logs, and state queries still need a normal full node behind the scenes, which is why teams usually pair a protection endpoint with a standard RPC provider such as OnFinality's RPC API for everything that isn't transaction submission.
This article explains how MEV blockers work, what they do and do not protect against, and how to decide whether to route user transactions through one — plus how to keep your read path and failover healthy once you do.
Key Takeaways
- A MEV blocker is an RPC endpoint that routes signed transactions through a private mempool or order-flow auction instead of the public mempool.
- It mainly protects against frontrunning and sandwich attacks on transaction submission; it does not change consensus, gas pricing, or your read path.
- Protection endpoints are usually chain-specific and often Ethereum-focused, so verify chain ID, supported methods, and revert behavior before switching.
- Most designs only intercept
eth_sendRawTransaction;eth_call,eth_getLogs, and trace methods still need a conventional full node. - Keep a standard RPC as a fallback so transaction submission does not become a single point of failure.
- Test on a testnet or with small value first, and monitor inclusion rate, revert rate, and rebate behavior after rollout.
The short answer: a MEV blocker is a transaction router
A MEV blocker is an RPC endpoint you point your wallet or backend at when you want your transactions to avoid the public mempool. You sign locally as usual, then send the raw transaction to the blocker. The blocker forwards it to a private relay, a builder network, or an order-flow auction, where searchers can bid for the right to include it. Because the transaction is not visible in the public mempool before inclusion, bots cannot easily frontrun or sandwich it.
The important nuance: the blocker is not a chain, a rollup, or a consensus change. Your transaction still settles on the same chain with the same chain ID. What changes is the path between your signature and the block builder.
Most MEV blockers also act as a partial refund mechanism. If your transaction creates backrunning opportunities, searchers pay for them, and part of that value can flow back to you. The exact refund model, revert behavior, and privacy level differ by endpoint, so read the provider's endpoint reference rather than assuming one behavior.
- Same chain, same signing flow — only the submission URL changes.
- Protection applies to transaction submission, not to reads, logs, or traces.
- Refund and revert behavior varies by endpoint path, so test before relying on it.
Decision guide: should your transactions go through a blocker?
Use this table to decide per workload rather than per project. Many teams route only the transaction-submission path through a protection endpoint and keep everything else on a conventional RPC provider.
- Route selectively: protection for value-bearing user transactions, standard RPC for everything else.
- Keep a documented fallback endpoint and a timeout so submission never hangs indefinitely.
| Criterion | What to check | Why it matters |
|---|---|---|
| Workload | Does the transaction create visible value in the mempool (swaps, mints, liquidations, NFT drops)? | If yes, frontrunning and sandwich risk is real and a blocker is worth evaluating. Routine transfers and admin transactions usually gain little. |
| User-facing vs backend | Is the transaction signed by end users in a wallet, or by your backend signer? | Wallet-level protection is a config change users can opt into. Backend submission needs a code path you control and monitor. |
| Chain support | Does the blocker support your chain ID and the methods you call? | Protection endpoints are often chain-specific; sending to the wrong chain or unsupported method fails silently or with confusing errors. |
| Revert policy | Does the endpoint drop reverting transactions, or include them and charge gas? | This changes your gas accounting and your retry logic, especially for bots and automated strategies. |
| Fallback path | What happens if the blocker is slow, down, or rejects your transaction? | Submission should not become a single point of failure for your product. |
What a blocker actually protects against — and what it doesn't
The core protection is against frontrunning and sandwich attacks on transactions that would otherwise sit in the public mempool. By hiding the transaction until inclusion, the blocker removes the window bots use to insert transactions around yours.
It does not remove MEV from the system. Value can still be extracted through backrunning, and the blocker's auction is one of the places that value gets priced. It also does not protect you from bad pricing in your own transaction, from contract-level exploits, or from reorgs. And it does not replace a healthy read path: if your app cannot read state or logs reliably, protection on submission will not save the user experience.
- Treat protection as one layer: it reduces a specific attack surface, it does not replace transaction hygiene.
| Criterion | What to check | Why it matters |
|---|---|---|
| Threat | Yes — transaction hidden until inclusion | The main reason teams adopt a blocker. |
| Backrunning value capture | Partially — via auction and possible refunds | Refund models differ; check the endpoint reference. |
| Failed-transaction gas | Depends on endpoint revert policy | Affects cost and retry logic for automated senders. |
| Reorgs and finality | No | Still your responsibility to handle confirmations. |
| Read-path reliability | No | Pair with a standard RPC for eth_call, eth_getLogs, and traces. |
Wiring a protection endpoint into a wallet or backend
For end users, the change is a network entry in the wallet: same chain ID, same currency symbol, same explorer, different RPC URL. For backends, the change is narrower — you typically keep your normal provider for reads and send only raw transactions to the protection endpoint.
The example below shows the split pattern in JavaScript. It uses a standard JSON-RPC provider for reads and a separate protection URL for submission. Replace the placeholder with the endpoint your chosen blocker publishes for your chain.
- Keep two clients: a read client and a submission client.
- Set an explicit timeout on submission and fall back to your standard RPC if the protection endpoint does not respond.
- Log the endpoint used per transaction so you can attribute inclusion and revert behavior later.
| Criterion | What to check | Why it matters |
|---|---|---|
| Config item | Must match the target chain exactly | A mismatch sends funds or transactions to the wrong network context. |
| Read RPC URL | Your standard provider endpoint | Used for eth_call, eth_getLogs, eth_getTransactionReceipt, and traces. |
| Submission RPC URL | The blocker's documented endpoint for your chain | Only raw transaction submission should go here. |
| Fallback URL | Your standard provider endpoint | Prevents submission outages from blocking your product. |
| Timeout | A few seconds, tuned to your UX | Avoids indefinite hangs when the protection path is degraded. |
Where OnFinality fits next to a protection endpoint
A MEV blocker answers one question: where do signed transactions go? Everything else — balance reads, event logs, contract calls, transaction receipts, trace data, and WebSocket subscriptions — still needs a full node. That is the layer OnFinality provides through its RPC API and dedicated node offerings on supported networks.
A common production shape is: a protection endpoint for eth_sendRawTransaction, a managed RPC for reads and receipts, and a dedicated node when you need predictable throughput or custom mempool policy. If you are still selecting the read side, the RPC provider selection guide covers workload, archive, trace, and failover criteria.
Two practical checks before you commit: confirm the chain you are protecting is supported on the read side, and confirm your fallback path is a provider you already trust for submission. Review RPC pricing to size the read side against your expected request volume.
- Protection endpoint: submission only.
- Managed RPC: reads, logs, receipts, subscriptions.
- Dedicated node: throughput control, custom policy, private peering.
Rollout and monitoring checklist
Switching submission paths is a production change. Roll it out in stages and watch the signals that tell you whether protection is working as intended.
- Start with a small share of traffic or a testnet where available.
- Alert on fallback frequency and inclusion-rate drops, not just on errors.
- Re-read the provider's endpoint reference after any change; paths and policies can differ between protection modes.
| Criterion | What to check | Why it matters |
|---|---|---|
| Signal | Transactions land in a reasonable number of blocks | A sudden drop suggests the protection path is degraded. |
| Revert rate | Stable or lower than before | Revert policy changes can shift gas costs. |
| Submission latency | Within your timeout budget | Slow submission hurts UX more than slow reads. |
| Fallback frequency | Low and explained | Frequent fallback means the primary path is unreliable. |
| Refund or rebate behavior | Matches the provider's documented model | Unexpected refunds or none at all signal a misconfigured endpoint. |
Key Takeaways
A MEV blocker is a routing choice for transaction submission, not a chain upgrade. It hides signed transactions from the public mempool to reduce frontrunning and sandwich risk, and some designs return part of the extracted value to the sender. It does not fix your read path, your gas pricing, or your confirmation handling.
The practical pattern is a split stack: a protection endpoint for raw transaction submission, a reliable standard RPC for reads, logs, receipts, and traces, and a fallback path so submission never becomes a single point of failure. Test the revert policy and refund model before you roll it out, then monitor inclusion rate, revert rate, and fallback frequency.
If you need the read side of that stack, start with OnFinality's RPC API, check supported networks, and review RPC pricing to size it for your workload.
- Protection is one layer; reliability of the read path is another.
- Verify chain ID, supported methods, and revert policy per endpoint.
- Always keep a documented fallback for submission.
Frequently Asked Questions
Is a MEV blocker the same as a private RPC?
They overlap. A MEV blocker is a private submission path with MEV-specific routing, often including an order-flow auction and refunds. A private RPC may simply hide transactions without an auction. Check the provider's documentation for what happens after submission.
Does using a MEV blocker change my chain ID or signing flow?
No. You sign the same transaction for the same chain. Only the RPC URL used for raw transaction submission changes. Reads and receipts still come from a standard node.
Can a MEV blocker stop all MEV extraction?
No. It mainly reduces frontrunning and sandwich risk on submission. Backrunning and other forms of value extraction can still occur, and the blocker's auction is one place that value gets priced.
Do I still need a normal RPC provider if I use a blocker?
Yes, in most setups. Methods like eth_call, eth_getLogs, eth_getTransactionReceipt, and trace calls need a full node. A managed RPC such as OnFinality's RPC API covers that layer.
What happens if the protection endpoint is down?
If you have no fallback, submission stalls. Configure a timeout and a fallback to a standard RPC you trust, and alert on fallback frequency so you notice degradation early.
Should every transaction go through a blocker?
Usually not. Route value-bearing user transactions where frontrunning risk is real. Routine transfers and admin operations often gain little and add an extra dependency.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
