> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blockheight.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Why BlockHeight
> BlockHeight is the community-driven observability protocol helping developers power faster, smarter, more reliable web3 apps.
## Overview
At BlockHeight, we continuously track the performance and reliability of RPC node providers across major networks, surfacing real-time insights into block propagation and consensus lag. Developers use BlockHeight to identify which endpoints are ahead, in-sync, or falling behind—enabling intelligent routing, faster state access, and more resilient web3 infrastructure. In a world of distributed nodes, we create consensus about consensus.
## Core Problem
In blockchain networks, consensus is achieved at the protocol level through validators or sequencers that order and write transactions to the ledger. However, due to the distributed nature of the nodes, the actual RPC nodes developers rely on don't always update with the latest block height simultaneously.
This creates a critical reliability challenge: how do developers know which RPC providers are truly at the current block height? How can they ensure their applications are reading the most current state and writing transactions based on up-to-date information?
Even a slight delay of a few blocks can result in:
* Failed transactions
* Missed financialopportunities
This problem becomes exponentially more complex in load-balanced environments where traffic is distributed across multiple providers and endpoints.
## BlockHeight's Solution
BlockHeight creates a real-time "consensus about consensus" - continuously monitoring the block height reported by all major RPC providers to determine:
1. The current network consensus height
2. Which providers are ahead of consensus (seeing blocks first)
3. Which providers are at consensus (reliable current state)
4. Which providers are behind consensus (potentially stale data)
Through this intelligence layer, BlockHeight enables developers to make informed, real-time decisions about where to route their blockchain traffic for optimal application performance.
## How It Works: Real-World Example
Consider a scenario where a developer needs to submit a time-sensitive transaction based on the most current blockchain state:
```
Provider_A: Block 29,000,001
Provider_B: Block 29,000,000
Provider_C: Block 29,000,000
Provider_D: Block 29,000,000
Provider_F: Block 28,999,997
```
BlockHeight's service would analyze this data and determine:
* **Network Consensus: Block 29,000,000** (majority agreement)
* **Provider\_A: AHEAD** (seeing new blocks faster than others)
* **Providers B, C, D: AT** (reliable current state)
* **Provider\_F: BEHIND** (3 blocks behind, potentially stale)
```mermaid [expandable] theme={null}
graph TB
%% Providers
PA["Provider_A
Block 29,000,001
(AHEAD)
blocks_behind: -1"]
PB["Provider_B
Block 29,000,000
(AT)
blocks_behind: 0"]
PC["Provider_C
Block 29,000,000
(AT)
blocks_behind: 0"]
PD["Provider_D
Block 29,000,000
(AT)
blocks_behind: 0"]
PF["Provider_F
Block 28,999,997
(BEHIND)
blocks_behind: 3"]
%% Analysis Node
process["BlockHeight"]
%% Results
consensus["Network Consensus:
Block 29,000,000"]
ahead["Providers Ahead:
Provider_A (+1)
blocks_behind: -1"]
current["Providers At Consensus:
Providers B, C, D
blocks_behind: 0"]
behind["Providers Behind:
Provider_F (-3)
blocks_behind: 1"]
%% Connections
PA --> process
PB --> process
PC --> process
PD --> process
PF --> process
process --> consensus
process --> ahead
process --> current
process --> behind
%% Styling with the provided hex colors
style PA fill:#00E383,stroke:#333
style PB fill:#F9BE08,stroke:#333
style PC fill:#F9BE08,stroke:#333
style PD fill:#F9BE08,stroke:#333
style PF fill:#FF4041,stroke:#333
style consensus fill:#6298FF,stroke:#333
style ahead fill:#00E383,stroke:#333
style current fill:#F9BE08,stroke:#333
style behind fill:#FF4041,stroke:#333
```
```filename theme={null}
https://api.internal.blockheight.xyz/providers?api_key=bh_e5849b6f-d3fc-4c3f-92a7-9f5a825a71a9
```
```filename theme={null}
{
"id": "base-official",
"name": "Base-Official",
"networks": [
{
"network": "base",
"chain_id": "8453",
"blockheight": {
"blockheight_status": "at",
"blocks_behind": 0,
"last_checked": "2025-05-07 01:24:02",
"seconds_ago": 145357,
"reported_blockheight": "29895847"
},
"events": {
"active": {
"total": 0,
"by_type": {
"height_stagnation": 0,
"provider_error": 0,
"high_latency": 0
}
},
"recent": {
"last_5min": 0,
"last_hour": 0
}
}
}
]
}
```
## Strategic Routing Decisions
With this intelligence, developers can implement nuanced RPC routing strategies:
| Use Case | Optimal Provider Selection | Why |
| ----------------------- | ---------------------------------- | --------------------------------------------------------------- |
| High-frequency trading | Provider\_A | Access to the newest blocks first creates competitive advantage |
| Regular transactions | Providers B, C, or D | At consensus, ensuring reliable current state |
| Application reads | Providers B, C, or D | Consistent data at consensus height |
| Historical data queries | Any provider (including F) | Historical blocks are immutable and available on all nodes |
| High-volume operations | Load balance across A, B, C, and D | Distribute traffic among reliable nodes |