zkSync Era RPC Guide: How to Connect and Build on zkSync (2026)

zkSync Era is a ZK rollup on Ethereum developed by Matter Labs. It executes transactions off-chain, generates zero-knowledge validity proofs, then posts those proofs to Ethereum mainnet. Unlike optimistic rollups, there is no challenge window: the proof itself guarantees correctness, so withdrawals to Ethereum are faster once proof verification completes.

The key distinction that shapes how you use zkSync Era’s RPC: it ships with native account abstraction at the protocol level. Every account can be a smart contract. This changes how gas estimation works, how signatures are validated, how Paymaster contracts can sponsor fees on behalf of users. All of this flows through the RPC layer.

This guide covers how zkSync Era RPC differs from Ethereum RPC, the key methods including zks_ extensions, how to connect with ethers.js or Web3.py or curl, zkSync-specific production considerations, common issues, plus how to choose a provider.

---

What is a zkSync Era RPC Endpoint

A zkSync Era RPC endpoint is an HTTP or WebSocket URL that exposes the zkSync Era JSON-RPC API. Your application sends method calls and receives on-chain data in return.

HTTP endpoints handle request-response interactions: reading contract state, estimating gas, submitting transactions, fetching logs. Each call is independent.

WebSocket endpoints maintain a persistent connection for event subscriptions. Use WSS when your application needs real-time responses to new blocks or contract events without polling.

zkSync Era uses chain ID 324 for mainnet. The JSON-RPC surface covers all standard eth_* methods plus a zks_ namespace with zkSync-specific extensions.

---

zkSync Era vs Ethereum: Key Differences for RPC

Understanding these differences before you build saves time debugging later.

ZK rollup finality model. Transactions on zkSync Era go through two confirmation stages. The sequencer confirms a transaction near-instantly and assigns it a position in the batch. ZK proof verification on Ethereum mainnet follows, typically within 1 to 3 hours. For most read-heavy applications and wallet interactions, sequencer confirmation is sufficient. For bridge withdrawals or high-value operations that require L1-backed finality, wait for proof verification.

Different transaction structure. zkSync Era transactions carry additional fields not present in standard Ethereum transactions: gasPerPubdata, factoryDeps, customSignature. These support account abstraction and ZK-specific gas accounting. Standard eth_sendRawTransaction accepts both legacy Ethereum transactions and zkSync-native transaction types. If you are serializing transactions manually, use the zkSync Era SDK or an AA-aware library to handle these fields correctly.

Native account abstraction. This is the biggest architectural difference from Ethereum. On Ethereum, only externally owned accounts (EOAs) can initiate transactions. On zkSync Era, every account is a smart contract by default. There is no EOA vs smart contract distinction at the protocol level. This means eth_getCode on a user address returns bytecode. Patterns that rely on msg.sender == tx.origin to detect EOAs behave differently. Gas estimation must account for the account’s validation logic, not just the called contract.

Different gas model. zkSync Era gas includes an L1 data publication cost in addition to L2 execution cost. The gasPerPubdata parameter controls how much gas the user pays per byte of data published to L1. Always use eth_estimateGas against the zkSync Era endpoint directly rather than applying Ethereum-derived estimates.

---

Example zkSync Era RPC Methods

Standard eth_ Methods

These work on zkSync Era with the same syntax as Ethereum:

• eth_blockNumber - current block height
• eth_getBalance - ETH balance for any address
• eth_call - read-only contract execution
• eth_estimateGas - includes L1 data cost component
• eth_sendRawTransaction - submit signed transactions
• eth_getTransactionReceipt - confirm inclusion and finality status
• eth_getLogs - query contract events by block range and topic
• eth_subscribe (WSS only) - subscribe to new blocks or logs

zkSync-Specific zks_ Methods

These methods are unique to zkSync Era and are not available on Ethereum or other EVM chains:

zks_getBlockDetails returns ZK-specific block metadata including the sequencer’s commit timestamp, the L1 transaction hash that posted the batch, plus the proof submission status. Useful for applications that need to surface finality status to users.

zks_getTransactionDetails returns zkSync-specific transaction data including the Paymaster address if one was used, the gasPerPubdata value, the transaction type (EIP-712, EIP-1559, or legacy).

zks_getBridgeContracts returns the L1 and L2 bridge contract addresses. Use this when building bridge integrations rather than hard-coding addresses.

zks_estimateFee is the zkSync-native fee estimation method. It returns gas_limit, gas_per_pubdata_limit, max_fee_per_gas, max_priority_fee_per_gas as separate fields. For AA transactions and Paymaster flows, use zks_estimateFee rather than eth_estimateGas to get accurate estimates.

zks_getMainContract returns the address of the zkSync Era diamond proxy contract on Ethereum L1.

---

Public zkSync Era RPC Endpoints

Provider	HTTP Endpoint	Notes
zkSync Era (official)	https://mainnet.era.zksync.io	Rate limited
Ankr	https://rpc.ankr.com/zksync_era	Free tier available
Chainstack	Provider dashboard	Paid plans
BoltRPC	https://eu.endpoints.matrixed.link/rpc/zksync?auth=YOUR_KEY	Flat-rate, free trial

Public endpoints are suitable for development and low-volume testing. Production workloads need a dedicated provider with consistent capacity and support.

---

Connecting Step by Step

ethers.js with zkSync Provider

The standard ethers.js JsonRpcProvider works for read operations and submitting pre-signed transactions. For AA transactions, Paymaster flows, or sending transactions from a smart account, use the zkSync Era SDK’s Provider class alongside ethers.js:

import { ethers } from "ethers";

// Standard ethers.js provider works for reads and legacy transactions
const provider = new ethers.JsonRpcProvider(
  "https://eu.endpoints.matrixed.link/rpc/zksync?auth=YOUR_KEY"
);

// Verify connection
const network = await provider.getNetwork();
console.log("Connected to chain ID:", network.chainId); // 324n

// Read a balance
const balance = await provider.getBalance("0xYourAddress");
console.log("Balance:", ethers.formatEther(balance), "ETH");

// WebSocket for real-time subscriptions
const wsProvider = new ethers.WebSocketProvider(
  "wss://eu.endpoints.matrixed.link/ws/zksync?auth=YOUR_KEY"
);

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

For AA-native transactions with zkSync Era SDK:

import { Provider, Wallet } from "zksync-ethers";

const provider = new Provider(
  "https://eu.endpoints.matrixed.link/rpc/zksync?auth=YOUR_KEY"
);

const wallet = new Wallet(privateKey, provider);

// zks_estimateFee via SDK
const feeData = await provider.estimateFee({
  from: wallet.address,
  to: recipientAddress,
  value: ethers.parseEther("0.01"),
});

console.log("Max fee per gas:", feeData.maxFeePerGas.toString());

Web3.py

from web3 import Web3

w3 = Web3(Web3.HTTPProvider(
    "https://eu.endpoints.matrixed.link/rpc/zksync?auth=YOUR_KEY"
))

print("Connected:", w3.is_connected())
print("Chain ID:", w3.eth.chain_id)  # 324

balance = w3.eth.get_balance("0xYourAddress")
print("Balance:", w3.from_wei(balance, "ether"), "ETH")

# Call a zks_ method directly
block_details = w3.provider.make_request("zks_getBlockDetails", [12345])
print("Block details:", block_details)

curl

# Standard eth_ method
curl -X POST https://eu.endpoints.matrixed.link/rpc/zksync?auth=YOUR_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

# zkSync-specific method
curl -X POST https://eu.endpoints.matrixed.link/rpc/zksync?auth=YOUR_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"zks_getBlockDetails","params":[12345],"id":1}'

For MetaMask setup, see the zkSync Era RPC endpoint page.

---

zkSync-Specific Considerations

ZK Proof Lifecycle and Finality

Transactions on zkSync Era pass through three states visible via RPC:

1. Sequencer confirmed - transaction hash is available, eth_getTransactionReceipt returns a receipt. This is the state most applications care about for UX purposes.
2. Batch committed - the sequencer has committed the batch to L1 (L1 tx exists). zks_getBlockDetails will show the commit tx hash.
3. Proof verified - ZK proof has been verified on L1. Funds can be withdrawn to Ethereum. zks_getBlockDetails shows the prove tx hash.

If your application involves bridge withdrawals or cross-chain messaging, poll zks_getBlockDetails for the block containing your transaction and check whether the prove transaction hash is populated.

Account Abstraction and Paymasters

Native account abstraction on zkSync Era means Paymaster contracts can pay transaction fees on behalf of users. From an RPC perspective, this affects gas estimation.

When estimating fees for a transaction that uses a Paymaster, include the Paymaster address and input data in your fee estimation call:

import { Provider } from "zksync-ethers";
import { utils } from "zksync-ethers";

const provider = new Provider(
  "https://eu.endpoints.matrixed.link/rpc/zksync?auth=YOUR_KEY"
);

const feeData = await provider.estimateFee({
  from: userAddress,
  to: contractAddress,
  data: encodedCallData,
  customData: {
    paymasterParams: utils.getPaymasterParams(paymasterAddress, {
      type: "ApprovalBased",
      token: tokenAddress,
      minimalAllowance: 1n,
      innerInput: new Uint8Array(),
    }),
  },
});

Calling eth_estimateGas without the Paymaster context will return an incorrect estimate for these transactions. Always use zks_estimateFee with the full transaction context when Paymasters are involved.

EVM Compatibility Gaps

zkSync Era is EVM-compatible but not EVM-equivalent. Contracts written with standard Solidity patterns deploy without changes in most cases. Known differences to check:

• SELFDESTRUCT is not supported
• EXTCODECOPY has restrictions
• Low-level assembly patterns may behave unexpectedly
• eth_getCode returns bytecode for all accounts including EOA-equivalent accounts due to native AA

The zkSync documentation maintains the full list of differences. Standard ERC-20, ERC-721, common DeFi patterns work without changes.

---

Common Issues

eth_estimateGas returns unexpectedly high values. zkSync Era’s gas estimate includes the L1 data publication cost. This is correct behavior. The total cost is higher than an equivalent Ethereum transaction but the actual ETH spent should be lower due to efficient proof batching. Use zks_estimateFee for a breakdown of the fee components.

Transaction stuck after sequencer confirmation. Proof verification takes 1 to 3 hours. If you are checking for a state change that requires L1 finality (such as a bridge withdrawal), poll zks_getBlockDetails for the prove tx hash rather than assuming the transaction is finalized after sequencer confirmation.

zks_ methods returning null. Some providers only expose the eth_* namespace. Verify your provider supports the full zkSync Era JSON-RPC specification including zks_ methods before building against them.

Account type checks failing. Code that checks for EOAs via msg.sender == tx.origin or by checking if eth_getCode returns empty will not work reliably on zkSync Era. All accounts may have associated bytecode. Update your account type detection logic to use zkSync-compatible patterns.

eth_getLogs range errors. zkSync Era has approximately 1-second block times. A 10,000-block range covers roughly 3 hours. Some providers enforce range limits. If you see range errors, use 5,000-block chunks and paginate.

---

Choosing a Provider

For zkSync Era production workloads, evaluate providers on:

Full zks_ method support. Not all providers expose the complete zks_ namespace. Verify zks_getBlockDetails, zks_estimateFee, zks_getTransactionDetails are available before committing.

AA workload capacity. Native account abstraction generates more RPC calls per user interaction than EOA-based flows: fee estimation, validation, Paymaster calls, signature verification. Your provider needs capacity sized for this multiplied call volume.

WebSocket reliability. Real-time dApps, account watchers, session key monitoring all depend on stable WSS connections. Treat WSS support as a first-class requirement.

Security certifications. ISO/IEC 27001:2022 certification is the standard for infrastructure handling production financial traffic.

BoltRPC provides zkSync Era RPC on infrastructure operated by Matrixed.Link, which is ISO/IEC 27001:2022 certified. The endpoint supports the complete zkSync Era JSON-RPC specification including all zks_ methods. Pricing is flat-rate with no per-method tiering.

Start your free 2-week trial: trial.boltrpc.io

---

FAQ

What is a zkSync Era RPC endpoint?

A zkSync Era RPC endpoint is an HTTP or WebSocket URL that connects your application to a zkSync Era node. Your application sends JSON-RPC method calls to read blockchain state, estimate fees, submit transactions, or subscribe to events. The zkSync Era endpoint supports standard eth_* methods plus a zks_ namespace with zkSync-specific extensions like zks_getBlockDetails and zks_estimateFee.

What is the difference between eth_estimateGas and zks_estimateFee on zkSync Era?

eth_estimateGas returns a single gas value. zks_estimateFee returns a structured breakdown including gas_limit, gas_per_pubdata_limit, max_fee_per_gas, max_priority_fee_per_gas as separate fields. For standard transactions, eth_estimateGas is sufficient. For AA transactions involving Paymasters, zks_estimateFee is required to get accurate estimates because it accounts for the full transaction context including Paymaster validation logic.

Does zkSync Era RPC work with ethers.js?

Yes. Standard ethers.js JsonRpcProvider works for reads and legacy transactions. For zkSync-native features like AA transactions and Paymaster flows, use the zksync-ethers SDK alongside ethers.js. The zksync-ethers Provider class extends ethers.js and adds zkSync-specific methods including estimateFee, getBlockDetails, getTransactionDetails.

How do I check if a zkSync Era transaction has reached L1 finality?

Call zks_getBlockDetails with the block number containing your transaction. The response includes fields for the commit transaction hash, prove transaction hash, execute transaction hash on L1. When prove_tx_hash is populated and non-null, the ZK proof for that block has been verified on Ethereum. This indicates L1-backed finality. For most application interactions, sequencer confirmation is sufficient and L1 finality only matters for bridge withdrawals.

---