DEV Community: OpenChainBench

Which cross-chain messaging protocol is actually fastest? An independent 2026 benchmark of Wormhole, LayerZero, Hyperlane, Axelar, and CCIP

OpenChainBench — Mon, 27 Jul 2026 16:41:00 +0000

The same cross-chain message can take 10 seconds or 25 minutes to deliver, depending on which chain you send it from and which messaging protocol you use. Same USDC value, same intent, roughly 150x difference in wall-clock time.

If you build anything cross-chain in 2026, the choice between Wormhole, LayerZero, Hyperlane, Axelar, and Chainlink CCIP is often made by trust preference, ecosystem alignment, or which SDK your team already knows. Rarely does it come down to actual measured performance, because independent latency data across all five protocols has been hard to find.

This post shares 24-hour rolling p50 medians for message delivery latency across all five, live from OpenChainBench — an open-source benchmark platform that probes each protocol continuously from three regions.

The finding that surprised me most: the dominant time cost is often the source chain's finality, not the messaging protocol itself. And the "fastest" protocol depends heavily on which source chain you route through.

What this benchmark measures

OpenChainBench runs a Go harness that observes each protocol's public delivery events. For each message, it computes:

Source-chain observation time (when the source chain includes the message)
Delivery time (when the destination chain confirms receipt for LayerZero, Hyperlane, Axelar, and CCIP, or when the protocol reaches signing quorum for Wormhole VAAs)

The delta is the latency. Every metric is:

Sampled every 60 seconds
Aggregated as a 24-hour rolling p50 median
Published under CC BY 4.0 licensing
Open source — the harness is public Go code on GitHub

No canary transactions, no synthetic traffic. Passive observation of live protocol usage. One consequence: routes with low traffic have smaller sample sizes and noisier percentiles. Sample sizes are visible on each live bench page.

Important caveat before comparing: four of the five protocols (Hyperlane, LayerZero, Axelar, CCIP) are measured end-to-end (source → destination). Wormhole is measured only up to VAA quorum (source → Guardian 13-of-19 signatures), because destination-side relay is caller-driven and not intrinsic to the protocol. So Wormhole numbers understate full user-facing latency — the true end-to-end for a Wormhole message is quorum time plus destination relay time.

Hyperlane: fastest end-to-end at 10-22 seconds

Source chain	Delivery p50 (24h)
Celo	10.0 s
Polygon	10.3 s
BNB Chain	10.3 s
Arbitrum	10.5 s
Ink	11.9 s
Unichain	12.7 s
Sonic	18.4 s
Avalanche	22.5 s

Live: openchainbench.com/benchmarks/hyperlane-message-latency

Hyperlane delivers in 10 to 22 seconds across all 8 measured source chains — the tightest range of any protocol here. Even the slowest chain (Avalanche at 22.5 s) beats the fastest chain on LayerZero, Axelar, or CCIP.

LayerZero: 26-48 seconds

Source chain	Delivery p50 (24h)
Monad	26.2 s
Robinhood Chain	26.9 s
Arbitrum	31.5 s
BNB Chain	33.3 s
Avalanche	34.4 s
Celo	42.0 s
Sui	45.0 s
Solana	48.3 s

Live: openchainbench.com/benchmarks/layerzero-message-latency

LayerZero delivers in 26 to 48 seconds — roughly 2 to 3 times slower than Hyperlane on comparable chains. Interesting anomaly: Arbitrum on LayerZero delivers end-to-end in 31.5 s, while Wormhole reaches quorum on Arbitrum in about 16 minutes (VAA-only, so the true Wormhole end-to-end is longer still). LayerZero's Ultra Light Node model uses different security assumptions than Wormhole's Guardian quorum, which explains the gap.

Wormhole: 5 seconds to 19 minutes (VAA quorum only)

Reminder: Wormhole's benchmark measures only source-side VAA finalization to 13-of-19 Guardian quorum. Destination-side relay adds more time and is caller-driven.

Source chain	VAA finalization p50
Sui	4.6 s
Monad	5.2 s
Berachain	7.5 s
Polygon	7.6 s
BNB Chain	7.9 s
Avalanche	8.5 s
Ink	10.0 s
Injective	12.5 s
Solana	18.5 s
Moonbeam	43.0 s
Ethereum	14 min
Arbitrum	16 min
Unichain	18 min
Base	19 min

Live: openchainbench.com/benchmarks/wormhole-vaa-latency

Two very different behaviors emerge. Non-Ethereum-finality chains (Sui, Monad, BNB, Solana) reach quorum in single-digit seconds. Chains that inherit Ethereum L1 finality (Ethereum, Arbitrum, Base, Unichain) wait 14 to 19 minutes. This is not Wormhole's design — Guardians refuse to sign until the source-chain state is finalized on Ethereum L1, which takes approximately two epochs (~13 min).

Axelar: 40 seconds on fast chains, 15+ min on Ethereum L2s

Source chain	Delivery p50 (24h)
BNB Chain	40.6 s
Osmosis	47.2 s
Polygon	50.7 s
Avalanche	64.3 s
Moonbeam	95.1 s
Ethereum	17 min
Arbitrum	20 min
Base	25 min

Live: openchainbench.com/benchmarks/axelar-gmp-latency

Same pattern as Wormhole. Fast on non-Ethereum-finality chains, slow on Ethereum-inheriting L2s. Base at 25 minutes is the slowest end-to-end measurement in this dataset.

Chainlink CCIP: 75 seconds to 17 minutes

Source chain	Delivery p50 (24h)
BNB Chain	74.8 s
Solana	82.2 s
Avalanche	90.0 s
Monad	92.0 s
Polygon	13 min
Ethereum	17 min
Robinhood Chain	17.5 min
Optimism	17.5 min

Live: openchainbench.com/benchmarks/chainlink-ccip-latency

CCIP is the slowest of the four end-to-end protocols measured, even on fast chains. This reflects Chainlink's more conservative security model — CCIP uses two independent risk-management systems that add latency but reduce trust assumptions.

The finality-depth choice: Polygon as a case study

Same source chain, dramatically different delivery times depending on the protocol. Polygon illustrates this best:

Protocol	Polygon delivery p50
Wormhole (VAA quorum only)	7.6 s
Hyperlane (end-to-end)	10.3 s
Axelar (end-to-end)	50.7 s
Chainlink CCIP (end-to-end)	13 min

Polygon has the same actual finality time regardless of who observes it. The variance comes from what each protocol chooses to wait for. Hyperlane accepts Polygon at a lower confirmation depth. CCIP waits for a much deeper confirmation before signing, trading time for security. This is a protocol-level design choice, not a chain property.

The takeaway for builders: even after picking your source chain, the protocol's finality-depth policy can multiply your delivery time by 100x. Fast finality is only fast if the protocol trusts it.

The finality tax

Across every protocol, a consistent pattern emerges: chains that inherit Ethereum L1 finality (Ethereum, Arbitrum, Base, Optimism, Unichain) impose 14 to 25 minutes of waiting time regardless of which messaging protocol you use.

This is not the protocol's fault. It is the source chain's finality guarantee.

If your dApp originates cross-chain messages from Base and users complain the bridge is slow, no protocol change will fix it. The wait is in Ethereum L1 finality. The only way to meaningfully reduce it is to originate the message from a chain with faster finality (Sui, Monad, BNB Chain, Solana, Cosmos-adjacent chains).

Conversely, choosing between Hyperlane, LayerZero, and Wormhole matters a lot on fast-finality chains where the messaging protocol itself becomes the bottleneck. On Sui, Wormhole reaches quorum in 5 seconds while other protocols take longer. On Celo, Hyperlane delivers end-to-end in 10 seconds while LayerZero takes 42 seconds. The differences compound depending on your source chain and the protocol's confirmation policy.

Which protocol should you use?

Based on this dataset, a rough decision framework:

Building on non-Ethereum-finality chains (Sui, Monad, BNB Chain, Solana, Avalanche, Cosmos-adjacent):
Hyperlane offers the tightest and fastest end-to-end latencies. Wormhole is competitive at the quorum step but the full end-to-end depends on destination-side relay. LayerZero is a middle option. Same-chain, cross-protocol deltas can be large (see Polygon above) — verify on the specific route you care about.

Building on Ethereum L2s that inherit L1 finality (Arbitrum, Base, Optimism, Unichain):
Protocol choice is largely irrelevant for speed — you'll wait 14-25 min for finality regardless. Choose based on trust assumptions, ecosystem alignment, or which chain you're bridging to.

Building on Ethereum L1:
Same as above — expect a 14-17 minute latency floor imposed by L1 finality.

Building on Cosmos-adjacent chains (Osmosis, Injective, Celo):
Hyperlane is fastest at 10 s on Celo. Axelar is native to Cosmos SDK but slower (47 s on Osmosis).

How to reproduce these measurements

OpenChainBench is fully open source. Every metric on the site is a Prometheus query against public data. You can reproduce any measurement locally.

For Wormhole VAA finalization, the data source is the public wormholescan indexer:

curl "https://api.wormholescan.io/api/v1/vaas?pageSize=100"

Each VAA row includes:

timestamp — source chain observation time
updatedAt — when wormholescan first indexed the VAA as fully-signed

The delta is the VAA finalization latency. OCB polls this endpoint every 60 seconds and computes rolling p50/p90/p99 percentiles.

For the messaging protocols (Hyperlane, LayerZero, Axelar, CCIP), similar public event feeds exist. The Go harness for each is on GitHub, linked from each benchmark page.

Resources

Full list of benchmarks: openchainbench.com
Hyperlane message latency
LayerZero message latency
Wormhole VAA finalization
Axelar GMP latency
Chainlink CCIP latency
Data license: CC BY 4.0

All figures reflect 24-hour rolling p50 medians as of publication. Live dashboards update every 60 seconds — current numbers may differ. Each live dashboard is the authoritative source at any given moment.

If you're building cross-chain and want a specific data point I didn't cover, ping @openchainbench on X or check the live dashboards directly.

Auto pick the cheapest cross chain bridge in Python with OpenChainBench

OpenChainBench — Sun, 26 Jul 2026 06:13:01 +0000

Why bridge selection matters more than you think

If you build a dapp that moves USDC across chains, you probably picked a bridge provider two years ago and never looked back. That decision is quietly costing your users money. Independent measurements show a fifteen times difference between the cheapest and the most expensive bridge on a $300 USDC transfer. NEAR Intents leads at 0.058 percent effective cost. deBridge trails at 0.897 percent. On a $10,000 transfer, that gap is roughly $84 out of your users' pockets for no additional service.

This post walks through how to auto pick the cheapest bridge at runtime using OpenChainBench, a public benchmark that measures six major bridges every minute from three regions. The full leaderboard lives at https://openchainbench.com/benchmarks/bridge-fee. We look at two approaches. First, a plain REST call for classic dapps. Second, an MCP integration for AI agent workflows.

Approach 1: Query the REST API from Python

The benchmark exposes every ranking as JSON via a stable endpoint. No API key required.

import requests

def get_cheapest_bridge() -> str:
    """Return the name of the cheapest cross chain bridge right now."""
    response = requests.get(
        "https://openchainbench.com/api/stat/bridge-fee",
        timeout=10,
    )
    response.raise_for_status()
    data = response.json()
    return data["leader"]["name"]

if __name__ == "__main__":
    leader = get_cheapest_bridge()
    print(f"Cheapest bridge right now: {leader}")

Expected output:

Cheapest bridge right now: Near Intents

The endpoint returns the full ranking too, so you can route by health status or fall back if the leader is temporarily down.

import requests

def rank_bridges() -> list[dict]:
    response = requests.get(
        "https://openchainbench.com/api/stat/bridge-fee",
        timeout=10,
    ).json()
    return [
        {"name": r["name"], "effective_cost_pct": r["ms"]["p50"]}
        for r in response["rankings"]
    ]

for bridge in rank_bridges():
    print(f"{bridge['name']:15} {bridge['effective_cost_pct']:.3f} percent")

Expected output:

Near Intents    0.058 percent
Relay           0.134 percent
Across          0.136 percent
Mobula          0.221 percent
LI.FI           0.423 percent
deBridge        0.897 percent

Now you have live data. Route your users through the cheapest available bridge and cache the result for five to ten minutes to avoid hammering the endpoint.

Approach 2: MCP integration for AI agents

If you build an AI trading agent or a chatbot that helps users move funds, plain REST calls put the routing logic in your code. You want the LLM to reason about bridge selection dynamically based on context. That is where Model Context Protocol comes in.

OpenChainBench exposes an MCP server that any MCP compatible client can consume. Claude Desktop, Cursor, and other MCP hosts can query the benchmark data natively through function calls, without you writing wrapper code.

claude mcp add openchainbench https://openchainbench.com/api/mcp/mcp

The server exposes three tools: list_benchmarks, get_benchmark, and query_prom. Once registered, your AI agent can answer questions like "which bridge is cheapest for a $300 USDC transfer from Solana to Base right now" by calling the tools directly, no extra plumbing needed.

Example agent interaction:

User: I need to move $500 USDC from Solana to Base. What is the cheapest option?

Agent: Based on OpenChainBench live data, NEAR Intents is currently the cheapest at 0.058 percent effective cost (fees plus slippage plus destination gas). Relay is second at 0.134 percent. On $500, the difference is about $0.38 in your favor with NEAR Intents.

The agent pulls fresh data at query time, so it never quotes stale numbers.

Comparison of the two approaches

Approach	Best for	Setup effort	Data freshness
REST API	Classic dapps, backend routing	5 minutes	Real time
MCP server	AI agents, chatbots, Claude Desktop	2 minutes	Real time

Both approaches are free and require no API key. Data is published under CC BY 4.0.

FAQ

Which cross chain bridge is currently the cheapest for USDC?

NEAR Intents leads the OpenChainBench bridge fee bench at 0.058 percent effective cost for $300 USDC transfers across Solana, Base, and Arbitrum corridors. Relay is second at 0.134 percent, Across at 0.136 percent.

What does effective cost include?

The benchmark counts bridge fee plus exchange slippage plus destination gas required to finalize the transfer. Headline fee alone is misleading because bridges recoup margin through slippage.

Is the OpenChainBench API rate limited?

The public REST endpoint has generous limits sufficient for backend routing use cases. For high volume production, cache the ranking for five to ten minutes.

Can I contribute a new bridge to the benchmark?

Yes, the harness is open source at https://github.com/ChainBench/OpenChainBench. Open an issue with the bridge you want added and the corridor to measure.

Does the MCP server work with clients other than Claude Desktop?

Yes, any MCP compatible client works: Cursor, Windsurf, generic MCP hosts, or custom LangChain and LlamaIndex agents.

Companion analysis

For the editorial deep dive on why bridge markets are opaque and what it means for builders, see the companion piece on Substack:
https://substack.com/home/post/p-208526753

The Archive Multiplier: Why eth_call at a Historical Block

OpenChainBench — Sun, 19 Jul 2026 15:38:59 +0000

TL;DR: Passing a historical blockNumber to eth_call, eth_getBalance or eth_getLogs silently routes your request to the archive tier of hosted RPC providers. In our production metrics, archive calls cost on average 26.7x more compute units than the same call at latest. This post explains why, shows the exact client code pattern that triggers it, and gives you three Prometheus queries to measure your own archive exposure in under a minute. Full cross provider measurements are published in the OpenChainBench RPC benchmarks.

Last week our RPC cost dashboard flagged an overage projection above four thousand dollars for a single billing cycle on a single provider. On paper, our services were doing normal eth_call operations. In practice, one small pattern buried in three separate indexers had multiplied our compute unit consumption by more than an order of magnitude, and nothing in the code review process had surfaced it.

This post breaks down what an archive multiplier is, why it silently inflates blockchain RPC bills across every major hosted provider, and how to detect it in your own Prometheus stack before the next overage alert lands in Slack.

What does "archive" mean at the Ethereum node level?

Every request that reads the state of a smart contract, whether through eth_call, eth_getBalance, eth_getStorageAt, eth_getCode, or a batch of these, requires the RPC node to reconstruct the world state at a specific block height.

Ethereum clients handle this in two modes.

Full node mode. The state trie is kept in memory or on fast SSD for the tip of the chain plus a rolling window of recent blocks. On Geth default settings that window is 128 blocks deep. Any query targeting latest, pending, or a block within that window resolves in a few milliseconds against the current state.

Archive node mode. The client preserves every intermediate state trie since genesis. Answering a query at a block from months or years ago requires reading historical trie data off disk and reconstructing the state at that point. This is orders of magnitude slower and dramatically more storage intensive. A mainnet Ethereum archive node currently requires around twenty terabytes of NVMe storage. A full node runs on about one and a half terabytes.

Hosted providers price this operational difference into their compute unit tables. The multiplier is not a bug in your billing. It reflects the real infrastructure cost of preserving all historical state.

The exact client code that triggers archive pricing

A typical viem call to read a token balance looks like this:

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

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

// Path A, cheap: reads the current state.
const balance = await client.readContract({
  address: TOKEN,
  abi: erc20Abi,
  functionName: 'balanceOf',
  args: [WALLET]
})

// Path B, expensive: reads state at a specific historical block.
const historicalBalance = await client.readContract({
  address: TOKEN,
  abi: erc20Abi,
  functionName: 'balanceOf',
  args: [WALLET],
  blockNumber: 18000000n
})

From a developer perspective the two calls are indistinguishable. Both return a bigint. The blockNumber parameter on the second call is what promotes the request to the archive tier on the provider side.

In our codebase we found this pattern in five categories of code paths:

Token balance backfills rebuilding historical wallet snapshots for analytics. Each snapshot iterates through blocks, calling balanceOf at each snapshot point.
Pool state reconstruction for liquidity analytics, calling getReserves() on Uniswap v2 pools or slot0() on Uniswap v3 pools at every historical trade block.
Bridge quote engines that need the exact token balance and allowance at the source block when validating a cross chain transfer.
Governance snapshots replaying votes at a historical block to verify quorum.
Audit tools and debuggers recomputing contract state at the block of a suspicious transaction to isolate the root cause of a bug.

None of these paths look expensive when you read them. They pass a single extra parameter to a familiar function call. But every one of those calls goes through the archive tier on the RPC provider.

How Alchemy, Chainstack and QuickNode price archive requests

Each provider publishes a compute unit or credit table in its public pricing documentation.

Alchemy documents its compute unit weights in the Alchemy compute units reference. The archive tier does not appear as a separate multiplier in the table itself. Instead, the archive rate applies once a request targets a block older than 128 blocks, and the effective cost per call in this mode is measured against the archive plan tier.

Chainstack uses Request Units and prices archive traffic at approximately double the standard rate on shared nodes. Enterprise archive dedicated nodes have a flat pricing model instead of per request billing.

QuickNode uses Credits per method. Archive calls carry a multiplier documented per method in the QuickNode API credits reference, typically between two and five times the equivalent full node call.

The observable behavior is consistent across all three. If you send the same request payload with and without a historical blockNumber parameter, the request without it hits the fast path and the request with it hits a slower and more expensive path. On heavily loaded indexers this compounds fast, because each iteration of a backfill loop produces one archive request.

What we measured on a production grade cluster

We instrument every outbound RPC call in our services with a Prometheus counter carrying labels for provider, method, chain, and node type. Over a rolling 24 hour window on one chain that receives moderate traffic, the raw breakdown was as follows:

Method	Raw requests	Compute units	Effective ratio
`eth_call` archive	2,470,000	65,970,000	26.7
`eth_getLogs` archive	355,000	9,500,000	26.8
`eth_getBalance` archive	49,200	1,315,000	26.7
`eth_call` full	4,000	4,000	1.0

The pattern is clean. Full mode calls average one compute unit per raw request. Archive mode calls on the same methods average close to twenty seven compute units per raw request. The ratio is stable across eth_call, eth_getLogs, and eth_getBalance, which are the three read paths that carry the vast majority of our traffic.

Translated into monthly cost on a moderately busy indexer on one chain, the archive share of that traffic drove roughly one thousand dollars of overage per month. Multiplied across five chains and three indexer instances, the number grows quickly into the tens of thousands per year.

How to detect archive exposure with 3 Prometheus queries

If you already record outbound RPC calls into a Prometheus counter, the following queries surface archive exposure in about thirty seconds.

Query 1. Absolute compute units by node type over 24 hours:

sum by (node_type) (
  increase(rpc_compute_units_total{provider="alchemy"}[24h])
)

Query 2. Archive share of total volume as a percentage:

sum(rate(rpc_compute_units_total{provider="alchemy", node_type="archive"}[1h]))
/
sum(rate(rpc_compute_units_total{provider="alchemy"}[1h]))
* 100

Query 3. Top ten source services and methods contributing to archive volume:

topk(10,
  sum by (app, method) (
    increase(rpc_compute_units_total{provider="alchemy", node_type="archive"}[24h])
  )
)

How to read the results:

Below 5 percent archive share: you are in good shape.
Between 5 and 20 percent: a specific backfill or indexer is doing more archive reads than it needs to, and the top ten query above will point at the culprit within seconds.
Above 50 percent: archive is your primary traffic pattern and the cost curve is dominated by the multiplier rather than by request volume, which usually means a stalled or looping job.

If you do not yet track this metric, the counter you want to add to your outbound HTTP transport takes labels for provider, method, chain, and node_type. Increment it once per response received, including 4xx and 5xx responses, because hosted providers bill errored calls just as they bill successful ones.

For a full working example of this instrumentation across twenty two chains and three geographic regions, the OpenChainBench RPC latency benchmarks publish the archive share of measured providers alongside p50, p95, and p99 latency. The instrumentation code that produces those metrics is open source on GitHub and the full approach is documented on the OpenChainBench methodology page.

5 strategies to reduce archive RPC costs in production

Once you have detected the pattern in your own metrics, five interventions consistently cut archive cost in production without changing product behavior.

1. Query at latest when the caller has no reason to pin a block. Audit every code path that passes a blockNumber parameter to readContract, getBalance, or getLogs. In a surprising fraction of cases the parameter was added defensively, without a functional requirement. Removing it drops the call from archive to full and eliminates the multiplier entirely.

2. Cache archive responses aggressively. An archive response for a finalized block is immutable. If your service asks for eth_call at block 18000000 today and again next week, the two responses are byte for byte identical. Wrapping archive calls in a Redis or Postgres cache with a TTL measured in months collapses repeat calls to a single provider hit.

3. Batch archive calls through Multicall3. If an indexer needs one hundred balanceOf reads at the same historical block, wrapping them in a single call to the Multicall3 contract at 0xcA11bde05977b3631167028862bE2a173976CA11 reduces the provider side accounting to one archive request instead of one hundred.

4. Materialize derived state in your own datastore. If your service repeatedly recomputes the same derived quantity from historical state, for example a token holder set at block N, write the result to your own Postgres or ClickHouse the first time and read from there for every subsequent access.

5. Split archive traffic onto a provider with a lower multiplier. The three providers price archive differently. If your workload is archive dominated, running a benchmark against Chainstack, QuickNode, and a self hosted archive node with the same request pattern will reveal cost differences worth thousands of dollars per month at production scale. The live RPC provider comparisons on OpenChainBench publish latency and error rate data across those providers so you can weigh cost against performance before switching.

The observability gap in current web3 SDKs

The reason this pattern persists in real codebases is that the archive tier is invisible from the SDK perspective. Viem, ethers, and web3.js expose blockNumber as a routine parameter with no warning that it changes the pricing tier on the RPC side. The provider knows, the developer does not, and the metric never surfaces until the monthly bill arrives.

Client side instrumentation with a node_type label is currently the only reliable way to close this gap. If you already use an eRPC middleware or a custom HTTP transport wrapper, adding the label at request emission time takes about thirty lines of code. Once the label is in place, alerting on archive share crossing a threshold becomes a one line Prometheus rule.

FAQ

What is an archive node in Ethereum?
An archive node stores every intermediate state trie since the genesis block, which allows it to answer state queries at any historical block height. It requires roughly 20 TB of NVMe storage on mainnet, compared to about 1.5 TB for a full node.

Why does eth_call at a historical block cost more?
Because the node must read historical trie data from disk and reconstruct the world state at that block, instead of serving the query from the hot state kept in memory for recent blocks. Hosted providers pass that infrastructure cost through as a compute unit multiplier.

How old does a block need to be to trigger archive pricing?
On most providers, any block older than the client's recent state window, which is 128 blocks on Geth default settings, is served from archive state and billed at the archive rate.

How can I tell how much of my RPC bill comes from archive calls?
Instrument your outbound RPC transport with a Prometheus counter labeled by provider, method, chain, and node type, then compute the archive share with the queries in this article. Independent cross provider archive measurements are also published in the OpenChainBench benchmarks.

Are archive responses safe to cache?
Yes, for finalized blocks. State at a finalized block is immutable, so responses can be cached indefinitely with no staleness risk.

Key takeaways

The archive multiplier is not a design flaw of hosted RPC providers. It reflects the real cost of preserving twenty terabytes of historical state on hot storage and answering queries against it. The problem is that the mechanism is invisible from client code, so the cost accumulates behind an opaque call that looks routine in a code review.

Three actions pay off immediately:

Instrument outbound RPC calls with a Prometheus counter that includes a node_type label.
Alert when the archive share of your total volume on any provider crosses five percent.
Audit every code path that passes blockNumber and either remove the parameter, cache the response, or batch through Multicall3.

Once the three are in place, the next overage alert arrives with the root cause already visible in your dashboard rather than requiring an emergency investigation across five services and two Postgres replicas.

If you want to see the full instrumentation applied to twenty two chains from three regions, OpenChainBench publishes the live results under an open methodology, with data under a Creative Commons license and the harness source on GitHub.

Originally published on the OpenChainBench blog. Benchmarks, methodology and raw data are available at openchainbench.com.