7Block Labs
Blockchain Infrastructure

ByAUJay

EIP-402, EIP-7623 Ethereum, EIP-1898 JSON-RPC Block Parameter by Hash or Number: Why They Matter for Infra Teams

Description: What infra leads need to know right now: how to make JSON-RPC reads reorg-resilient with EIP-1898, what EIP-7623’s calldata repricing actually changes in production after Pectra, and why “EIP‑402” is really HTTP 402/x402—and how to wire it safely to Ethereum payments.


TL;DR for decision‑makers

  • If your node, indexers, and services are not EIP‑1898‑aware, your “read coherence” under reorgs is probabilistic at best. Adopt the object-style block parameter (by hash or number) and treat “safe”/“finalized” as first‑class tags in RPC. (eips.ethereum.org)
  • EIP‑7623 went live with Pectra on May 7, 2025. Calldata‑heavy transactions now pay a floor price, shrinking worst‑case EL payload size and nudging DA off calldata and into blobs. Rollup batchers, gas estimators, and cost models must be updated. (blog.ethereum.org)
  • There is no “EIP‑402.” Teams using that label almost always mean HTTP 402 “Payment Required” a.k.a. x402—the emerging protocol for pay‑per‑API over HTTP that today relies on EIP‑3009 tokens (e.g., USDC) or smart‑EOA flows. Treat it as web infra plus onchain settlement, not an Ethereum core change. (developer.mozilla.org)

Where Ethereum is today: dates and parameters your infra should anchor on

  • Pectra mainnet: activated May 7, 2025 at epoch 364032 (10:05:11 UTC). It included EIP‑7623 (calldata repricing) and EIP‑7691 (blob throughput increase from 3/6 to 6/9 target/max). (blog.ethereum.org)
  • Fusaka mainnet: scheduled Dec 3, 2025 at 21:49:11 UTC, introducing Blob Parameter Only (BPO) forks to safely lift blob counts post‑PeerDAS. BPO1 raised per‑block target/max to 10/15 on Dec 9, 2025; BPO2 is scheduled for Jan 7, 2026 to raise to 14/21. Anchor your capacity planning and alerting to these dates. (blog.ethereum.org)

Implication: Between Pectra and Fusaka+BPO, Ethereum is explicitly steering data availability to blobs and compressing the tails of block payload sizes. Calldata as a DA channel is now an emergency relief valve, not your default. (blog.ethereum.org)


EIP‑1898: make your reads reorg‑resilient and deterministic

What changed: EIP‑1898 lets clients pass a structured “block parameter” to state‑querying methods—either a blockNumber or a blockHash—with an optional requireCanonical flag. Affected methods include eth_getBalance, eth_getStorageAt, eth_getTransactionCount, eth_getCode, eth_call, and eth_getProof. (eips.ethereum.org)

Why infra teams should care:

  • Read coherence across N RPC calls: pin all calls to the same blockHash and you’ll never mix states across a reorg window.
  • Canonicality control: requireCanonical=true forces the node to reject reads from non‑canonical blocks with a distinct error code (-32000), while missing blocks return -32001. This makes retries and incident triage predictable. (eips.ethereum.org)
  • Safer “latest-ish” tags: after the Merge, Ethereum recognizes “safe” and “finalized” block tags that jump by epoch rather than by block. For analytics and payments‑adjacent logic, prefer safe or finalized over latest. (ethereum.org)

Practical example: pinning to a block hash with canonicality requirements (Node.js)

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

const client = createPublicClient({ chain: mainnet, transport: http(process.env.RPC!) });

async function coherentAccountSnapshot(address: `0x${string}`, blockHash: `0x${string}`) {
  // requireCanonical: true means we’d rather fail than read from a reorged block
  const blockParam = { blockHash, requireCanonical: true };

  const [balance, nonce, code] = await Promise.all([
    client.getBalance({ address, blockNumber: undefined, blockTag: undefined, block: blockParam as any }),
    client.getTransactionCount({ address, block: blockParam as any }),
    client.getCode({ address, block: blockParam as any }),
  ]);

  return { balance, nonce, code };
}

Minimal retry policy:

  • If error.code === -32001 → block not found: re‑fetch the latest safe head and retry;
  • If error.code === -32000 → not canonical: fetch the canonical hash for that height and retry or shift to safe;
  • Else fail fast and alarm.

Pro tip: for dashboards and customer‑visible balances, default to “safe” not “latest”; for settlement‑critical logic, use “finalized.” This trades a bounded freshness lag (minutes) for drastically lower reorg risk. (ethereum.org)

JSON‑RPC request shape (raw):

{
  "jsonrpc":"2.0",
  "id":1,
  "method":"eth_call",
  "params":[
    {"to":"0x...","data":"0x..."},
    {"blockHash":"0xabc123...","requireCanonical":true}
  ]
}

Reference error semantics and method list per EIP‑1898. Wire your client error handling to these exact codes. (eips.ethereum.org)


EIP‑7623: calldata costs changed—what to fix in gas estimators, batchers, and cost models

What EIP‑7623 does: introduces a floor price on calldata proportional to “tokens_in_calldata,” where tokens = zero_bytes + 4×nonzero_bytes. Transactions with too much calldata relative to EVM compute now pay 10/40 gas per byte (floor), shrinking worst‑case block size and variance. Parameters: STANDARD_TOKEN_COST=4; TOTAL_COST_FLOOR_PER_TOKEN=10. Included in Pectra. (eips.ethereum.org)

Why infra teams should care:

  • Gas estimation must reserve the floor up front: a tx gasLimit must cover 21000 + TOTAL_COST_FLOOR_PER_TOKEN×tokens_in_calldata even if execution will refund/underuse; otherwise the tx is invalid and will never be processed. (eips.ethereum.org)
  • Calldata DA becomes cost‑inefficient: rollups relying on calldata as their “overflow” path should expect step‑function cost increases on data‑heavy frames; prioritize blob pipelines. (blog.ethereum.org)
  • Block builder behavior: variance reduction opens headroom for higher blob counts and future gas limit tuning; your throughput models need new ceilings and tails.

Drop‑in utility for Node.js estimators:

// EIP-7623 floor calculator
export function eip7623CalldataFloorGas(calldata: Uint8Array) {
  let zero = 0, nonzero = 0;
  for (const b of calldata) (b === 0) ? zero++ : nonzero++;
  const tokens = BigInt(zero) + BigInt(nonzero) * 4n; // tokens_in_calldata
  const floorPerToken = 10n; // TOTAL_COST_FLOOR_PER_TOKEN
  return 21000n + floorPerToken * tokens;
}

// Wrap around eth_estimateGas()
export async function estimateWithFloor(ethEstimateGas: (tx:any)=>Promise<bigint>, tx: any, calldataHex: string) {
  const baseEstimate = await ethEstimateGas(tx);
  const data = Uint8Array.from(Buffer.from(calldataHex.replace(/^0x/, ''), 'hex'));
  const floor = eip7623CalldataFloorGas(data);
  return baseEstimate > floor ? baseEstimate : floor;
}

Operational checklist you should implement this quarter:

  • Wallets/services: patch estimators to add the floor reserve before submitting user txs; log any “intrinsic gas too low” rejects as a regression test. (eips.ethereum.org)
  • Sequencers/batchers: re‑weight frame split points; target blobs first, and only route to calldata under explicit SLO violations. Track price deltas vs blob base fee. (blog.ethereum.org)
  • Capacity planning: post‑Fusaka, blob target 14/max 21 is scheduled as of January 7, 2026—update daily DA throughput assumptions and alerts for under/over‑utilization. (blog.ethereum.org)

“EIP‑402” is not an EIP: it’s HTTP 402/x402—what it is and how to ship it safely

Reality check: the term “EIP‑402” is a misnomer you’ll hear in product and go‑to‑market decks. 402 is an HTTP status code (“Payment Required”). x402 is an open protocol that makes pay‑per‑request work using 402 responses plus a base64 payment header on retry. It’s not part of Ethereum’s core; it’s a web‑payment pattern that settles onchain. (developer.mozilla.org)

Key moving parts for EVM today:

  • Tokens: x402 flows on EVM currently lean on ERC‑3009 “TransferWithAuthorization” (e.g., USDC). Users sign an EIP‑712 authorization; a facilitator pays gas and settles onchain. This is why asset coverage matters. (eips.ethereum.org)
  • Client/server contract: server returns 402 with PaymentRequirements JSON (asset, network, payTo, maxAmountRequired, timeout). Client retries with X‑PAYMENT header carrying a signed payload. Server verifies/settles directly or via a facilitator and returns 200 plus an optional receipt header. (github.com)

Wire‑level sketch:

GET /v1/infer HTTP/1.1
Host: api.example.ai
Accept: application/json
HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "x402Version": 1,
  "accepts": [{
    "scheme": "exact",
    "network": "base",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC
    "maxAmountRequired": "1000",
    "payTo": "0xMerchant...",
    "maxTimeoutSeconds": 600,
    "description": "Pay $0.001 for this request"
  }]
}
GET /v1/infer HTTP/1.1
Host: api.example.ai
X-PAYMENT: eyJ4NDAyVmVyc2lvbiI6MSwic2NoZW1lIjoiZXhhY3QiLCJuZXR3b3JrIjoiYmFzZSIsInBheWxvYWQiOnsKICAiYXV0aG9yaXphdGlvbiI6IHsiZnJvbSI6ICJ... (b64 JSON)

Best‑practice guardrails for infra and platform teams:

  • Bind the payment to the resource. Include URL/method hash in the EIP‑712 typed data so a stolen signature is useless elsewhere.
  • Enforce network/chainId strictly; reject mismatches to prevent “wrong‑net” replay. Most facilitators expose /verify and /settle endpoints—use /verify first for low‑latency. (github.com)
  • Token coverage: ERC‑3009 is not universal (e.g., USDT does not implement it). If your market requires USDT or non‑3009 assets, you’ll need wrapper tokens, a hybrid flow, or a 7702‑style authorization once wallets support it broadly. Document these tradeoffs early. (eips.ethereum.org)

Authoritative references for your architects and security reviewers: MDN’s 402 semantics and the x402 open spec. (developer.mozilla.org)


How the pieces fit together for infra leaders

  • Deterministic reads (EIP‑1898) + conservative tags (“safe”, “finalized”) are your base layer for correctness; apply them everywhere you don’t strictly need last‑block freshness. (eips.ethereum.org)
  • Calldata repricing (EIP‑7623) forces the last mile: blobs for DA, not calldata. Expect quieter p2p propagation, more predictable block sizes, and easier blob‑count lifts via BPO forks—plan DA throughput by BPO schedule. (eips.ethereum.org)
  • 402/x402 is a web protocol you can adopt now; its safety depends on exactly how you verify/settle and what tokens you accept. Treat it like payments infra with onchain settlement hooks, not a “blockchain feature.” (github.com)

Implementation recipes and gotchas

  1. Hardening JSON‑RPC read paths
  • Policy:
    • External‑facing APIs: default to blockTag="safe".
    • Financial/stateful ops: require “finalized” or a concrete blockHash with requireCanonical=true.
  • RPC providers differ: some L2s do not expose “safe/finalized” tags—feature‑detect per chain and gracefully degrade to blockNumber. (docs.moonbeam.network)
  1. EIP‑7623 upgrades in clients/services
  • Gas floor accounting in:
    • wallet backends and custodial signers,
    • relayers/bundlers,
    • any code that sets gasLimit by formula or static margins.
  • Alerting: watch for spikes in “intrinsic gas too low” and estimation underflows after deploys; enforce CI tests with synthetic calldata‑heavy txs. (eips.ethereum.org)
  1. Blob‑first DA pipelines
  • Sequencer playbook: prefer EIP‑4844 blobs; only fall back to calldata under explicit SLO breaches. After BPO2 (target/max 14/21), raise per‑window blob budgets. Use blob base fee curves in your cost model. (blog.ethereum.org)
  1. 402/x402 productionization
  • Verification path: resource server → /verify first (<=30–50 ms typical), then async or inline /settle depending on endpoint UX; return X‑PAYMENT‑RESPONSE with tx metadata. (github.com)
  • Idempotency: include a paymentId (nonce) in EIP‑712 payloads; reject duplicates; store receipts for audit.
  • Key risk: token fragmentation. If you need USDT or non‑3009 assets, plan for wrappers or staged asset support; do not silently downgrade to custodial flows. (eips.ethereum.org)

Quick decision matrix

  • Need the freshest possible state and can tolerate reorg risk? Use latest but pin follow‑up calls to the returned block hash (EIP‑1898).

  • Need consistency and low reorg risk? Use “safe.”

  • Need settlement‑grade certainty? Use “finalized” or a finalized block hash. (ethereum.org)

  • Is your tx calldata‑heavy? Expect the floor (10/40 gas per byte for the heavy case). Budget and route to blobs when posting data. (eips.ethereum.org)

  • Monetizing APIs or agent calls? 402/x402 is web‑native and chain‑agnostic; on EVM today, ERC‑3009 assets give the best UX. Align payments support with your target user assets. (github.com)


Reference snippets you can paste into runbooks

Error handling for EIP‑1898:

  • -32001 “Resource not found”: block missing → refetch head/tag and retry once.
  • -32000 “Invalid input” with requireCanonical=true: reorged → shift to canonical hash or “safe/finalized.”

Estimator SLO for EIP‑7623:

  • Reject any tx build where gasLimit < 21000 + 10×tokens_in_calldata (with tokens defined per spec). Treat as coding error. (eips.ethereum.org)

x402 verification contract with ERC‑3009:

  • Prefer receiveWithAuthorization over transferWithAuthorization inside contracts to prevent front‑running; enforce domain separation and deadline windows. (eips.ethereum.org)

What to do this month

  • Audit all JSON‑RPC callers for EIP‑1898 support; ban raw hex block numbers in new code unless pinned from a preceding getBlock. Document error code‑based retries. (eips.ethereum.org)
  • Patch gas estimation libraries to include the EIP‑7623 floor and add CI tests with zero‑byte‑heavy calldata. (eips.ethereum.org)
  • If you run or depend on batchers/sequencers: validate blob budgets against BPO1/BPO2 schedules and update alerts for blob underutilization or blob base fee spikes. (blog.ethereum.org)
  • If “EIP‑402 payments” is on your roadmap, rewrite your docs to “HTTP 402/x402” and add a formal threat model plus receipts and idempotency. Pin to ERC‑3009 (or declare unsupported assets) and publish SLAs for verification/settlement. (github.com)

Further reading (authoritative sources)

  • EIP‑1898: block parameter by hash or number; methods, error codes, examples. (eips.ethereum.org)
  • EIP‑7623: calldata floor parameters and formulas; compatibility notes for eth_estimateGas. (eips.ethereum.org)
  • Pectra announcement: inclusion of EIP‑7623 and EIP‑7691; rationale for variance reduction alongside blob scaling. (blog.ethereum.org)
  • Fusaka/BPO schedule: dates and blob target/max plan (10/15 then 14/21). (blog.ethereum.org)
  • HTTP 402 status (MDN) and x402 protocol overview/spec (Coinbase OSS). (developer.mozilla.org)
  • ERC‑3009 spec: TransferWithAuthorization details and EIP‑712 domain. (eips.ethereum.org)

By aligning your read semantics (EIP‑1898), gas/DA strategy (EIP‑7623 + blobs), and web‑native monetization (HTTP 402/x402), you’ll reduce tail risks, cut ambiguous incident handling, and open a clean path for automated, on‑demand payments—all without waiting for another hard fork.

Like what you're reading? Let's build together.

Get a free 30‑minute consultation with our engineering team.

Related Posts

7BlockLabs

Full-stack blockchain product studio: DeFi, dApps, audits, integrations.

7Block Labs is a trading name of JAYANTH TECHNOLOGIES LIMITED.

Registered in England and Wales (Company No. 16589283).

Registered Office address: Office 13536, 182-184 High Street North, East Ham, London, E6 2JA.

© 2025 7BlockLabs. All rights reserved.