How do I choose a Celo RPC provider for a production app?

Celo is an EVM-compatible Layer 1 with a mobile-first design history and a strong stablecoin and payments ecosystem. If you are building on Celo, the RPC endpoint is the layer between your app and the chain, and the provider you pick shapes how your app behaves under load, during reorgs, and when you need historical state. This page is written for developers and infrastructure buyers who already know they need an endpoint and are trying to decide what to run against it.

Quick recommendation: shared endpoint or dedicated node?

Start with the workload, not the provider logo. The right Celo RPC setup depends on three things: how many requests per second you send, whether you need historical state, and whether you can tolerate a shared endpoint during traffic spikes.

• Prototypes, scripts, and low-traffic dApps: a shared RPC API is usually enough. You get an HTTPS endpoint, standard JSON-RPC methods, and no node operations. OnFinality's Celo RPC API is a managed option in this category.
• Production apps with steady traffic and SLAs: look for a provider that offers both shared and dedicated tiers, so you can start shared and move to a dedicated node when your request profile grows. See RPC pricing for how tiers are structured.
• Indexers, analytics, and anything reading old blocks: you need archive access. Confirm archive support before you commit, because not every shared endpoint keeps full history.
• Trading bots, liquidation keepers, and real-time dashboards: you need low-latency reads plus WebSocket or streaming support, and a failover endpoint configured in your client.

If you are unsure, start with a shared endpoint, instrument your request volume and error rate for a week, then decide whether a dedicated node is justified.

Celo chain settings at a glance

Use these values when adding Celo to a wallet, a hardhat config, or a client library. They match the Celo mainnet configuration.

A wallet or client config looks like this:

{
  "chainId": "0x1a4",
  "chainName": "Celo Mainnet",
  "nativeCurrency": { "name": "CELO", "symbol": "CELO", "decimals": 18 },
  "rpcUrls": ["https://celo.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://celoscan.io"]
}

The chain ID 42220 is the decimal form; 0x1a4 is the same value in hex, which is what wallet_addEthereumChain expects. Getting this wrong is one of the most common causes of a wallet refusing to switch networks.

What your Celo workload actually stresses

Different Celo apps hit the RPC layer in different ways. Before comparing providers, map your traffic to one of these profiles.

If your profile is in the bottom three rows, a shared endpoint may still work, but you should verify archive support, log query caps, and WebSocket availability before you build around it.

Provider evaluation matrix

When you compare Celo RPC providers, score them against the criteria that match your workload. The table below lists the dimensions that matter most, with OnFinality as one option to evaluate alongside others.

Two practical checks that separate providers quickly:

1. Archive depth. Ask how far back eth_getLogs and eth_getBalance work. If the answer is vague, test it yourself against a block from several months ago.
2. Behaviour under load. Send a burst of eth_getLogs or eth_call requests and watch for rate-limit responses, timeouts, or truncated results.

Connecting and testing your endpoint

Once you have an endpoint, verify it before wiring it into your app. A single eth_chainId call confirms you are talking to Celo mainnet and not a testnet or a misconfigured proxy.

curl -s https://celo.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

A correct response returns 0x1a4, which is 42220 in decimal. From there, check the latest block and a historical call:

curl -s https://celo.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

In JavaScript, the same check with a client library is straightforward:

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

const client = createPublicClient({
  chain: celo,
  transport: http("https://celo.api.onfinality.io/public"),
});

const chainId = await client.getChainId();
const block = await client.getBlockNumber();
console.log({ chainId, block });

If you plan to use WebSocket subscriptions, confirm the provider exposes a wss:// endpoint for Celo and test a subscription before relying on it in production.

Failure modes and how to debug them

Most Celo RPC problems fall into a small set of categories. Match the symptom to the likely cause before you change providers.

A useful habit is to log the id and method of every failed request alongside the HTTP status. That makes it obvious whether failures cluster around one method, one time window, or one endpoint.

Running Celo in production: what to put in place

Before you go live, cover the basics that prevent most incidents:

• Failover. Configure a primary and a secondary endpoint in your client. If the primary returns errors or times out, switch automatically.
• Retries with backoff. Retry idempotent reads, but do not blindly retry writes. A retried eth_sendRawTransaction with the same signed payload is usually safe; a re-signed transaction with a new nonce is not.
• Block pinning for critical reads. For balances and contract state used in decisions, query a specific block number rather than latest.
• Monitoring. Track request rate, error rate, p95 latency, and head lag. A simple probe that calls eth_blockNumber every few seconds and compares the returned height to a reference is enough to catch a stalled endpoint.
• Archive planning. If you query history, confirm archive access is part of your plan before you need it.

If your traffic grows past what a shared endpoint handles comfortably, a dedicated Celo node gives you isolated capacity and predictable behaviour. OnFinality offers both managed RPC and dedicated node infrastructure, and you can compare tiers on the RPC pricing page. For the broader evaluation framework, see how to choose an RPC provider.

Key Takeaways

• Celo mainnet uses chain ID 42220 and the native CELO token; confirm both before debugging anything else.
• Match your workload profile to provider features: archive for indexers, WebSocket for bots, write reliability for payments.
• Test archive depth and burst behaviour yourself rather than relying on marketing pages.
• Always configure a failover endpoint and monitor head lag, error rate, and p95 latency.
• Shared RPC is fine for prototypes; move to a dedicated node when traffic or isolation needs grow.
• OnFinality provides a managed Celo RPC API and dedicated node options, alongside many other networks.

Frequently Asked Questions

What is the Celo mainnet RPC endpoint? OnFinality's public Celo endpoint is https://celo.api.onfinality.io/public. For production use, consider a managed or dedicated endpoint with a plan that matches your traffic.

What chain ID does Celo use? Celo mainnet uses chain ID 42220, which is 0x1a4 in hex.

Do I need an archive node for Celo? Only if you query historical state or logs. If you call eth_getLogs over old block ranges or read balances at past blocks, confirm archive access with your provider.

Does Celo support WebSocket subscriptions? Celo is EVM-compatible, so eth_subscribe works when the provider exposes a WebSocket endpoint. Check availability with your provider before building real-time features.

How do I handle rate limits on a shared Celo endpoint? Reduce burst sizes, batch where possible, and add retries with backoff. If limits still block your workload, move to a dedicated tier.

Can I run my own Celo node instead? Yes. Self-hosting gives full control but means you own sync, upgrades, storage, and monitoring. Many teams use a managed provider for reads and keep a self-hosted node for specific needs.

How do I switch Celo RPC providers without downtime? Add the new endpoint as a secondary in your client, run both in parallel, compare responses, then promote the new endpoint to primary once you are confident.