How to Choose a zkSync RPC Provider for Production Apps

Quick recommendation: match the provider to your workload

Before comparing vendors, decide what your application actually needs from a zkSync RPC provider. A wallet or a simple dApp frontend can often run on a public endpoint. A trading bot, indexer, or analytics service that issues thousands of requests per second will need a dedicated node or a provider with generous rate limits and archive data.

Ask yourself these questions:

• How many requests per second do you expect? Public endpoints typically throttle at 10–100 RPS per client. If your traffic is bursty or sustained, you need a provider that can scale.
• Do you need historical state? Indexers and analytics tools often require eth_getLogs over large ranges or archive data. Not all providers offer archive nodes.
• Do you need WebSocket support? Real-time applications like order books or event listeners rely on eth_subscribe. Check that the provider supports WSS and its subscription limits.
• What is your tolerance for downtime? If your app is production, a single public endpoint is risky. Consider a provider with multiple endpoints, failover, or a dedicated cluster.

For most production workloads, a managed RPC provider like OnFinality offers a balance of reliability and scalability. You get a stable endpoint, access to multiple networks, and the option to upgrade to a dedicated node when you outgrow shared infrastructure. See RPC pricing and supported networks for details.

zkSync RPC basics: what you are connecting to

ZKsync is an Ethereum Layer 2 scaling solution that uses zero-knowledge rollups (ZK rollups) to increase throughput and reduce transaction costs. It is EVM-compatible, meaning most Ethereum tooling works with minimal changes. However, ZKsync has its own JSON-RPC API that extends the standard Ethereum API with L2-specific methods.

When you interact with ZKsync, you send JSON-RPC requests to an endpoint. The endpoint can be a public node, a shared provider, or a dedicated node you run yourself. The provider handles the underlying node infrastructure, including synchronization, storage, and network connectivity.

Chain settings at a glance

If you are configuring a wallet or a dApp, you need the correct chain details. Here are the official settings for ZKsync mainnet and testnet:

These URLs are public endpoints provided by OnFinality. For production use, you should get a dedicated API key to avoid rate limits and ensure reliability. See the ZKsync network page for more details.

What to look for in a zkSync RPC provider

Not all RPC providers are equal. Here are the key criteria to evaluate when choosing a provider for ZKsync:

Public vs. shared vs. dedicated

• Public endpoints are free and easy to use, but they are rate-limited and not suitable for production. They are fine for testing and small projects.
• Shared RPC providers offer a managed endpoint with higher rate limits and additional features like archive data and WebSocket support. They are a good default for most production apps.
• Dedicated nodes give you a single-tenant node with no shared resources. They offer the highest performance and reliability, but at a higher cost. They are ideal for high-throughput applications, indexers, and enterprises.

OnFinality offers both shared and dedicated options. You can start with a shared endpoint and upgrade to a dedicated node as your needs grow. See RPC pricing for details.

How to connect to ZKsync with a provider

Once you have chosen a provider, you need to configure your application to use the endpoint. Here is an example using ethers.js to connect to ZKsync mainnet:

const { ethers } = require("ethers");

// Replace with your provider's endpoint
const RPC_URL = "https://zksync.api.onfinality.io/public";

const provider = new ethers.JsonRpcProvider(RPC_URL);

async function getBlockNumber() {
  const blockNumber = await provider.getBlockNumber();
  console.log("Current block number:", blockNumber);
}

getBlockNumber();

For WebSocket support, use ethers.WebSocketProvider:

const { ethers } = require("ethers");

const WSS_URL = "wss://zksync.api.onfinality.io/public";
const provider = new ethers.WebSocketProvider(WSS_URL);

provider.on("block", (blockNumber) => {
  console.log("New block:", blockNumber);
});

Note that the public endpoint may not support WebSocket. Check with your provider for the correct WSS URL.

Key zkSync RPC methods you will use

ZKsync supports the standard Ethereum JSON-RPC methods, plus some L2-specific ones. Here are the most common ones:

• eth_blockNumber – get the latest block number
• eth_getBalance – get the balance of an address
• eth_call – execute a read-only contract call
• eth_sendRawTransaction – send a signed transaction
• eth_getTransactionReceipt – get transaction receipt
• eth_getLogs – query logs (useful for indexing)
• zks_getBlockDetails – get detailed information about a block (L2-specific)
• zks_getTransactionDetails – get detailed information about a transaction (L2-specific)

You can test these methods with a simple curl request:

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

Common pitfalls when using zkSync RPC

Even with a good provider, you may run into issues. Here are some common pitfalls and how to avoid them:

• Rate limiting: Public endpoints often limit requests per second. If you hit the limit, you will get errors. Use a provider with higher limits or implement retry logic.
• Missing archive data: Some providers only offer full nodes, which do not store historical state. If you need to query old blocks, you need an archive node.
• WebSocket disconnects: WebSocket connections can drop. Implement reconnection logic in your app.
• Incorrect chain ID: Make sure you use the correct chain ID (324 for mainnet, 300 for Sepolia). Using the wrong one will cause transactions to fail.
• L2-specific methods: Not all providers support zks_* methods. If you need them, verify that your provider does.

Production readiness checklist

Before you launch your application, go through this checklist:

• Choose a provider that meets your throughput and data needs
• Get a dedicated API key (not the public endpoint)
• Set up monitoring for your RPC endpoints
• Implement retry logic for rate limits and network errors
• Use WebSocket with reconnection for real-time features
• Test on ZKsync Sepolia first
• Have a fallback provider in case of downtime

Key Takeaways

• ZKsync is an EVM-compatible L2 with its own JSON-RPC API.
• Choose a provider based on your workload: public for testing, shared for production, dedicated for high throughput.
• Check for archive data, WebSocket support, and zkSync-specific methods.
• Use the correct chain ID and endpoint for mainnet vs. testnet.
• Monitor your endpoints and have a fallback plan.

Frequently Asked Questions

What is the best zkSync RPC provider?

The best provider depends on your needs. For production, look for a provider with high reliability, good throughput, and support for zkSync-specific methods. OnFinality offers both shared and dedicated options.

Can I use a public zkSync RPC endpoint for production?

Public endpoints are rate-limited and not recommended for production. They are fine for testing and development.

Does OnFinality support ZKsync?

Yes, OnFinality supports ZKsync mainnet and Sepolia testnet. See the ZKsync network page for details.

What is the chain ID for ZKsync mainnet?

The chain ID is 324.

How do I get a dedicated zkSync RPC node?

You can get a dedicated node from OnFinality. See dedicated node for more information.