Polygon Private RPC Explained: How It Works

Almost every interaction with Polygon goes through an RPC endpoint. Your wallet uses one to read balances, your dApp uses one to call contracts, and your bot uses one to send trades. Most of the time nobody thinks about where those requests go. A Polygon private RPC is what you use when you do care, specifically about what happens to your transactions between the moment you sign them and the moment they land in a block.

In short: a Polygon private RPC is a JSON-RPC endpoint that accepts signed transactions and forwards them through private infrastructure toward block production, instead of broadcasting them to the public mempool. It speaks the same protocol as any other RPC, so wallets, bots and backends can use it with little or no code change.

What an RPC endpoint does

Polygon PoS nodes expose the Ethereum JSON-RPC interface. Requests fall into two groups:

• Reads ask for state: eth_getBalance, eth_call, eth_getTransactionReceipt, eth_getBlockByNumber and so on. They change nothing.
• Writes submit something that will change state. In practice that means one method: eth_sendRawTransaction, which takes a signed transaction and hands it to the network.

Reads are about speed, reliability and rate limits. Writes are where privacy comes in, because what the endpoint does with your signed transaction determines who can see it before it is included.

What a standard RPC does with your transaction

A standard endpoint, whether free and shared or paid and dedicated, passes your transaction to a Polygon node. That node validates it, adds it to its transaction pool and gossips it to its peers. Within moments the transaction is in the public mempool, visible to anyone who runs a node or subscribes to pending transactions.

That visibility is how the network normally works, and for many transactions it is harmless. For swaps, liquidations, large transfers or any transaction whose value depends on ordering, it creates an opportunity for others to act first. We cover those risks in MEV protection on Polygon.

What makes an RPC private

A private RPC changes the write path. When it receives eth_sendRawTransaction (or a dedicated method, depending on the provider), it does not gossip the transaction to the public peer-to-peer network. Instead it forwards it through a private route toward the parties that build blocks.

A typical private RPC has a few layers:

1. An authenticated endpoint. Requests carry an API key, so the provider knows who is submitting and can apply limits and pricing.
2. Validation. The transaction is checked before it is forwarded: correct chain ID, valid signature, sensible fees and gas limit. Invalid transactions are rejected with a clear error instead of being passed on.
3. Private routing. The transaction travels over the provider’s own infrastructure toward block production instead of the public gossip network.
4. Status reporting. The provider tells you what happened: accepted, forwarded, included or not. Hyperstrate, for example, reports received, private route established, propagated, included and settled.

Settlement is untouched. Once a block producer includes the transaction, it is part of the Polygon chain like every other transaction.

Why block production matters on Polygon

Since the Rio upgrade in October 2025, Polygon PoS uses a model Polygon calls Validator-Elected Block Producer (VEBloP). Validators elect a small pool of block producers, and one producer builds blocks for a longer span, with backups ready to take over. Polygon says this removes chain reorganizations and shortens block times. For private submission, it means the route a transaction takes toward that producer, and who sees it on the way, is what decides whether it was ever exposed.

What a private RPC can and can’t hide

It can hide a pending transaction from the public mempool. Bots that monitor the mempool for trades to frontrun or sandwich will not see it.

It cannot hide:

• The transaction after inclusion. Sender, recipient, amounts, call data and fees are public onchain and on Polygonscan.
• The transaction from the private route itself. The provider and anything it forwards to see the transaction before inclusion. That is unavoidable: somebody has to deliver it to block production.
• Effects that happen after inclusion, such as other traders reacting to the new price.

This is why it is worth understanding a provider’s model rather than treating “private” as a guarantee.

Private RPC vs public and dedicated RPC

People often use “private RPC” to mean a paid or dedicated endpoint. Those are different things. A dedicated endpoint gives you your own capacity and better reliability, but it may still broadcast your transactions to the public mempool. Private routing is about the write path, not about who else shares the server. We compare all three in public RPC vs private RPC on Polygon.

How applications use a private RPC

The most common setup keeps reads and writes apart:

• Reads go to your existing RPC provider.
• Signed transactions go to the private endpoint.

Wallets can offer this as an optional “private” or “protected” sending mode. Bots and backends usually switch one URL in their configuration. The step-by-step version is in how to send private transactions on Polygon.

Questions to ask a Polygon private RPC provider

• Routing: how does a transaction reach block production, and who can see it before inclusion?
• Methods: does the endpoint accept eth_sendRawTransaction, a dedicated method, or both? Does it also serve reads?
• Authentication: how are API keys issued, scoped and rotated?
• Status: how do you learn whether a transaction was included, and what happens if it was not?
• Failure handling: are transactions retried, and for how long?
• Pricing: what do you pay for transactions that land, that are attempted but do not land, and that are never attempted?
• Independence: who operates the service? Hyperstrate, for instance, is an independent provider and is not affiliated with Polygon Labs.

Frequently asked questions

Is a Polygon private RPC the same as a private mempool?

They solve the same problem from slightly different angles. A private mempool is a holding area for transactions that is not shared publicly; a private RPC is the endpoint you submit to. In practice, a private RPC delivers your transactions into a private path instead of the public mempool.

Does a private RPC make my transaction anonymous?

No. Once included, the transaction and its sender are public onchain. A private RPC only affects visibility before inclusion.

Can I use a private RPC from MetaMask or another wallet?

Wallets that let you add a custom RPC can submit through it, as long as the endpoint accepts the requests the wallet sends. Check your provider’s documentation for wallet support and authentication.

Will a private RPC make my transactions faster?

Not necessarily. Inclusion speed depends on fees, network conditions and block production. A private RPC is about who can see your transaction before it is included.

Conclusion

A Polygon private RPC looks like any other RPC from the outside. What sets it apart is what happens to a signed transaction after you submit it: private routing toward block production instead of broadcast to the public mempool. It cannot make onchain data private and it does not replace sensible slippage limits, but it removes the pre-inclusion window that mempool-watching bots depend on.

Hyperstrate provides one authenticated JSON-RPC endpoint for private transaction submission on Polygon. See how it works, browse the developer examples, or contact us.