NexFlow › Library › ZKsync Era RPC endpoint guide

ZKsync Era RPC endpoint: free reads, keyed lanes and x402

ZKsync Era speaks Ethereum's JSON-RPC dialect, but it is a zero-knowledge rollup underneath, and that changes what "latest", "final" and "gas" mean in the answers you get back. This guide gives you a working endpoint, the real responses it returned today, and the chain-specific traps worth knowing before you point a backend at it.

10 min read · updated 2026-09-27 · infra guide, not financial advice

If you only need the URL, here it is: https://nexflowscan.com/api/rpc/zksync-era. It takes a standard JSON-RPC POST, needs no key for baseline reads, and answers from a pool of health-checked upstream providers rather than from a single box. Everything below is about using it well — which methods behave differently on ZKsync Era than on Ethereum mainnet, how far behind the chain tip each block tag sits, and when a free lane stops being the right tool.

ZKsync Era is Matter Labs' EVM-compatible rollup. Transactions execute on the L2, get grouped into batches, and each batch is proven with a validity proof that Ethereum verifies. From a client's point of view it mostly looks like any other EVM network: chain ID, blocks, receipts, logs, eth_call. The differences show up at the edges — in block cadence, in how gas is priced, and in how long it takes before a block is truly settled on L1.

The endpoint, and what it answered today

A chain-ID check is the cheapest possible sanity test for any RPC URL: it confirms you are talking to the network you think you are before you trust a single balance. Here is that request against our relay, followed by a block-height read:

curl -s -X POST https://nexflowscan.com/api/rpc/zksync-era \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
# {"jsonrpc":"2.0","result":"0x144","id":1}

curl -s -X POST https://nexflowscan.com/api/rpc/zksync-era \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
# {"jsonrpc":"2.0","result":"0x44e568d","id":1}

Decoded, 0x144 is 324 — ZKsync Era mainnet's chain ID — and 0x44e568d is block 72,242,829, the height our relay reported on 2026-09-27. Your block number will be higher when you run it; the chain ID never changes. If you ever receive something other than 0x144 from a URL that claims to be ZKsync Era, stop: you are on a testnet, a different rollup, or a misconfigured provider, and every downstream read is suspect.

Add the network to a wallet with the same two facts: chain ID 324 and ETH as the gas currency. The URL is the only part you are choosing.

Blocks, batches, and why "final" takes hours

ZKsync's own documentation, in the protocol section titled Blocks and batches, separates two units that Ethereum developers normally treat as one. An L2 block is what eth_blockNumber counts; the docs describe these as produced on a roughly one-second cadence, mainly so that wallets and tooling that expect frequent block updates see transactions confirm quickly. An L1 batch is the unit that is actually committed, proven and executed on Ethereum; many L2 blocks roll into one batch.

The companion page, Finality, lays out the pipeline: batch formation (generally a few minutes), batch commitment to Ethereum, proof generation, and finalization, which includes a deliberate delay of about three hours as a security measure. The docs put complete finality for a ZKsync Era transaction at around three hours, aligned with the finality of the Ethereum block that settles it. Before that, transactions are shown with what the docs call instant confirmation — visible in APIs and interfaces, but not yet irreversible on L1.

You can watch this directly through the relay by asking for three block tags. On 2026-09-27 our reads returned:

The finalized gap of roughly four hours lines up with the documentation's three-hour delay plus batch assembly and proving time. The practical rule follows from it: a UI can happily show latest; anything that releases value off-chain — crediting a deposit, paying out, closing a trade in another system — should key off finalized and accept the wait, or at least key off safe with a written reason why.

One more observation from the same session. Over the most recent 1,000 blocks, timestamps averaged about seven seconds apart, not one. The documentation's one-second figure describes how often a block can be sealed; what we measured is what the chain actually produced during that window. Do not hard-code either number into polling logic. Poll on a timer, compare heights, and let the chain tell you how fast it is moving.

Gas on ZKsync Era is not Ethereum gas

ZKsync's Fee model documentation explains that a transaction pays for two things: computation on the L2, and pubdata — the state-change data that must be published to Ethereum so anyone can reconstruct the rollup's state. Pubdata is priced against L1 conditions, which is why a transaction that looks cheap in computation can still be expensive when it writes a lot of storage. The docs cover this under How ZKsync Chains charges for pubdata.

Three things follow for anyone reading fees through RPC:

Always estimate against the chain. Gas limits copied from Ethereum mainnet tooling are wrong here, sometimes by a wide margin, because the pubdata component does not exist on L1. eth_estimateGas through our relay is served by a ZKsync node, so its answer includes the chain's own accounting. Build the estimate, add your normal margin, send.

Ignore the block gas limit. The gasLimit field in the latest block header we read was 1,125,899,906,842,624 — two to the fiftieth power. That is not a real capacity figure; it is a placeholder the node reports for compatibility. Code that divides gas used by gas limit to compute "fullness" will produce nonsense on this chain.

Tips behave differently. eth_maxPriorityFeePerGas returned 0x0 in our read, and eth_gasPrice returned 45,250,000 wei, equal to the block's base fee in the same session. The sequencer orders transactions itself, so a priority fee is not a lever the way it is on Ethereum. Treat these as dated snapshots — the point is the shape of the answers, not the numbers.

What our relay serves on ZKsync Era — and what it refuses

The relay is a read gateway. It forwards the standard Ethereum read namespace — eth_call, eth_getBalance, eth_getLogs, eth_getBlockByNumber, eth_getTransactionReceipt, eth_estimateGas, eth_feeHistory, the filter methods and the net_/web3_ basics — and tries the next upstream in the pool when one fails or lags.

It does not forward ZKsync's own zks_ namespace. We tested zks_L1BatchNumber and the relay answered with error -32601, "Method not allowed on this relay". If your application depends on ZKsync-specific calls — batch details, L1-to-L2 proofs, bridge contract discovery — you need a provider that exposes them directly, or your own node. Everything you can do with plain Ethereum RPC works through us; the rollup-internal extras do not.

Signing and node-administration methods are blocked outright. eth_sign and txpool_content both returned -32601 in our tests, and the lane page states plainly that sends and signs are refused on the public lane. That is deliberate: a shared public endpoint should never be the place a key lives, and it should not be your broadcast path for anything that matters. Sign in the wallet or the backend that owns the key; broadcast through infrastructure you control or pay for.

Behind the URL sits a small ladder of keyless upstreams. The client-version string we got back during testing identified a third-party gateway rather than a Matter Labs node, which is normal for a relay: the value is in the fallback, not in any one provider. If you need to know exactly which node answered a given call — for example, to reproduce a disputed read — pin your own provider for that work.

Free, keyed or x402 — picking a lane

Our relay, as of 2026-09-27, offers three ways to call the same ZKsync Era endpoint. They differ in who pays, how, and how much traffic you can push.

The free lane is a 50-call-per-IP allowance, not a production promise. The relay's rate limiter scores a batch by its item count, so a 25-item batch uses 25 of your 300 per minute. When you outgrow it, the relay answers with HTTP 402 rather than silently dropping calls, which is the cue to move up.

The keyed lane is a flat one-time fee. Request the payment addresses from /api/rpc/keys/checkout, pay, then claim the rk1_ key; the integration guide walks through the headers. For a service that reads ZKsync Era around the clock, this is usually the cheaper and simpler choice.

The x402 lane has no account at all. An unpaid request comes back as HTTP 402 with a machine-readable challenge listing the price in USDC and the networks it will settle on; the client pays and retries with an X-PAYMENT header, and the call is served. The x402 RPC feature page explains the flow. It fits software that makes occasional calls on behalf of someone else and should pay as it goes.

A short checklist for production reads

Keep two independent endpoints configured and compare them for any read that moves money; a disagreement means one of them is stale or wrong, and you should not act until they agree. Log the block number alongside every important read so you can reconstruct what your system saw. Use finalized for settlement logic and latest for display, and make that choice explicit in code rather than relying on a library default. Budget for the three-hour finality window in any cross-chain or off-chain flow — it is part of the protocol, not an outage. And if you need batch-level detail from the zks_ namespace, plan for a direct provider from the start rather than discovering the gap in production.

The full list of networks the relay covers, including every other EVM rollup we route, is on the RPC lane index.

Frequently asked