What are private RPC endpoints for dapps and when should you use them?

Quick recommendation: when does your dapp need a private endpoint?

Before you compare providers, decide which access model fits your workload. The table below maps common dapp scenarios to the right endpoint type.

If your dapp is past the prototype stage and you expect steady traffic, a private RPC endpoint is usually the right next step. It gives you a unique URL with an API key, so your requests no longer queue behind every other user of a shared public endpoint. You also get your own rate limits and usage analytics, which makes debugging and capacity planning much easier.

For most production dapps, a private shared endpoint strikes the right balance between cost and performance. Only move to a dedicated node when you need consistent throughput, custom node configuration, or access to archive data and trace methods that shared endpoints often restrict.

What exactly is a private RPC endpoint?

An RPC endpoint is a URL that your dapp uses to talk to a blockchain node. It accepts JSON-RPC requests like "what is this address's balance?" or "broadcast this transaction" and forwards them to a node running the chain's software.

A private RPC endpoint is an endpoint with a unique URL that only you can use. It typically includes an API key or authentication token, giving you your own authenticated lane into the provider's infrastructure. "Private" here means exclusive to you, not anonymous or encrypted. It does not hide your transactions from the public mempool or protect you from MEV bots.

Private endpoints are different from private transactions. Private transactions are a separate feature that some providers offer to keep your transaction out of the public mempool until it is included in a block, which can reduce MEV risk. A private RPC endpoint does not do this by itself.

Public vs. private vs. dedicated: what's the difference?

It helps to think of these as three levels of access:

• Public endpoints are shared by everyone. They are free but have strict rate limits, no guarantees, and no support. They are fine for testing but not for production.
• Private shared endpoints are unique to you but still run on shared infrastructure. You get your own rate limits, better reliability, and usage analytics. This is what most production dapps use.
• Dedicated nodes are single-tenant infrastructure. You get your own node instance, which means consistent performance, full control over configuration, and no noisy neighbors. This is for high-throughput or data-intensive workloads.

The table below summarizes the key differences:

How to create a private RPC endpoint

Creating a private RPC endpoint is straightforward with most providers. Here's a general workflow:

1. Sign up for an account with an RPC provider like OnFinality.
2. Create an API key or project. This generates a unique URL with your key embedded.
3. Select the network you want to connect to (e.g., Ethereum, Solana, Base).
4. Copy your endpoint URL and use it in your dapp configuration.

For example, with OnFinality, you can get a private endpoint for any supported network by creating an API key in the dashboard. The URL looks something like:

https://your-project-id.region.rpc.onfinality.io

You then use this URL in your dapp's configuration. Here's an example with ethers.js:

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider(
  "https://your-project-id.region.rpc.onfinality.io"
);

const blockNumber = await provider.getBlockNumber();
console.log(blockNumber);

For viem:

import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";

const client = createPublicClient({
  chain: mainnet,
  transport: http("https://your-project-id.region.rpc.onfinality.io"),
});

const blockNumber = await client.getBlockNumber();
console.log(blockNumber);

What private endpoints do and don't do

Private endpoints primarily improve reliability and reduce failed submissions. They do not provide anonymity or privacy for your transactions. Here's a breakdown:

• Do: Give you a dedicated rate limit, so your requests are less likely to be throttled.
• Do: Provide better uptime and performance because you are not competing with a crowd.
• Do: Allow you to see your own usage metrics, which helps with debugging and capacity planning.
• Don't: Hide your transactions from the public mempool. Your transaction data is still visible to anyone watching the network.
• Don't: Protect you from MEV bots. For that, you need private transaction routing, which is a separate feature.

When a private endpoint is not enough

Private shared endpoints have limits. If your dapp needs any of the following, consider a dedicated node:

• Consistent high throughput: If you regularly hit your rate limits, a dedicated node gives you more headroom.
• Archive data: If you need historical state at any block, you need an archive node. Many shared endpoints only offer recent state.
• Trace methods: Methods like debug_traceTransaction are often restricted on shared endpoints for security reasons.
• Custom configuration: If you need to enable specific flags or run your own node version, a dedicated node is necessary.

How to evaluate RPC providers for private endpoints

When comparing providers, focus on these criteria:

Use this checklist when comparing providers, including OnFinality's RPC service.

Common pitfalls and troubleshooting

Even with a private endpoint, you may run into issues. Here are common problems and how to fix them:

• Rate limit exceeded (429): You are sending too many requests. Increase your plan or optimize your dapp to cache data and reduce redundant calls.
• Authentication errors (401): Your API key is invalid or missing. Double-check your endpoint URL and ensure the key is included correctly.
• WebSocket disconnects: If you use WebSocket for real-time data, ensure your provider supports it and that you handle reconnection logic.
• Slow responses: Check your geographic region. If your provider has endpoints closer to your users, use them.

Key Takeaways

• Private RPC endpoints give your dapp a unique, authenticated URL with dedicated rate limits and better reliability.
• They are different from private transactions, which protect against MEV.
• Public endpoints are for testing; private shared endpoints are for most production dapps; dedicated nodes are for high-throughput or data-heavy workloads.
• Evaluate providers based on rate limits, network coverage, WebSocket support, archive data, latency, and observability.
• Use a checklist to compare providers and choose the one that fits your dapp's needs.

Frequently Asked Questions

What is a private RPC endpoint?

A private RPC endpoint is a unique URL with an API key that only you can use. It gives your dapp its own authenticated lane into a node provider's infrastructure, with dedicated rate limits and better reliability.

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

A public endpoint is shared by all users and has strict rate limits. A private endpoint is unique to you, with custom rate limits and better performance.

Does a private RPC endpoint make my transactions private?

No. A private RPC endpoint does not hide your transactions from the public mempool. It only gives you a dedicated connection. For transaction privacy, you need private transaction routing, which is a separate feature.

When should I use a dedicated node instead of a private shared endpoint?

Use a dedicated node when you need consistent high throughput, archive data, trace methods, or custom configuration. For most production dapps, a private shared endpoint is sufficient.

How do I get a private RPC endpoint?

Sign up with an RPC provider like OnFinality, create an API key, select your network, and use the provided URL in your dapp. See RPC pricing and supported networks for more details.