Bitcoin RPC Reliability at Scale

The standard getblock or getrawtransaction call blocks the entire RPC thread until the data is fetched from disk. Under load, this creates a queue, causing timeouts and cascading failures for all connected clients.

• Latency Spikes: P95 latency can jump from ~100ms to 10s+ under concurrent load.
• No Concurrency: A single slow query for a deep block can stall all other requests.

The UTXO set, now exceeding ~100GB, must be fully scanned for many operations. Indexes are rudimentary, forcing full-table scans for complex queries like filtering transactions by address.

• Resource Exhaustion: A single scantxoutset or address history query can consume >32GB RAM.
• Disk I/O Saturation: Continuous full-node syncs and rescan operations saturate disk bandwidth, degrading performance for all other services.

Applications misuse the Bitcoin P2P protocol as a real-time data feed, overwhelming node bandwidth and connection limits. Broadcasting transactions or polling for confirmations via getblockchaininfo creates unsustainable overhead.

• Connection Storm: A single app can require 50+ persistent connections, hitting default node limits (~125 max).
• Bandwidth Tax: Serving raw blocks to thousands of clients via P2P can require >1 Gbps sustained throughput.

Treats Bitcoin RPC as a distributed system problem. Replaces a single node with a managed, intelligent network.\n- Global Anycast Routing: Routes requests to the nearest healthy endpoint, cutting latency from seconds to ~200-500ms.\n- Automated Failover: Detects stale or forked nodes instantly, ensuring >99.9% historical data reliability.\n- Unified API: Presents a single endpoint, abstracting the complexity of managing a node cluster.

Builds a marketplace for Bitcoin node access, distributing load across many independent operators. This is the 'infrastructure as a service' model.\n- Geographic Distribution: Nodes hosted globally, reducing latency for dApps like Lightning Network wallets.\n- Redundancy by Design: No single operator failure can take down the service, mitigating chain reorg risk.\n- Economic Incentives: Operators are paid for reliable uptime, aligning interests with developers on Liquid Network and beyond.

Acknowledges that vanilla Bitcoin RPC is insufficient for complex state queries. Builds a dedicated indexing layer on top.\n- State Pre-Computation: Indexes Ordinals, BRC-20s, and sBTC events off-chain, delivering queries in <100ms.\n- Reduced Node Load: Offloads heavy historical scans from the core RPC node, improving stability for all users.\n- Programmable Filters: Allows developers to subscribe to specific transaction patterns, enabling real-time apps.

Bypasses the public mempool and standard RPC for the most authoritative, low-latency data source: mining pools themselves.\n- Sub-Second Block Propagation: Receives blocks and transactions directly from hashing power, crucial for high-frequency trading bots.\n- Mempool Sovereignty: Accesses the private mempool view of major pools, seeing transactions before public broadcast.\n- Eliminates Middlemen: Reduces hops between node layers, minimizing propagation delay and frontrunning risk.

Vanilla Bitcoin Core RPC is a single-threaded, blocking API. A getblock call during IBD halts all other queries. At scale, this creates cascading failures for wallets, indexers, and DeFi protocols.

• Blocks are ~4MB, taking ~100ms+ to serialize/deserialize.
• A single slow call can spike p95 latency from 50ms to 10s+.
• This fragility breaks assumptions for high-frequency services like Lightning Network or sovryn.

Decouple request processing from chain synchronization. Use a dedicated indexing layer (e.g., electrs, nigiri) that serves queries from a optimized database, not the live node.

• Enables concurrent query handling and sub-50ms p95 latency.
• Provides historical state lookups (e.g., for Mercury Layer or bitvm) without syncing.
• Critical for rollup sequencers (e.g., Citrea, Botanix) needing reliable block submission.

Checking balance or unspents for a wallet with thousands of addresses requires scanning the entire UTXO set via scantxoutset. This is a linear-time operation that becomes prohibitive for institutional-scale custody or exchanges.

• A query for 10k addresses can take 30+ seconds on a live node.
• Makes real-time portfolio tracking and audit trails impossible.
• A major pain point for crypto banks and asset managers.

Pre-compute and index the mapping from addresses to UTXOs. Expose this via a GraphQL or REST API that allows complex, multi-address queries in constant time.

• Enables instant balance checks for wallets with millions of addresses.
• Allows for advanced querying (e.g., "UTXOs created after block X") essential for compliance and analytics.
• Services like Blockstream Esplora and mempool.space implement this pattern.

The Bitcoin mempool is a global, unordered set. RPC methods like getrawmempool return terabytes of data. Fee estimation (estimatesmartfee) fails during volatility, causing failed txs and poor UX for payment processors and NFT marketplaces.

• Fee spikes cause 90%+ transaction failure rates during congestion.
• No native way to track a specific transaction's propagation status.
• Makes building reliable Layer 2 commitment or time-sensitive swaps a gamble.

Segment the mempool by fee tier and expose a WebSocket stream of transactions. Pair this with a robust fee estimation algorithm that uses historical congestion models, not just current data.

• Provides real-time tx lifecycle tracking (seen, propagated, confirmed).
• Enables CPFP and RBF strategies for protocols like Lightning and swap services.
• Mempool.space API and Blocknative offer commercial versions of this.