Lens Chain RPC: A Developer's Guide (Chain ID 232)

Lens Chain is the home of Lens, the social protocol: accounts, usernames, follows, feeds and posts live there as contract state. It is built on ZKsync's ZK Stack, so it answers ordinary Ethereum JSON-RPC and viem and ethers connect without changes. Three things set it apart from other ZK Stack chains, though: gas is paid in GHO instead of ETH, most transactions are sponsored by a paymaster, and the chain only produces a block when there is something to put in it.

Everything below was measured against the live chain on October 15, 2026, through the same endpoint SwiftNodes customers use.

The endpoint

https://rpc.swiftnodes.io/rpc/lens?key=YOUR_API_KEY
wss://rpc.swiftnodes.io/ws/lens?key=YOUR_API_KEY

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

const lens = defineChain({
  id: 232,
  name: "Lens Chain",
  nativeCurrency: { name: "GHO", symbol: "GHO", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/lens?key=YOUR_API_KEY"] } },
});

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

Note the native currency. eth_getBalance on Lens Chain returns a GHO balance, and every fee in this guide is in GHO. A wallet or dashboard that labels native balances "ETH" by default will be wrong here.

What we measured

Blocks only when there is work

Most chains tick at a fixed interval and produce empty blocks when nothing happens. Lens Chain doesn't. The last 10,000 blocks averaged 27 seconds apart, and a sample of 60 recent blocks held 71 transactions, so a typical block carries a single transaction. The block number counts transactions more than time.

That breaks two habits:

• Block numbers are not a clock. "Wait 10 blocks" might mean 30 seconds or 10 minutes. Wait on timestamps, or on the safe and finalized tags.
• Polling for new heads is mostly idle. A loop that calls eth_blockNumber every second gets the same answer about 26 times out of 27. On the WebSocket URL, eth_subscribe with newHeads delivered 3 heads and 17 matching logs in 60 seconds, and only sends when there is something new.

GHO gas, and why it is 2.77 gwei

The gas price is set by zks_getFeeParams, the same as on any ZK Stack chain, with one extra step. The chain's minimal L2 gas price is 36,948,438 wei in ETH terms, and a conversion ratio of 75 turns that into the base token: 36,948,438 × 75 is 2.771 gwei. That matches eth_gasPrice and the baseFeePerGas on every block we read, so on a quiet chain the price is flat.

As on other ZK Stack chains, a transfer is not 21,000 gas. The plain GHO transfers we sampled each used 77,629 gas, because ZKsync charges for account validation and the state change it records. eth_estimateGas for a transfer returned 143,389. The estimate includes headroom and unused gas is refunded, so the cost is what the receipt says: 77,629 × 2.77 gwei = 0.000215 GHO. Use the estimate as the gas limit and the receipt for accounting.

zks_estimateFee returns the same limit plus gas_per_pubdata_limit, which you need if you build EIP-712 transactions yourself. More on those differences in ZKsync Era RPC differences.

Two thirds of transactions are sponsored

Lens apps generally pay gas for their users. Out of 45 transactions we pulled with zks_getRawBlockTransactions, 30 named a paymaster, a contract that pays the fee on the sender's behalf. Two paymaster contracts covered all 30. The rest were 10 legacy transactions, 4 unsponsored EIP-712 transactions and one EIP-1559 transaction.

This is ZK Stack's native account abstraction: the sponsorship is part of the protocol transaction (type 0x71), not an ERC-4337 bundle. Consequences for indexers and analytics:

• The sender often holds no GHO. None of the 15 senders we checked had contract code, so they are ordinary keys, but a zero balance doesn't mean an account is inactive.
• The fee payer is not in the standard fields. eth_getTransactionByHash doesn't show the paymaster. Use zks_getRawBlockTransactions (field common_data.L2.paymasterParams) if you need to know who paid.
• Fee totals per user are misleading. Summing gasUsed × effectiveGasPrice by from counts gas the user never paid.

Data on Avail, finality on Ethereum

Lens Chain is a validium: it proves its state on Ethereum but publishes transaction data to Avail instead. The fee parameters show it: l1_pubdata_price is 0, because the chain doesn't pay Ethereum for data. Our rollup vs validium vs optimium post explains the trade-off. For RPC users, it explains why fees are flat and low and don't follow Ethereum gas.

What takes time is the batch. zks_getL1BatchBlockRange and zks_getL1BatchDetails show the cycle:

The finalized tag pointed exactly at the last block of batch 9175, 10.8 hours behind the head. safe follows the committed batch and was 2.8 hours behind. A transaction early in a batch waits roughly 8 hours for the batch to close plus 5.5 hours on Ethereum, about 13.5 hours in total. One at the end of a batch waits about 5.5 hours. That is much slower than Abstract, another ZK Stack chain, where batches close every 12 minutes. The difference is traffic: a batch closes when it fills up or times out, and Lens Chain fills slowly.

Show users latest, which is final in practice for social actions. Wait for finalized only where it matters, such as withdrawals to Ethereum. Our finality survey across 62 chains and soft vs hard finality on L2s have the wider picture.

Logs: dense blocks, a result cap

Lens activity is all contract events, so the chain is dense with logs: 100 blocks returned 1,002 logs and about 1 MB of JSON. The cap is on results. A query that would return more than 10,000 logs fails with:

Query returned more than 10000 results. Try with this block range [0x60f434, 0x60f868].

At about 10 logs per block, an unfiltered query hits that cap at roughly 1,000 blocks. One 1,000-block request failed earlier with backend response too large instead. Filter by contract address and topic, and when the cap error comes back, retry with the range it suggests:

async function getLogsPaged(filter: { address?: `0x${string}`; fromBlock: bigint; toBlock: bigint }) {
  const out = [];
  let from = filter.fromBlock;
  while (from <= filter.toBlock) {
    let to = filter.toBlock;
    for (;;) {
      try {
        out.push(...(await client.getLogs({ ...filter, fromBlock: from, toBlock: to })));
        break;
      } catch (e: any) {
        const m = /\[(0x[0-9a-f]+), (0x[0-9a-f]+)\]/i.exec(String(e?.details ?? e?.message));
        to = m ? BigInt(m[2]) : from + (to - from) / 2n;
      }
    }
    from = to + 1n;
  }
  return out;
}

More on how providers limit log queries in eth_getLogs range caps.

History, tracing and methods

Historical state reads worked at every depth we tried, back to 3 million blocks, about half of the chain since block 1 on February 21, 2025. debug_traceTransaction with callTracer returned full call trees, including the system-contract calls ZKsync makes on each transaction. eth_getBlockReceipts works. The trace_* namespace does not.

Summary

• ZK Stack validium for the Lens social protocol, chain ID 232, gas in GHO.
• Blocks only when there are transactions, about 27 s apart: wait on time or tags, not block counts.
• Flat 2.77 gwei gas price; transfers use ~78k gas, about 0.0002 GHO. Always estimate.
• Two thirds of transactions are paymaster-sponsored; find the payer with zks_getRawBlockTransactions.
• 8-hour batches: safe ~2.8 h, finalized ~11 h behind the head.
• eth_getLogs caps results at 10,000 (about 1,000 blocks unfiltered) and suggests a range.

Lens Chain endpoints and method support are on our Lens Chain RPC page, with 127 other chains on the same key. SwiftNodes has a free tier to try it.