Public, private, and dedicated RPC endpoints, explained

Every wallet and onchain app talks to a blockchain through an RPC endpoint: a URL that accepts requests like "what is this address's balance?" and "broadcast this transaction," and forwards them to a node running that chain's software. Most wallets ship with a default endpoint shared by every user of that wallet. The nodes behind that default are usually run by professional providers, but inside it you are one anonymous user among millions: you share the wallet's allocation with everyone else, you cannot see or debug your own requests, and you cannot raise your limits when your usage grows. A private RPC endpoint fixes that by giving you a connection of your own, with your own metered quota, from a provider you choose.

Before setting one up, it is worth knowing that "private RPC" here can mean a few different things:

• A private RPC endpoint. A URL with your API key embedded in it, served by a node provider's managed infrastructure, like Alchemy's RPC API. "Private" means only you can use that particular API URL, so your requests never queue behind a crowd. This is what most wallets and apps mean by the term.
• Private transactions. Transaction routing that keeps a transaction out of the public mempool (the waiting room where pending transactions sit in plain view) until it is included in a block. This is what protects a transaction from MEV bots. Private transactions are a feature some RPC providers add to their endpoints, but it isn't necessarily a part of every private RPC endpoint.
• Private, single-tenant infrastructure. Blockchain nodes reserved for one customer, for workloads with isolation, latency, or customization requirements that shared machines cannot meet, like Alchemy's Dedicated Clusters.

These three definitions are not competing options. They are layers: a private endpoint is the entry point, private transaction routing is a feature a provider can attach to it, and single-tenant infrastructure is what you graduate to when sharing itself becomes the problem. This guide explains each of these privacy options and how they compare.

What is a private RPC endpoint?

A private RPC endpoint is an RPC endpoint with a unique URL that only the owner can use, giving you your own authenticated lane into a node provider's fleet instead of the open queue of a public gateway.

Think of it like an apartment building. A private endpoint gives you your own key and your own front door, but the building's plumbing and power are shared with every other tenant. That sharing is what makes a private endpoint free to create and instant to provision: your URL is yours alone, while the node fleet behind it is operated at scale for many customers. Our fleet at Alchemy is the same infrastructure that powers $1T+ in annual transaction volume for teams like Robinhood, Coinbase, and Polymarket, and you can access that same node fleet infrastructure for free.

When you create an Alchemy account, the endpoint URL embeds an API key, which is what makes your connection private. The nodes are still shared, but your request quota is not: we meter usage per key, so you have a reserved slice of throughput that no one else's traffic can consume. A public endpoint works the other way around, with one pool of capacity rationed across every anonymous caller, usually per IP address, so your effective limit shrinks as the crowd grows.

Compared with sharing a wallet's default endpoint or calling a public one, a private endpoint gets you four things:

• Speed. Your requests hit a fleet tuned for low latency instead of queuing behind thousands of strangers in a public endpoint. You can compare providers on live latency benchmarks before choosing one.
• Accurate data. Nodes that lag behind the head of the chain serve stale balances and cause failed transactions. A managed fleet keeps its nodes current, so your wallet and apps see the chain as it is now.
• Reliability. During airdrops, mints, and volatile trading windows, public endpoints degrade first, because their shared pool is exactly what everyone rushes at once. With an API key, your keyed throughput is unaffected by that crowd, and keeping the fleet behind your endpoint performant and serving all of your traffic is the provider's job.
• Visibility. Public endpoints are often anonymous. With your own endpoint you can see every request, debug failures, and set alerts, which matters the first time a transaction silently fails.

For developers, using the endpoint in code is a one-line change: it is a standard JSON-RPC URL, so you pass it to ethers, viem, or web3.py as the provider URL, and a wss:// version of the same URL serves subscriptions. Since the key rides in the URL, protect your URL if it ships in a frontend: the dashboard lets you restrict a key to specific domains and IP addresses.

How do public, private, and dedicated endpoints compare?

RPC access comes in three tiers, and each column to the right buys you more isolation.

The real difference between the first two columns is accountability, not competence. Public RPC endpoints are run by chain foundations, volunteers, and providers offering a free sample, and many are run well. But none of them owe you anything: no capacity, no uptime commitment, no guarantee of current data, and no one to call when requests start failing. They are fine for a quick test.

A private endpoint on a managed provider is the right default for almost everyone: individual users who want faster wallet transactions, developers building apps, and production teams serving real traffic. The provider is accountable for keeping the fleet fast, current, and up, and publishes its measured performance so you can hold it to that.

Beyond those needs, Dedicated Clusters also exist for the narrow set of workloads with requirements that shared infrastructure cannot satisfy by design. Note what the customization row in the table above implies: a private endpoint serves the same standard APIs to every customer, because everyone shares the same nodes. Only single-tenant infrastructure can run code or configurations that are yours alone.

Do private endpoints protect transactions from MEV?

Not by default, and this is where the second meaning of "private RPC" can cause confusion. The "private" in a private endpoint refers to who can use the URL endpoint. The transactions you send through it still enter the public mempool on most networks and with most providers, where MEV bots can see them before they are mined and front-run or sandwich them.

Keeping a transaction out of the public mempool until it is included in a block requires private transaction routing, and that is a per-provider feature, not a standard part of the RPC stack. Some providers do not offer it at all; others sell it as an add-on or a separate endpoint.

At Alchemy, we offer MEV protection for free on Ethereum, Solana, Base, Arbitrum, and BNB Smart Chain to customers who send their write traffic exclusively through us. Transactions sent through our standard endpoints are routed through private submission channels automatically. Instead of being gossiped across the public network for anyone to inspect, they go straight to the parties who assemble blocks, such as trusted block builders on Ethereum.

The exact channel differs per chain, but the effect is the same: your transactions stay hidden until they are in a block, which shields them from front-running and sandwich attacks. This requires no configuration, costs nothing extra, and does not worsen your execution price. And to be explicit about whose side the routing is on: we never front-run our customers' transactions or extract value from their order flow. The only MEV in our pipeline is the kind that works in your favor, like better execution prices.

The exclusivity requirement is how the protection works, not fine print. A transaction is protected only if every copy of it stays out of the public mempool. If you multiplex your writes, broadcasting the same transaction through multiple providers for redundancy, the copies sent elsewhere land in public mempools where MEV bots can see them, and that transaction loses its protection.

If you are evaluating providers and MEV protection matters to your users, ask for it by name. An endpoint being "private" tells you nothing about how it routes transactions.

How do you create a private RPC endpoint?

Creating a private RPC endpoint is straightforward with any RPC provider. Simply create an account or login, and many providers will offer you a free API key with some usage limits upon account creation, no credit card required (hint: we're talking about us).

From there, select the chain and network you want to use the endpoint for. At Alchemy, all you need is one API key to access any of the 100+ networks we support, and each network gets its own URL (eth-mainnet, base-mainnet, etc.) with your key attached. Remember: your URL contains your API key, so treat it like a password.

For developers testing their application, you will then need to connect your wallet to your new endpoint, which you can do by opening your wallet of choice and opening the network selector. You will enter the details of the chain you want to connect to as well as your private RPC URL. Once that's done, all transactions associated with that wallet will route through your private endpoint!

When is a private endpoint not enough?

A private endpoint reserves your own slice of throughput, but the machines serving it are still shared with other customers. For the vast majority of workloads that is exactly the right trade: instant provisioning, elastic scaling, and usage-based pricing with no capacity planning.

However, a small set of workloads has requirements that a shared fleet cannot satisfy by design:

• Custom code on the node. Security and forensics teams run bespoke tracers and modified node clients. A shared fleet cannot host one customer's custom code, because every customer shares the same node runtime.
• Regulatory isolation. Regulated financial institutions need to prove that no other customer's traffic, code, or data touched their environment. On multi-tenant hardware, that proof is impossible by definition.
• Regional latency. Trading firms competing on speed need nodes placed in a specific region: next to their own servers to shave round-trip time off reads, or near a rollup's sequencer (the service that receives and orders that rollup's transactions) so submitted transactions arrive sooner. Shared fleets are placed for aggregate performance, not for one customer's geography.
• Unbounded historical queries. Oracles, indexers, and analytics platforms need unlimited getLogs ranges and heavy archive access, which shared fleets rate-limit to protect other tenants.

For those workloads, the next step up is a product like Alchemy's Dedicated Clusters: single-tenant node clusters that we provision, operate, and maintain, configured to your requirements. Each cluster runs redundant nodes per chain, single-tenant isolation covered by our SOC 2 Type II audit, deployment in the region you choose, and a fixed monthly price based on provisioned capacity. For spikes beyond the cluster's provisioned capacity, traffic can automatically fail over to our shared fleet instead of returning errors; teams whose isolation requirements rule that out can size the cluster for peak load instead. Teams like Blockaid use Dedicated Clusters to run custom tracers securing $312B+ in assets.

If you are weighing the decision, our guide to choosing between shared and dedicated infrastructure walks through it in detail, and there are deeper dives on how dedicated infrastructure works and how to evaluate dedicated providers. Teams currently running their own nodes can see what migrating to dedicated infrastructure involves. It is an endpoint swap, not a rebuild.

Get a faster connection to the chain

Whichever tier fits, the upgrade path starts the same way. Create a private RPC endpoint on the free tier in a couple of minutes, point your wallet or app at it, and get faster, more reliable access to every major network. If your workload has isolation, latency, or customization requirements that shared infrastructure cannot meet, talk to our team about Dedicated Clusters.

Frequently asked questions

What is a private RPC endpoint?

A private RPC endpoint is an RPC endpoint with a unique URL that only the owner can use, giving you your own authenticated connection to a node provider instead of a shared public gateway. The URL embeds an API key, and usage is metered per key, so no one else's requests can consume your capacity.

What is the difference between a public and a private RPC endpoint?

A public RPC endpoint is open to everyone and run on a best-effort basis: no rate-limit guarantees, no uptime commitments, and no one accountable when it degrades. A private endpoint is a keyed URL on a provider's managed fleet, with rate limits that scale with your plan, published uptime performance, and a dashboard showing your traffic.

Does a private RPC endpoint make my transactions private?

Not by itself. "Private" in the name refers to who can use the endpoint: every transaction still settles publicly onchain, and the provider operating the endpoint can see the requests you send, as with any RPC provider. Keeping transactions out of the public mempool before inclusion requires private transaction routing, which is a per-provider feature. Alchemy includes it on Ethereum, Solana, Base, Arbitrum, and BNB Smart Chain; many providers do not offer it.

Does Alchemy protect my transactions from MEV?

Yes. Standard Alchemy RPC endpoints on Ethereum, Solana, Base, Arbitrum, and BNB Smart Chain include MEV protection at no extra cost. Transactions are routed privately so MEV bots cannot see them before inclusion, which prevents front-running and sandwich attacks without changing your send-transaction flow or worsening your execution price. Protection requires sending your write traffic exclusively through Alchemy: if you multiplex the same transaction to multiple providers, the copies sent elsewhere enter public mempools where MEV bots can see them, and that transaction loses protection.

What is the difference between a private RPC endpoint and a dedicated node?

A private RPC endpoint is a keyed URL served by shared, multi-tenant infrastructure: the URL is exclusive, the nodes behind it are not. A dedicated node or cluster is single-tenant infrastructure reserved for one customer, used for workloads that need custom code on the node, regulatory isolation, specific regions, or unbounded historical queries. Alchemy offers both, and most workloads run best on a private endpoint backed by shared infrastructure.

Do I need technical skills to create a private RPC endpoint?

No. Creating a private RPC endpoint with Alchemy takes a couple of minutes: create a free account, create an app, and copy the RPC URL it generates. Adding it to a wallet like MetaMask is a settings change, not a coding task.

Can I connect my private RPC endpoint to MetaMask?

Yes. Open MetaMask's network menu, add a custom network, and paste your private RPC URL along with the chain ID, currency symbol, and block explorer for your network. Once saved, all activity on that network routes through your endpoint.

Which blockchains does Alchemy support for private RPC endpoints?

Alchemy supports private RPC endpoints for Ethereum, Solana, Base, Polygon, Arbitrum, Optimism, and more than 100 other networks across every major layer 1 and layer 2 ecosystem.

When should I move from a private endpoint to dedicated infrastructure?

Move to dedicated infrastructure when your workload has a hard requirement shared infrastructure cannot meet: running custom tracers or binaries on the node, proving single-tenant isolation for compliance, deploying in a specific region for latency, or running unbounded archive and log queries. If none of those apply, a private endpoint on shared infrastructure is the better default.