zkSync Era RPC Nodes & Endpoints

zkSync Era RPC URLs you can use right now

Third-party endpoints, free and shared. They speak the standard eth_ methods plus zkSync's own zks_ namespace, and they throttle like any public endpoint once a paymaster or indexer starts polling in earnest.

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider("https://mainnet.era.zksync.io");
const blockNumber = await provider.getBlockNumber();
console.log("zkSync Era block:", blockNumber);

EVM-compatible is not EVM-equivalent, and it shows in your tooling

zkSync Era runs Solidity, but it does not run Ethereum's bytecode. Contracts are compiled with zksolc to a different instruction set targeted at the zk circuit, which means deployment artifacts, bytecode comparisons, and verification flows all differ from mainnet. The most common practical casualty is CREATE2 address prediction: the formula uses a different hashing scheme here, so a factory pattern that computes deterministic addresses off-chain will produce wrong answers if it was ported unchanged. Anything asserting on bytecode, or precomputing addresses, needs revisiting rather than reusing.

Account abstraction is the other structural difference, and it is native rather than bolted on. Every account on zkSync Era can carry validation logic, so a transaction may be paid for by a paymaster and authorised by something other than an ECDSA signature over the familiar payload. For an RPC consumer this changes what a transaction looks like: the from address is not reliably an externally owned account, gas may be sponsored, and the zks_ methods exist to expose the fee and bridge details that standard eth_ methods have no field for. An indexer built on mainnet assumptions about who signed and who paid will misread a meaningful share of traffic.

Where shared zkSync Era endpoints stop being enough

zkSync Era adds surfaces that generic shared endpoints handle unevenly: the zks_ namespace for fee estimates and L1 batch data, and native account abstraction, which turns wallets and paymasters into services that poll constantly. A bundler or paymaster loop asking for fees and nonces every few hundred milliseconds is exactly the steady, chatty traffic that shared rate limits punish, and a public endpoint that lags on zks_ methods breaks fee UX in ways users notice immediately.

A dedicated zkSync RPC node serves that polling at whatever rate your product needs and keeps the zks_ namespace as fast as the standard one. Indexers tracking L1 batch commitments get consistent throughput instead of backoff loops. On BLAZED.sh, the bundler or indexer itself runs in a container on the node host, reading over a local socket.

zkSync Era RPC latency is a distance problem

Account-abstraction UX is a latency product: the wallet waits on a fee estimate, the paymaster waits on a balance read, and every one of those calls pays the network path to the endpoint. Over a public gateway that is tens to low hundreds of milliseconds per call. On our live Ethereum product, co-located code completes calls in under 10 milliseconds over a local socket, and dedicated zkSync Era nodes will use the same design. That gap is the difference between AA flows that feel native and ones that feel like waiting.

What dedicated zkSync Era node hosting will cost

BLAZED.sh prices node access in per-request credits granted monthly by your subscription, with a deliberately narrow weight spread: most RPC methods cost a single credit, and only a handful of heavy operations cost more. Dedicated zkSync Era nodes will launch on the same credit model, with the waitlist deciding rollout priority.

AA infrastructure generates many small reads, and small reads are single-credit calls, so even a paymaster polling around the clock arrives at a monthly number you can compute in advance.

Perfect for

What is zkSync Era?

zkSync Era uses zkEVM technology to prove batches of transactions with validity proofs, giving faster economic finality than optimistic rollups once a proof is verified on Ethereum. It is EVM-compatible rather than fully EVM-equivalent: most Solidity works, but contract deployment uses a different bytecode path and the chain exposes zkSync-specific RPC methods (the zks_ namespace) for fees, L1 batch details, and paymaster flows. Native account abstraction is a first-class feature, so wallets, gasless UX, and smart-account tooling are common here. Connecting uses chain ID 324, and as with every rollup the RPC layer, not the prover, is what most apps feel day to day, especially indexers tracking L1 batch commitments.

zkSync Era RPC: frequently asked questions