Polygon zkEVM RPC: A Developer's Guide to the Type 1 ZK Rollup

Polygon zkEVM is the most Ethereum-equivalent zero-knowledge rollup in production. It's a Type 1 zkEVM — meaning it doesn't modify Ethereum's data structures, opcodes, or state representation. Every EVM contract deploys without modification. Every RPC method works the same way it does on Ethereum mainnet. The difference is under the hood: a ZK prover generates a cryptographic proof that every batch of transactions was executed correctly, and Ethereum verifies that proof on-chain.

If you're coming from Ethereum, everything you know transfers directly. Same chain interactions, same tooling, same RPC methods. The differences are in the economics (cheaper gas, different fee token), the finality model (ZK proof verification instead of validator voting), and the bridge architecture.

This is the practical reference for connecting to Polygon zkEVM via JSON-RPC.

The essentials

Polygon zkEVM mainnet has:

• Chain ID: 1101 (0x44d)
• Block time: ~5 seconds (L2 blocks), L1 batch submission every ~20 minutes
• Gas token: ETH (same as Ethereum)
• Consensus: ZK proof generation + Ethereum verification
• Finality: ~30 minutes (proof generated + verified on L1)
• Type: Type 1 zkEVM — full EVM equivalence

The "Type 1" designation matters. Other zkEVMs (like Scroll at Type 2, or zkSync at Type 4) modify some aspect of the EVM — different data structures, missing opcodes, or different state representations. Polygon zkEVM's Type 1 approach means zero migration effort. Your contracts, your tooling, your RPC calls — all identical to Ethereum.

Connecting: the setup

curl

# Chain ID
curl -s -X POST https://rpc.swiftnodes.io/rpc/polygon-zkevm?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x44d"}

# Latest block
curl -s -X POST https://rpc.swiftnodes.io/rpc/polygon-zkevm?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

# ETH balance
curl -s -X POST https://rpc.swiftnodes.io/rpc/polygon-zkevm?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xADDRESS","latest"],"id":1}'

viem

import { createPublicClient, http } from 'viem';
import { polygonZkEvm } from 'viem/chains';

const client = createPublicClient({
  chain: polygonZkEvm,
  transport: http('https://rpc.swiftnodes.io/rpc/polygon-zkevm?key=YOUR_API_KEY'),
});

const blockNumber = await client.getBlockNumber();
const balance = await client.getBalance({ address: '0x...' });

ethers v6

import { JsonRpcProvider } from 'ethers';

const provider = new JsonRpcProvider(
  'https://rpc.swiftnodes.io/rpc/polygon-zkevm?key=YOUR_API_KEY'
);

const blockNumber = await provider.getBlockNumber();
const balance = await provider.getBalance('0x...');

What's the same as Ethereum

Because Polygon zkEVM is Type 1 (full EVM equivalence), these all work identically to Ethereum mainnet:

The only thing that's different is the proving mechanism — instead of validators voting on block validity, a ZK prover generates a cryptographic proof that Ethereum verifies. This gives you mathematical certainty of correctness instead of economic certainty from validator stakes.

What's different from Ethereum

Gas is cheaper but works differently

Polygon zkEVM gas is priced in ETH (same as Ethereum), but the costs are dramatically lower:

The gas price fluctuates based on L1 ETH gas prices (since batch submission costs L1 gas) and the prover's operating costs. During L1 congestion, Polygon zkEVM gas can spike — but it's always a fraction of mainnet costs.

Finality is proof-based, not time-based

On Ethereum, finality comes from validator voting (~13 minutes for finalized). On Polygon zkEVM, finality comes from ZK proof verification on L1:

1. Transactions execute on L2 (~5 second blocks)
2. The sequencer batches transactions and submits them to L1 (~every 20 minutes)
3. The ZK prover generates a proof of correct execution
4. The proof is verified on Ethereum L1

The full cycle takes approximately 30 minutes from L2 transaction to L1-finalized state. For most applications, you can treat L2 confirmations as sufficient (the sequencer is trusted not to reorg). For high-value settlements, wait for the L1 proof verification.

The bridge is asymmetric

Depositing from Ethereum to Polygon zkEVM is fast (~15 minutes, waiting for L1 confirmations). Withdrawing back to Ethereum requires waiting for the ZK proof to be verified on L1 — approximately 30 minutes for the standard bridge.

// Deposit: Ethereum → Polygon zkEVM
// Send ETH to the bridge contract on Ethereum mainnet
// Funds available on Polygon zkEVM after ~15 minutes

// Withdrawal: Polygon zkEVM → Ethereum
// Call the bridge contract on Polygon zkEVM
// Funds available on Ethereum after ~30 minutes (proof verification)

Third-party bridges (Across, Stargate, Hop) offer faster withdrawals by fronting the liquidity — typically 2-5 minutes instead of 30.

The methods you'll actually use

Since Polygon zkEVM is EVM-equivalent, the methods are identical to Ethereum. Here are the ones you'll use most:

Gas estimation caveat

eth_estimateGas on Polygon zkEVM returns accurate estimates for execution gas, but the actual cost includes a data availability component that isn't captured in the estimate. The L2 gas price includes both execution costs and the cost of posting data to L1.

For accurate cost estimation:

const gasEstimate = await client.estimateGas({
  to: '0x...',
  data: calldata,
  account: '0x...',
});

const gasPrice = await client.getGasPrice(); // Includes DA costs
const totalCost = gasEstimate * gasPrice;

// Add 20% buffer for gas price fluctuations
const bufferedCost = (totalCost * 120n) / 100n;

Archive access

Polygon zkEVM's state grows more slowly than Ethereum's (lower transaction volume), but archive access is still important for:

• Querying historical balances or contract state
• Running eth_call at historical blocks
• Building indexers that backfill from old blocks
• Debugging old transactions

Not all providers offer archive access for Polygon zkEVM. Confirm archive support before choosing an endpoint if your application needs historical state queries.

WebSocket subscriptions

Polygon zkEVM supports WebSocket subscriptions for real-time updates:

import { createPublicClient, webSocket } from 'viem';
import { polygonZkEvm } from 'viem/chains';

const client = createPublicClient({
  chain: polygonZkEvm,
  transport: webSocket('wss://rpc.swiftnodes.io/ws/polygon-zkevm?key=YOUR_API_KEY'),
});

// Subscribe to new L2 blocks
const unwatch = client.watchBlocks({
  onBlock: (block) => {
    console.log(`New L2 block: ${block.number}`);
  },
});

With ~5 second block times, WebSocket subscriptions are much more efficient than polling. Use eth_subscribe with "newHeads" for block updates and "logs" for event monitoring.

Compared to other Polygon chains

Polygon PoS is faster and cheaper for high-frequency transactions. Polygon zkEVM inherits Ethereum's security through ZK proofs and uses ETH for gas — better for applications that need Ethereum-level security guarantees.

Production considerations

Rate limits

Polygon zkEVM RPC providers typically limit:

• Requests per second — usually 10-50 RPS on free tiers
• eth_getLogs range — some providers limit the block range for log queries
• WebSocket connections — concurrent connection limits

Gas price volatility

Polygon zkEVM gas prices track L1 Ethereum gas prices (since batch submission costs L1 gas). During L1 congestion:

• L1 gas spikes → Polygon zkEVM gas spikes
• The effect is dampened (L2 batches many txs into one L1 tx) but not eliminated
• Monitor eth_gasPrice and adjust your fee expectations accordingly

Sequencer downtime

If the Polygon zkEVM sequencer goes down:

• New transactions can't be submitted
• Existing transactions in the mempool are held
• The network resumes when the sequencer comes back
• No transactions are lost (they're held, not dropped)

The sequencer has been highly reliable since mainnet launch, but it's a centralized component. For critical applications, implement retry logic with exponential backoff.

Choosing a Polygon zkEVM RPC endpoint

The decision comes down to three things:

1. Do you need archive access? If your application queries historical state, confirm the provider offers it. Not all do for Polygon zkEVM.

2. What's your request volume? Polygon zkEVM has lower traffic than Ethereum mainnet, but popular dApps can still hit rate limits. Calculate your expected requests and choose accordingly.

3. Do you need WebSocket support? Real-time applications need WebSocket subscriptions. Confirm the provider offers them with reasonable connection limits.

The short version

Polygon zkEVM (chain ID 1101) is a Type 1 ZK rollup — full EVM equivalence, ETH gas, ~5 second blocks. Everything that works on Ethereum works here without modification. Gas is 100-1000x cheaper. Finality takes ~30 minutes (ZK proof verification on L1). Use the same tooling, same contracts, same RPC methods. The only difference is under the hood: ZK proofs instead of validator voting.

For Polygon zkEVM RPC access with archive support and WebSocket subscriptions, grab a free API key and point your app at:

https://rpc.swiftnodes.io/rpc/polygon-zkevm?key=YOUR_API_KEY