Zora RPC: A 2026 Developer's Guide

Zora Network is a creator chain. Most of what happens on it is minting — ERC-721 and ERC-1155 drops, free mints, edition releases — and minting is the most bursty traffic pattern in crypto. A drop goes live, a few thousand wallets pile in over ten minutes, and every one of them is hammering an RPC endpoint to estimate gas, read mint state, and confirm transactions. If you're indexing those mints or running a mint bot, your RPC is the bottleneck, not the chain.

Looking for endpoints? Zora RPC endpoints lists the endpoint URLs, live status and plans. This post explains how Zora works from a developer's side.

Zora is also an OP Stack rollup and a member of the Optimism Superchain, which means it's EVM-equivalent: every contract, tool, and eth_* method you know from Ethereum works unchanged. The catch is the same one every chain has — the public endpoint that shows up first in the docs is fine for a wallet and falls over the moment you read the chain at mint-day volume. This is the practical guide to building on Zora in 2026.

The facts that matter

Two things follow from "OP Stack, Superchain." First, anything you wrote for Optimism or Base ports to Zora by changing the chain ID and the endpoint — same opcodes, same precompiles, same RPC surface. Second, finality is two-tier: the sequencer gives you a soft confirmation in ~2 seconds, but a transaction isn't L1-final until it's posted and the challenge window passes. For UI you act on the soft confirmation; for anything irreversible (crediting a withdrawal, paying out) you wait for finality. On our endpoint the finalized tag trailed the head by roughly 1,000–1,300 blocks (about 30–45 minutes) in September 2026 measurements. We go deeper on the distinction in soft vs hard finality on L2s, but the rule of thumb: don't treat a 2-second confirmation as money-in-the-bank.

One more OP Stack detail that surprises people coming from Ethereum: a transaction pays two fees. L2 execution gas is what eth_estimateGas covers; on top of it is an L1 data fee for posting the transaction's data to Ethereum. The OP Stack exposes the inputs through the GasPriceOracle predeploy at 0x420000000000000000000000000000000000000F — on Zora, l1BaseFee() answered 127,693,915 wei when we called it — so read it there if you need exact costs rather than estimates.

The public-node trap

Zora's public endpoint exists so wallets work out of the box. It is not built for your indexer. The moment a popular drop lands, the public node is shared across every wallet and bot on the network at once, and you'll see exactly what you'd expect: rate-limit errors, dropped WebSocket subscriptions, and eth_getLogs calls that time out right when you need them. There's no key, no support, and no way to ask for more throughput.

For anything beyond a hobby script you want your own keyed endpoint. On SwiftNodes that's a flat-rate key — not metered compute units that turn a mint-day traffic spike into a surprise bill:

HTTP: https://rpc.swiftnodes.io/rpc/zora?key=YOUR_API_KEY

WebSocket subscriptions are not available for Zora on SwiftNodes right now: our health checks open a real eth_subscribe on each Zora upstream, and none currently accepts one. The live-tail pattern below uses HTTP polling instead, which at 2-second blocks costs one request every couple of seconds.

Connecting

Because Zora is EVM-equivalent, every library treats it as a generic chain — you just supply the chain ID and the endpoint.

viem:

import { createPublicClient, http, defineChain } from "viem";

const zora = defineChain({
  id: 7777777,
  name: "Zora",
  nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/zora?key=YOUR_API_KEY"] } },
});

const client = createPublicClient({ chain: zora, transport: http() });
console.log(await client.getBlockNumber());

ethers v6:

import { JsonRpcProvider } from "ethers";
const provider = new JsonRpcProvider("https://rpc.swiftnodes.io/rpc/zora?key=YOUR_API_KEY", 7777777);

web3.py:

from web3 import Web3
w3 = Web3(Web3.HTTPProvider("https://rpc.swiftnodes.io/rpc/zora?key=YOUR_API_KEY"))

Reading mints without melting your endpoint

The defining Zora workload is reading mint events. Most Zora drops are ERC-1155 editions, so the event you care about is TransferSingle (and TransferBatch) with a from of the zero address — that's a mint.

import { parseAbiItem } from "viem";

// ERC-1155 mints for a collection in a block range
const logs = await client.getLogs({
  address: "0xYourCollection",
  event: parseAbiItem(
    "event TransferSingle(address indexed operator, address indexed from, address indexed to, uint256 id, uint256 value)"
  ),
  args: { from: "0x0000000000000000000000000000000000000000" }, // mints only
  fromBlock: 20_000_000n,
  toBlock: 20_001_000n,
});

Two habits keep this fast and cheap:

• Page your block ranges. Don't ask for a million blocks at once — every provider caps the range, and you'll get an error or a truncated result. Backfill in fixed windows. We covered the failure modes in detail in how eth_getLogs range caps bite you in production.
• Filter by topic, not in your app. Passing args: { from: zeroAddress } filters server-side so you only pull mints, instead of fetching every transfer and discarding 90% of it.

Watching mints live

For a mint bot or a live drop dashboard you want events within a block or two of landing. With 2-second blocks, a range-based eth_getLogs poll gets you there without a socket, and it never skips a block because each poll starts where the last one ended:

import { createPublicClient, http, parseAbiItem } from "viem";
import { zora } from "viem/chains";

const client = createPublicClient({ chain: zora, transport: http("https://rpc.swiftnodes.io/rpc/zora?key=YOUR_API_KEY") });
const mint = parseAbiItem("event TransferSingle(address indexed operator, address indexed from, address indexed to, uint256 id, uint256 value)");

let next = await client.getBlockNumber();
setInterval(async () => {
  const head = await client.getBlockNumber();
  if (head < next) return;
  const logs = await client.getLogs({ event: mint, args: { from: "0x0000000000000000000000000000000000000000" }, fromBlock: next, toBlock: head });
  logs.forEach(handleMint);
  next = head + 1n;
}, 2000);

Avoid eth_newFilter / eth_getFilterChanges polling against any load-balanced endpoint: a filter lives on one node, and the next poll can land on another that has never heard of it.

The same rule applies whenever WebSocket is available (on Zora or any other chain): a subscription is a best-effort live tail, not a delivery guarantee. If the socket drops during a drop, you lose every mint in the gap unless you backfill it with an eth_getLogs catch-up on reconnect — the full pattern is in handling WebSocket reconnections without losing events.

Rate limits and mint-day spikes

The thing that makes Zora different operationally isn't steady-state load — it's the spike. Plan for the drop, not the average:

• Batch your reads. When you're checking mint state across many tokens, use eth_call batching or Multicall3 instead of one round-trip per token. One request that reads 200 token balances beats 200 requests.
• Cache the immutable. Collection metadata, total supply caps, mint prices — read once, cache, don't re-fetch on every block.
• Back off on 429s. When you do get rate-limited, exponential backoff with jitter prevents your own workers from making it worse.
• Use a flat-rate endpoint. On metered-compute providers, a single hot drop where you fire thousands of eth_getLogs and eth_call requests in ten minutes is precisely the pattern that produces a bill you didn't plan for.

Building on Zora

Zora rewards the same discipline as any high-burst chain: a keyed endpoint, server-side log filtering, paged backfills, batched reads, and a live tail that never skips a block. Get those right and a mint drop is a non-event for your infrastructure.

SwiftNodes runs flat-rate Zora HTTP endpoints — no compute-unit math when a drop spikes your traffic, and the Zora RPC page shows live status, including whether WebSocket is currently available. Grab a free key at swiftnodes.io and point your app at our Zora RPC, or browse the other 83 chains we support. For the finality and Superchain context, Zora behaves like its OP Stack siblings — if you're already on Optimism or Base, you're most of the way there.