Katana RPC: A Developer's Guide to the DeFi-First L2

Katana looks like every other OP Stack chain from the RPC side: the same eth_* methods, the same predeploys at 0x4200…, the same L1 fee fields on receipts. Two things underneath are different, and both change how you write code against it. Blocks come every second, not every two. And Katana settles with ZK validity proofs instead of a seven-day fraud-proof window, so "finalized" arrives in minutes rather than a week.

Katana is a DeFi-focused Ethereum L2 incubated by Polygon Labs and GSR. It opened its public mainnet in June 2025. Per L2BEAT, it runs the Agglayer CDK in its OP Stack configuration: an OP Stack chain proven with OP Succinct (SP1 validity proofs), using Agglayer as its canonical bridge. Bridged assets go through VaultBridge, which puts deposits into yield-generating vaults on Ethereum and routes the yield back into Katana's ecosystem.

This guide covers what we measured through our endpoint on 2026-09-27, and what it means for your code.

The essentials

It is EVM-equivalent: Foundry, Hardhat, viem and ethers all work unchanged. Point them at the RPC and set the chain ID.

One block per second

A 1-second block time is twice as fast as Base or Optimism, and it changes a few habits:

• Polling is expensive. A loop that calls eth_getBlockByNumber("latest") every block makes 86,400 requests a day. Use a WebSocket newHeads subscription instead, or better, subscribe to exactly the logs you care about. The eth_subscribe logs guide shows the pattern.
• Block ranges are shorter in time. The 30,000-block eth_getLogs limit covers about 8.3 hours of Katana history. A backfill over one month is about 87 requests, not one. The general approach for ranges is in eth_getLogs range caps.
• Confirmation counts mean less. "Wait 12 blocks" is 12 seconds on Katana. Count confirmations with block tags, not block numbers.

Finality: latest, safe, finalized

OP Stack chains expose three levels through standard block tags, and Katana's numbers are unusual:

On an optimistic rollup, a withdrawal to L1 still waits seven days after finalized for the fraud-proof window. Katana has no such window: its state transitions are proven with validity proofs, and Succinct puts Katana's finality at "under an hour" (case study). For anything that moves value off-chain, such as crediting a deposit or releasing funds, wait for finalized:

import { createPublicClient, http, defineChain } from "viem";
import { chainConfig } from "viem/op-stack";

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

const client = createPublicClient({ chain: katana, transport: http() });

const finalized = await client.getBlock({ blockTag: "finalized" });
const isFinal = (txBlock) => txBlock <= finalized.number;

viem does ship a katana chain in viem/chains, but as of viem 2.47 it is a plain chain definition without the OP Stack formatters, so receipt fields like l1Fee come back as raw hex strings. Spreading chainConfig from viem/op-stack, as above, adds them.

The soft/hard distinction is covered in general terms in L2 finality: soft vs hard.

Fees: almost all execution, almost no L1

Katana receipts carry the standard OP Stack L1 fee fields: l1Fee, l1GasPrice, l1GasUsed, l1BlobBaseFee, l1BaseFeeScalar, l1BlobBaseFeeScalar. On most OP Stack chains the L1 data fee is a large part of what a user pays. On Katana it isn't. Across 12 recent user transactions:

That sample averaged about 0.000003 ETH per transaction, under a cent at current ETH prices. The practical upshot: on Katana, eth_estimateGas × eth_gasPrice is a good estimate of the full cost. If you want the L1 part anyway, the chainConfig formatters above parse the receipt fields into bigints:

const receipt = await client.getTransactionReceipt({ hash: "0x..." });
const total = receipt.gasUsed * receipt.effectiveGasPrice + (receipt.l1Fee ?? 0n);

Or ask the GasPriceOracle predeploy (0x420000000000000000000000000000000000000F) with getL1Fee(bytes) before sending. For 100 bytes of calldata it returned 420,810,233 wei, a fraction of a millionth of an ETH.

Archive and tracing

The node behind our Katana endpoint is op-reth, and it serves full history: eth_getBalance worked 128, 10,000 and 1,000,000 blocks back and at block 1. The Reth tracing APIs are there too:

• debug_traceBlockByNumber and debug_traceTransaction with callTracer
• trace_block and trace_transaction
• eth_getBlockReceipts for all receipts in one call

With a block every second, eth_getBlockReceipts matters: indexing a day of Katana receipts is 86,400 calls with it, and one call per transaction without it. For internal calls and value transfers, see trace_filter and trace_transaction.

Trust model, briefly

Katana is Stage 0 on L2BEAT. Validity proofs protect state transitions, but the sequencer and proposer are centralized. Users can force a transaction through L1 with a delay of up to 12 hours if the sequencer censors them. Contract upgrades have no exit window. None of that changes how you call the RPC, but it belongs in the risk section of anything that holds user funds on the chain. The sequencer's role in general is explained in what is a sequencer.

The short version

• Chain ID 747474, ETH for gas, standard OP Stack JSON-RPC.
• 1-second blocks: subscribe instead of polling; 30,000-block eth_getLogs windows cover about 8 hours.
• finalized is about 26 minutes behind latest, and there is no seven-day withdrawal window: validity proofs settle it.
• Fees are almost entirely L2 execution; the L1 data fee was 0.2% in our sample.
• Full archive, debug_* and trace_* are available.

Katana HTTP and WebSocket endpoints, with the live block height and WebSocket status, are on our Katana RPC page. The same key works across 83 chains, and SwiftNodes has a free tier to start with.