Public RPC Endpoint Risks: What to Know Before Going to Production

What Are Public RPC Endpoints and Why Do They Seem Attractive?

A public RPC endpoint is a JSON-RPC or WebSocket endpoint that anyone can access without authentication. Examples include the ones listed in the Solana documentation and the public endpoints provided by various projects. They are attractive because they are free, require no sign-up, and are easy to test with.

However, 'free' comes at a cost. Public endpoints are shared infrastructure, often operated by community members or as a courtesy by projects. They are not designed for production workloads. The risks range from rate limiting to data inconsistency, and they can directly impact your dApp's reliability and user trust.

To understand the scale of the problem, consider that a single public endpoint might serve thousands of concurrent users, each with different usage patterns. This shared nature means that one user's heavy load can degrade the experience for everyone else. Moreover, public endpoints are often hosted on modest infrastructure without the redundancy needed for high availability. They may be running on a single node or a small cluster, making them susceptible to outages if the node fails or needs maintenance.

Another subtle issue is that public endpoints are often provided as a courtesy by projects or community members. This means they can be taken down at any time without notice. For example, a project might deprecate its public endpoint after a major upgrade, leaving developers who relied on it scrambling to find an alternative. This lack of stability is a critical risk for any application that needs consistent access to the blockchain.

• No authentication means no accountability and no service-level agreement (SLA).
• Shared resources lead to unpredictable performance and availability.
• Public endpoints may be deprecated or shut down without notice.
• They are often hosted on limited infrastructure without redundancy, increasing the risk of downtime.

Rate Limits: The Most Immediate Risk

Public RPC endpoints impose strict rate limits to protect their infrastructure from abuse. These limits are often undocumented and can change without notice. For example, a public Solana endpoint might allow only a few requests per second per IP, which is insufficient for any dApp with real user traffic.

To observe rate limits yourself, you can use curl to send a burst of requests and measure the response times and error codes. Here's a simple test:

for i in {1..20}; do curl -s -o /dev/null -w "%{http_code} %{time_total}\n" -X POST https://api.mainnet-beta.solana.com -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'; done

Data Consistency: The Hidden Danger of Multiple Servers

Public RPC endpoints often sit behind load balancers that route requests to multiple backend nodes. These nodes may not be perfectly synchronized, especially on networks with fast finality like Solana. As a result, you might get different responses for the same query depending on which node handles your request.

For example, querying getBalance for an account might return different values if the nodes are at different block heights. This inconsistency can break your application's logic, especially if you rely on precise account states for transactions.

To test for consistency, you can send the same request multiple times and compare the results. Use a script to query a public endpoint and a dedicated endpoint (e.g., from OnFinality) and compare the result fields. You'll likely see discrepancies on the public endpoint.

The root cause of this inconsistency is that nodes may be at different block heights due to network propagation delays. While most networks have mechanisms to ensure eventual consistency, the time window for inconsistency can be significant, especially on high-throughput networks. For applications that need to read the latest state, this can lead to errors such as attempting to sign a transaction based on stale data.

Moreover, some public endpoints may be configured to serve from a snapshot or a lagging node to reduce load, which can introduce even larger discrepancies. This is particularly dangerous for applications that need to construct transactions based on current account states, as they might end up with invalid transactions.

curl -s -X POST https://api.mainnet-beta.solana.com -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}' && echo "" && curl -s -X POST https://solana-rpc.publicnode.com -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}'

Security and Authentication: Why No Auth Is a Risk

Public RPC endpoints require no authentication, which means anyone can use them. This opens the door to several security risks:

First, your requests are not encrypted end-to-end if you use plain HTTP (though most public endpoints use HTTPS). More importantly, without authentication, you cannot protect your data from being intercepted or tampered with in transit if the endpoint is compromised.

Second, malicious actors can use public endpoints to launch attacks, such as sending spam transactions or exploiting vulnerabilities. If your dApp relies on a public endpoint, you are at the mercy of the endpoint's security posture. A compromised public endpoint could return malicious data, leading to incorrect transaction signing or fund loss.

Third, public endpoints are often targeted by attackers because they are open and have no access control. They might be used to perform denial-of-service (DoS) attacks on the underlying node, which can cause the endpoint to become unavailable for everyone. This is a common issue with public infrastructure.

Managed providers mitigate these risks by offering authenticated endpoints with API keys. For example, OnFinality's RPC Assistant allows you to generate API keys and restrict access. This ensures that only your application can use the endpoint, and you can revoke keys if compromised.

Additionally, managed providers often implement additional security measures such as IP whitelisting, request signing, and encryption in transit. These features are essential for protecting sensitive data and ensuring the integrity of your requests.

Reliability and Uptime: No Guarantees

Public RPC endpoints have no uptime guarantees. They can go down for maintenance, be rate-limited for everyone, or simply disappear. This is unacceptable for production applications that need 24/7 availability.

To measure reliability, you can set up a simple monitoring script that pings the endpoint every minute and logs the response time and status. Over a week, you'll likely see periods of high latency or downtime. For a more systematic approach, refer to our guide on monitoring RPC endpoints.

In contrast, commercial providers offer SLAs with uptime commitments (e.g., 99.9% or higher). OnFinality, for instance, provides network-specific endpoints with redundant infrastructure and automatic failover.

The lack of guarantees also means that public endpoints may be subject to maintenance windows without prior notice. For example, a node operator might need to upgrade the software and take the endpoint offline for a few minutes. During this time, your dApp will be unable to access the blockchain, leading to downtime for your users.

Furthermore, public endpoints are often hosted on a single server or a small cluster, which means they are vulnerable to hardware failures, network issues, and even power outages. Without redundancy, any failure can result in extended downtime.

When to Use Public Endpoints vs. Dedicated Endpoints

Public endpoints are suitable for development, testing, and low-traffic prototypes. If you are building a hackathon project or a simple script, they are fine. However, for any production dApp, you should use a dedicated RPC endpoint from a managed provider.

Here's a decision checklist:

• If your dApp handles real user funds, use a dedicated endpoint.

• If you expect more than a few requests per second, use a dedicated endpoint.

• If you need consistent data for transaction building, use a dedicated endpoint.

• If you require authentication and access control, use a dedicated endpoint.

• If you need an SLA and support, use a dedicated endpoint.

For a deeper comparison, read our article on how to choose an RPC provider and best RPC providers for Web3 projects.

How to Migrate from Public to Dedicated Endpoints

Migrating is straightforward. First, sign up for a managed RPC service like OnFinality. Then, create an endpoint for your target network (e.g., Solana or Ethereum). You'll get a URL with an API key.

Update your application's configuration to use the new endpoint. For example, in a JavaScript dApp using @solana/web3.js, you would change the Connection URL:

const connection = new Connection('https://solana-mainnet.onfinality.io/rpc?apikey=YOUR_API_KEY');

Tradeoffs: Cost vs. Reliability

The main tradeoff is cost. Dedicated endpoints are not free, but they are often inexpensive compared to the cost of downtime or data inconsistency. For example, OnFinality offers flexible pricing with a free tier for development and affordable paid plans for production.

Consider the cost of a public endpoint failure: if your dApp goes down for an hour, you might lose user trust, revenue, or even face security incidents. The cost of a managed endpoint is negligible in comparison.

To quantify the potential impact, think about your dApp's revenue per hour. If you have 1,000 active users and each generates $0.10 in revenue per hour, an hour of downtime costs $100. A managed RPC plan might cost $50 per month, so even a single hour of downtime per month would justify the expense.

Moreover, the cost of a dedicated endpoint is not just about uptime; it also includes the value of consistent data, security, and support. These factors can save you development time and prevent costly bugs.

In summary, public RPC endpoints are a risky shortcut. For production, invest in a reliable, secure, and consistent RPC infrastructure. Start by exploring the OnFinality API service and network options to find the right fit for your project.