ChainBench · Flotapponnier · Jun 25, 2026 · Jun 25, 2026
@@ -6,15 +6,15 @@ short_answer: |
 benchmark: network-fees
 
 intro: |
- Wallet UX, micropayments, on-chain agents and gaming all break the same way: a five dollar transfer fee makes the use case impossible. This page answers one question with live data. Which chain is actually the cheapest to send a native transfer on right now, measured in dollars, not in gwei or lamports or stroops or sun. The OpenChainBench network-fees harness queries every chain's own fee market directly (eth_feeHistory for the EVM family, getRecentPrioritizationFees on Solana, koios epoch params on Cardano, fee_stats on Stellar, get_fee_estimate on Monero, Bag-of-Cells emulation on TON, getChainParameters on TRON, suix_getReferenceGasPrice on Sui), converts the result to the chain's smallest native unit, then multiplies by the live USD price of the native token. The output is the dollar amount a wallet user actually pays today. No marketing claim, no protocol-deterministic baseline that ignores priority bidding, no MATIC at peak gas reframed as the median.
+ Wallet UX, micropayments, on-chain agents and gaming all break the same way: a five dollar transfer fee makes the use case impossible. This page answers one question with live data. Which chain is actually the cheapest to send a native transfer on right now, measured in dollars, not in gwei or lamports or stroops or sun. The OpenChainBench network-fees harness queries every chain's own fee market directly (eth_feeHistory for the EVM family, getRecentPrioritizationFees on Solana, koios epoch params on Cardano, fee_stats on Stellar, get_fee_estimate on Monero, Bag-of-Cells emulation on Gram (formerly TON), getChainParameters on TRON, suix_getReferenceGasPrice on Sui), converts the result to the chain's smallest native unit, then multiplies by the live USD price of the native token. The output is the dollar amount a wallet user actually pays today. No marketing claim, no protocol-deterministic baseline that ignores priority bidding, no MATIC at peak gas reframed as the median.
 
 methodology: |
  Each chain is queried on its own fee surface every 30 seconds, never normalised to a synthetic gas estimate. The harness multiplies the chain's published fee parameter by a canonical transfer size for that chain (21000 gas for EVM native transfers, 5000 lamports base plus typical priority on Solana, 225 vBytes for a SegWit Litecoin transfer, 1500 bytes for a one-input two-output Monero RingCT transfer, 250 bytes for ADA, etc.), then converts to USD using Mobula's live price feed. The leaderboard ranks by 24h p50, so a single congestion spike does not move the headline number. Chains where the fee model is protocol-deterministic (Cardano, Stellar, TRON) are shown at the published rate parameter, which moves only when the parameter itself moves through on-chain governance.
 
 limitations:
  - "Native transfers are the cheapest possible transaction on each chain. Smart-contract calls (token transfer, swap, NFT mint) cost more, often by an order of magnitude on the EVM family because of storage writes."
  - "L2 figures cover L2 execution cost only. The L1 data-posting component (Ethereum blob calldata, EigenDA for Mantle) is not yet included, so the actual user-visible cost during expensive blob windows is higher than this leaderboard shows."
- - "TON publishes a conservative observed value because TON has no clean fee-estimate RPC; the real fee can fluctuate by workchain and shard."
+ - "Gram (formerly TON) publishes a conservative observed value because the Gram chain has no clean fee-estimate RPC; the real fee can fluctuate by workchain and shard."
  - "Native currency price volatility moves the USD figure independently of any change in the chain's fee market. A 20 percent ETH move shifts every Ethereum-denominated L1 and L2 transfer fee by the same percent."
 
 faq:

@@ -6,16 +6,16 @@ short_answer: |
 benchmark: l1-finality
 
 intro: |
- Finality is the point at which a confirmed transaction cannot be reversed without breaking the protocol's security assumptions. It is the right number to look at for cross-chain settlement, exchange withdrawal thresholds, bridge unlock conditions and any system that needs to know "is this real now or can it still be undone." This page answers one question with live measurement. Which L1 chain actually finalizes the fastest in wall-clock seconds, not in slot counts or in marketing claims. OpenChainBench measures every L1 against its own native finality definition: deterministic for BFT chains (Ethereum Casper FFG, Stellar SCP, Hedera Hashgraph, SUI Mysticeti, TON BAG) and convention-based for probabilistic chains (Bitcoin and similar by confirmation depth). The leaderboard ranks by 24h p50 wall-clock seconds.
+ Finality is the point at which a confirmed transaction cannot be reversed without breaking the protocol's security assumptions. It is the right number to look at for cross-chain settlement, exchange withdrawal thresholds, bridge unlock conditions and any system that needs to know "is this real now or can it still be undone." This page answers one question with live measurement. Which L1 chain actually finalizes the fastest in wall-clock seconds, not in slot counts or in marketing claims. OpenChainBench measures every L1 against its own native finality definition: deterministic for BFT chains (Ethereum Casper FFG, Stellar SCP, Hedera Hashgraph, SUI Mysticeti, Gram BAG) and convention-based for probabilistic chains (Bitcoin and similar by confirmation depth). The leaderboard ranks by 24h p50 wall-clock seconds.
 
 methodology: |
- Two methods are used, picked per chain. For chains whose finality is much longer than our 10 second poll interval (Ethereum, Solana, TRON, Litecoin, Monero) the harness compares `latest` and `finalized` block timestamps from the chain RPCs and takes the delta. For chains whose finality is faster than the poll interval (BNB, Avalanche, SUI, TON, Stellar) the harness maintains a persistent WebSocket or SSE subscription, recording wall-clock time T1 when block N is first seen as `latest` and T2 when it becomes `finalized`, with millisecond precision. The WS path is the only honest way to measure sub-poll-cadence finality; comparing two pointers at a single instant collapses to zero when finalization catches up to the head. Probabilistic chains (Litecoin, Monero) are measured against their conventional confirmation depth, not against a uniform depth across all chains.
+ Two methods are used, picked per chain. For chains whose finality is much longer than our 10 second poll interval (Ethereum, Solana, TRON, Litecoin, Monero) the harness compares `latest` and `finalized` block timestamps from the chain RPCs and takes the delta. For chains whose finality is faster than the poll interval (BNB, Avalanche, SUI, Gram, Stellar) the harness maintains a persistent WebSocket or SSE subscription, recording wall-clock time T1 when block N is first seen as `latest` and T2 when it becomes `finalized`, with millisecond precision. The WS path is the only honest way to measure sub-poll-cadence finality; comparing two pointers at a single instant collapses to zero when finalization catches up to the head. Probabilistic chains (Litecoin, Monero) are measured against their conventional confirmation depth, not against a uniform depth across all chains.
 
 limitations:
  - "Hedera's documented 3 to 5 second Hashgraph aBFT finality is not on the live leaderboard. Hedera mirror nodes only expose already-final blocks, so wall-clock measurement is impossible from public endpoints; re-enables once Block Nodes (HIP-1056) leave private preview."
  - "Probabilistic chains (Litecoin, Monero) settle on a confirmation-depth convention. The reported value is the time to that depth, which is the exchange-style settlement threshold, not a strict protocol-level finality."
  - "XRP is excluded by design: ledger_current has no close-time field, so wall-clock measurement requires a WS subscription to the ledger stream which is not yet implemented."
- - "Sub-second finalities on TON and SUI are real because both chains expose millisecond-precision timestamps. Sub-second finalities claimed by chains without millisecond timestamps would be a measurement artifact, not a protocol property."
+ - "Sub-second finalities on Gram (formerly TON) and SUI are real because both chains expose millisecond-precision timestamps. Sub-second finalities claimed by chains without millisecond timestamps would be a measurement artifact, not a protocol property."
 
 faq:
  - q: "What is blockchain finality?"
@@ -24,8 +24,8 @@ faq:
  a: "No. Solana exposes two commitments. Processed is optimistic and lands sub-second, typically under 500 milliseconds. Finalized requires 32 confirmed slots and clocks closer to 13 seconds in practice. The headline value here is finalized, the stricter guarantee. Sub-second Solana finality is real but only at the processed commitment level."
  - q: "Why is Ethereum finality 12.8 minutes?"
  a: "Ethereum uses Casper FFG which finalizes a checkpoint two epochs after it is justified. Each epoch is 32 slots of 12 seconds, giving 12.8 minutes as the documented target. Reorgs of unfinalized blocks remain possible inside the two-epoch window, but a finalized block is treated as irreversible by every Ethereum client."
- - q: "How is TON able to finalize so fast?"
- a: "TON's BAG consensus pushes masterchain finality under one second by separating state across a masterchain and many workchains. The number reported here is the masterchain commit, which is the canonical reference for cross-chain settlement. Workchain blocks are also finalized but only after the masterchain commit references them."
+ - q: "How is Gram (formerly TON) able to finalize so fast?"
+ a: "Gram's BAG consensus pushes masterchain finality under one second by separating state across a masterchain and many workchains. The number reported here is the masterchain commit, which is the canonical reference for cross-chain settlement. Workchain blocks are also finalized but only after the masterchain commit references them."
  - q: "Can I trust a sub-second L1 finality for cross-chain settlement?"
  a: "It depends on what you are settling. For bridges and exchanges with their own deeper confirmation thresholds, sub-second native finality means you reach those internal thresholds faster, not that you can skip them. For protocols that consume finality directly (e.g. LayerZero finality oracle, IBC client), the native value is what matters and the sub-second chains genuinely settle in under a second."
 

@@ -20,7 +20,7 @@ This works for: **Ethereum, Solana, TRON, Stellar, Hedera, SUI, Litecoin, Monero
 
 For chains where finality is faster than our poll interval, comparing two pointers at one instant doesn't measure finalization time - it measures the gap-at-instant, which collapses to zero when finalization catches up to head. The honest path is to subscribe to a push stream, record `T1 = time.Now()` when block N is first observed, and `T2 = time.Now()` when N becomes finalized. `lag = T2 − T1`, with millisecond precision, independent of chain timestamp resolution.
 
-This works for: **BNB, Avalanche, TON**.
+This works for: **BNB, Avalanche, Gram**.
 
 ## Per-chain methodology
 
@@ -34,7 +34,7 @@ This works for: **BNB, Avalanche, TON**.
 | **Stellar** | HTTP poll | Horizon `/ledgers?order=desc&limit=2` | 1 ledger back (SCP-final) | Circle = 1, deterministic SCP |
 | **Hedera** | HTTP poll | Mirror `/api/v1/blocks?order=desc&limit=2` | 1 block back. Timestamps parsed at ns precision | Hashgraph aBFT deterministic |
 | **SUI** | HTTP poll | `sui_getLatestCheckpointSequenceNumber` + `sui_getCheckpoint` | 1 checkpoint back | Circle USDC = 1, Mysticeti finalizes in 1 |
-| **TON** | SSE wall-clock | `tonapi.io/v2/sse/blocks?workchain=-1` (masterchain only) | Time between consecutive masterchain blocks | TON docs: a tx is final once included in a masterchain block, so block_N is final when block_N+1 commits |
+| **Gram** | SSE wall-clock | `tonapi.io/v2/sse/blocks?workchain=-1` (masterchain only) | Time between consecutive masterchain blocks | Gram (formerly TON) docs: a tx is final once included in a masterchain block, so block_N is final when block_N+1 commits |
 | **Litecoin** | HTTP poll (probabilistic) | blockchair `/stats.best_block_height` and `/dashboards/block/{height}.block.time` | 12 confirmations | Coinbase deposit standard, post-April-2026 13-block MWEB reorg |
 | **Monero** | HTTP poll (probabilistic) | monero-rpc `get_info` + `get_block_header_by_height` (with cakewallet/sethforprivacy/monerujo failover) | 10 confirmations | Wallet protocol unlock period |
 | **Cardano** | HTTP poll (probabilistic) | koios `/tip` + `/blocks?block_height=eq.<height>` | 15 confirmations | Above Coinbase 10 / Kraken 15. Far below the academic k=2160 (~12 h) |
@@ -56,7 +56,7 @@ This works for: **BNB, Avalanche, TON**.
 | Hedera | High | Hashgraph aBFT + ns-precision timestamps |
 | SUI | High | 1 checkpoint = Circle USDC standard |
 | Stellar | High | SCP deterministic, Circle = 1 |
-| TON | High (after SSE refactor) | tonapi `workchain=-1` SSE stream, ms-precise |
+| Gram | High (after SSE refactor) | tonapi `workchain=-1` SSE stream, ms-precise |
 | Cardano | Medium | 15-conf compromise between Coinbase 10 and Kraken 15. Academic k=2160 is theoretical; no actor uses it |
 | Litecoin | Medium | 12-conf post-April-2026 reorg; standard is evolving |
 | TRON | Medium | CEX confirmation counts vary 19 to 30; we use the 19-block protocol minimum |
@@ -66,7 +66,7 @@ This works for: **BNB, Avalanche, TON**.
 
 Rather than copy the docs (which are optimistic targets), we anchored each chain's depth to what production actors (Coinbase, Circle, Kraken, Binance, Fireblocks) actually require before crediting a deposit or treating a transfer as irreversible. That's the practical-settlement standard people put real money behind, and it's the closest thing to a ground truth for "real-world finality."
 
-For chains where no canonical CEX number exists (TON, Monero), we fall back to protocol-level minimums plus a small safety margin and flag them as "Lower" / inferred in the audit.
+For chains where no canonical CEX number exists (Gram, Monero), we fall back to protocol-level minimums plus a small safety margin and flag them as "Lower" / inferred in the audit.
 
 ## Metrics emitted
 
@@ -81,7 +81,7 @@ l1_finality_last_refresh_timestamp_seconds{chain}
 l1_finality_fetch_errors_total{chain, error_type}
 l1_finality_health{chain} # 1 if last sample succeeded
 
-# Wall-clock-measured chains (BNB, Avalanche, TON)
+# Wall-clock-measured chains (BNB, Avalanche, Gram)
 l1_finality_wallclock_lag_milliseconds{chain} # ms-precise gauge
 l1_finality_wallclock_lag_milliseconds_histogram # histogram for tail latency
 l1_finality_wallclock_health{chain} # 1 if WS/SSE connected