Block Time-based indexing, used by The Graph's Subgraphs, excels at delivering data with ultra-low latency by indexing new blocks as soon as they are proposed. For example, on a chain like Polygon with a ~2-second block time, a subgraph can surface transaction data to an application's UI in under 5 seconds. This is critical for high-frequency dApps like DEX aggregators (e.g., 1inch) or real-time dashboards that need to reflect the latest state immediately, even if that state has a small chance of being reorganized.
LABS
Comparisons
Subgraph Indexing Speed: Block Time vs Confirmation Time
A technical analysis for CTOs and architects on the critical trade-off between indexing at block time for speed versus waiting for confirmations for data integrity. Covers The Graph, Substreams, and custom indexers.
Chainscore © 2026
introduction
THE ANALYSIS
Introduction: The Finality-Speed Dilemma in Indexing
Choosing an indexing strategy forces a fundamental choice between near-instant data availability and cryptographically secure finality.
Confirmation Time-based indexing, employed by solutions like Chainlink Data Streams or Pyth, takes a different approach by waiting for a predefined number of block confirmations. This strategy prioritizes data finality, ensuring the indexed information is virtually irreversible. The trade-off is inherent latency; waiting for 15 confirmations on Ethereum (~3 minutes) or 32 confirmations on Solana (~13 seconds) means your application receives provably final data, but not the absolute latest.
The key trade-off: If your priority is user experience and speed for front-end applications, choose Block Time indexing. If you prioritize security and settlement finality for back-end logic, smart contract execution, or oracle feeds, choose Confirmation Time indexing. The former is ideal for Uniswap's UI; the latter is non-negotiable for Aave's liquidation engines.
tldr-summary
Subgraph Indexing Speed: Block Time vs Confirmation Time
TL;DR: Core Trade-Offs at a Glance
The fundamental latency choice for indexing. Block time offers raw speed, while confirmation time prioritizes finality.
01
Block Time Indexing (e.g., The Graph, Substreams)
Indexes on every new block: Subgraphs start processing as soon as a block is proposed. This enables sub-second latency for data like NFT mints on Polygon or token swaps on Arbitrum. Essential for real-time dashboards and high-frequency dApps.
< 2 sec
Typical Latency
Real-time
Data Freshness
02
Risk: Chain Reorganizations
Primary weakness: Data can be invalidated if the chain reorgs. This requires logic to handle orphaned blocks and can lead to temporary data inconsistency. A critical consideration for financial settlement or audit logs.
03
Confirmation Time Indexing (e.g., Goldsky, Custom Solutions)
Waits for finality: Indexing begins only after a block has enough confirmations (e.g., 15 blocks on Ethereum, 32 on Solana). This guarantees data finality and eliminates reorg risk. Non-negotiable for bridging protocols like LayerZero or perpetual DEXs like dYdX.
~1-5 min
Added Latency (Ethereum)
Irreversible
Data Guarantee
04
Trade-off: User Experience Latency
Slower front-end updates: Users see pending states longer. This can be mitigated with optimistic UIs or hybrid approaches (e.g., using EVM's finalized tag). Less ideal for social or gaming dApps where immediate feedback is key.
INDEXING LATENCY COMPARISON
Head-to-Head: Indexing at Block Time vs Confirmation Time
Direct comparison of indexing performance, data freshness, and infrastructure trade-offs.
| Metric | Indexing at Block Time | Indexing at Confirmation Time |
|---|---|---|
Data Freshness | < 2 seconds | ~12 seconds (Solana) to ~15 minutes (Ethereum) |
Indexing Latency | Near real-time | Network-dependent finality delay |
Reorg Risk | High (requires rollback logic) | Low (data is finalized) |
Use Case Fit | High-frequency trading, live dashboards | Settlements, analytics, historical queries |
Infrastructure Complexity | High (stream processing, state management) | Lower (batch processing) |
Example Protocols | The Graph Firehose, Subsquid | The Graph (standard), Goldsky |
pros-cons-a
Subgraph Indexing Speed
Pros and Cons: Indexing at Block Time
Choosing between indexing at block time vs. confirmation time is a fundamental architectural decision. This table highlights the key trade-offs for protocol performance and data integrity.
01
Block Time Indexing (e.g., The Graph, Substreams)
Immediate Data Availability: Indexers process transactions as soon as they appear in a new block, before network consensus finalizes them. This enables sub-second latency for dApps like high-frequency DEX aggregators (1inch) or real-time NFT marketplaces (Blur).
< 1 sec
Typical Latency
0
Confirmation Wait
02
Block Time Indexing: The Risk
Exposure to Chain Reorgs: Indexed data is provisional. A chain reorganization can invalidate previously indexed blocks, causing data rollbacks. This is critical for final-state applications like debt settlements in lending protocols (Aave, Compound) or calculating accurate TVL.
03
Confirmation Time Indexing (e.g., Goldsky, Custom RPC)
Guaranteed Finality: Indexers wait for a set number of block confirmations (e.g., 15 on Ethereum, 32 on Solana). This eliminates reorg risk, providing cryptographically final data. Essential for audit trails, financial reporting, and bridging protocols (LayerZero, Wormhole).
99.9%
Data Finality
04
Confirmation Time Indexing: The Cost
Inherent Latency Penalty: Waiting for confirmations adds unavoidable delay—~3 minutes on Ethereum, ~13 seconds on Solana. This is prohibitive for real-time applications like gaming, live dashboards, or arbitrage bots that require the earliest possible signal.
pros-cons-b
Subgraph Indexing Speed: Block Time vs Confirmation Time
Pros and Cons: Indexing at Confirmation Time
Key strengths and trade-offs at a glance for two fundamental indexing paradigms.
01
Block Time Indexing (e.g., The Graph)
Indexes data as soon as a block is proposed. This provides the fastest possible data availability for protocols like Uniswap or Aave that need near real-time price feeds and state updates for front-ends. The trade-off is handling chain reorganizations (reorgs).
< 2 sec
Data Latency
High
Reorg Risk
02
Confirmation Time Indexing (e.g., Goldsky, Substreams)
Waits for a configurable number of block confirmations (e.g., 12 on Ethereum). This eliminates reorg handling complexity, providing deterministic, final data. This is critical for analytics dashboards, accounting systems, and any application where data integrity is more important than sub-second latency.
~2 min
Data Latency (Eth)
Zero
Reorg Risk
03
Pro: Speed for User Experience
Block time indexing is superior for interactive dApps. A DEX aggregator like 1inch needs the latest pool states to calculate optimal swaps. Waiting for confirmations would result in stale quotes and failed transactions, directly impacting user retention and protocol revenue.
04
Con: Handling Chain Reorganizations
Block time indexing must manage reorgs, adding engineering overhead. Your subgraph logic must be idempotent and handle data rollbacks. On high-throughput chains like Polygon or Arbitrum, deep reorgs can temporarily corrupt an unprepared indexer's dataset, requiring manual intervention.
05
Pro: Data Integrity & Simplicity
Confirmation time indexing guarantees finality, simplifying downstream logic. An NFT marketplace like OpenSea building a royalty reporting system can rely on this data being immutable. It removes entire classes of bugs related to state reversal, making ETL pipelines and data lakes far more reliable.
06
Con: Latency for Real-Time Features
The confirmation delay is a non-starter for latency-sensitive features. A lending protocol's liquidation engine or a perpetual DEX's funding rate mechanism cannot wait minutes for data. This forces a hybrid architecture, adding complexity where real-time and finalized data must be reconciled.
CHOOSE YOUR PRIORITY
Decision Framework: Block Time vs. Confirmation Time for Subgraph Indexing
Indexing on Block Time
Verdict: The default for maximum speed. Strengths: Subgraphs (The Graph, Goldsky) begin processing transactions as soon as they appear in a block, minimizing indexing latency. This is critical for applications like high-frequency DEX aggregators (1inch, Uniswap) or real-time dashboards that need sub-second data updates. Trade-off: You risk indexing orphaned blocks during chain reorganizations, requiring logic to handle data rollbacks.
Indexing on Confirmation Time
Verdict: Sacrifices speed for absolute data integrity. Strengths: Waits for a set number of block confirmations (e.g., 15 on Ethereum) before indexing. This is non-negotiable for applications where finality is paramount, such as cross-chain bridge security modules (LayerZero, Wormhole) or on-chain settlement reporting. It eliminates reorg-related data inconsistencies. Trade-off: Introduces a significant delay (e.g., ~3 minutes on Ethereum). Not suitable for live features.
SUBGRAPH INDEXING SPEED
Technical Deep Dive: Implementation & Reorg Handling
A subgraph's performance is dictated by its indexing speed, which is fundamentally tied to the underlying blockchain's block production and finality. This section compares how different consensus mechanisms and reorg handling strategies impact data availability for dApps.
Yes, The Graph can index data significantly faster on Solana due to its lower block time. Solana's ~400ms block time allows subgraphs to ingest and process blocks more frequently than Ethereum's ~12-second block time. This results in near real-time data updates for Solana dApps. However, this speed advantage is contingent on Solana's network stability and the subgraph's ability to handle its high transaction volume. On Ethereum, indexing is slower but more predictable, with data finality guaranteed after probabilistic confirmation periods.
verdict
THE ANALYSIS
Verdict: Strategic Recommendations for Engineering Leaders
Choosing between block time and confirmation time for subgraph indexing is a fundamental architectural decision impacting data freshness, reliability, and development velocity.
Block Time Indexing excels at delivering near real-time data with minimal latency. By processing data as soon as it's included in a new block, this approach provides the fastest possible read state for dApps like high-frequency DEX aggregators or NFT minting dashboards. For example, on a chain like Solana with ~400ms block times, a subgraph can surface transaction data in under a second, enabling ultra-responsive user interfaces.
Confirmation Time Indexing takes a different approach by waiting for a configurable number of block confirmations before processing. This strategy prioritizes data finality and security over speed, making it ideal for applications where accuracy is non-negotiable. This results in a trade-off: you accept higher latency (e.g., waiting for 15+ confirmations on Ethereum, adding ~3 minutes) to virtually eliminate the risk of handling orphaned or reorganized blocks, which is critical for protocols like lending markets or cross-chain bridges.
The key trade-off: If your priority is user experience and speed for front-end applications, choose Block Time Indexing. This is best for dashboards, explorers, and trading interfaces where sub-second updates are a competitive advantage. If you prioritize data integrity and back-end settlement logic, choose Confirmation Time Indexing. This is non-negotiable for DeFi protocols handling large-value transactions, audit systems, or any process where a chain reorg could cause financial loss or state corruption.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall