An RPC endpoint is a server that lets you read blockchain data without running a full node. You ask for the latest block height, it tells you. You ask for a transaction receipt, it tells you. You assume it's telling the truth. It usually is. But when money is involved, "usually" is not good enough.
An RPC endpoint can return stale data (an old block as the current block), incomplete data (a transaction not yet mined), or data about to be invalidated by a reorg where the blockchain reverses the last 10 blocks. If you settle based on this information, it becomes invalid 30 seconds later.
The risk per call is small—maybe 0.01% return stale data. But at 10,000 transactions per second, 0.01% error means 1-2 payments per second settled on false information. That's $1M-$10M per day in invalid settlements. Most platforms don't measure this. They assume their RPC is honest and hope reorgs never happen. When reorgs do happen, they discover too late and manually reverse settlements.
Zero-trust RPC validation means not trusting any single RPC endpoint. You verify every response against consensus from multiple providers before settlement.
The Threat Model
Three classes of RPC failures exist.
First, honest failures. Your RPC provider (Alchemy, Infura, QuickNode) has a bug or corrupted database and returns wrong data unintentionally. Alchemy had a 45-minute outage in 2023 where cached data was 20 blocks behind. This is rare but it happens.
Second, network failures. The provider is correct but the network between you and them is compromised. A man-in-the-middle attack, BGP hijack, or DDoS slows the response. You receive the data late, making it stale by the time you read it.
Third, blockchain failures. The blockchain reorgs—the last 10 blocks are replaced due to a network partition or consensus failure. Your RPC was correct when you asked, but that state is no longer valid 2 minutes later.
For payment settlement, all three have the same outcome. You settle based on data that no longer represents the chain's true state. The fix is multi-provider consensus. Instead of trusting one RPC provider, query three independent providers and compare results.
Building Multi-Provider Consensus and Finality
Use majority voting. Query three RPC providers (Alchemy, Infura, QuickNode) for the current block height. Alchemy returns 17,234,567. Infura returns 17,234,567. QuickNode returns 17,234,556. Two out of three agree, so 17,234,567 is the truth.
This triples RPC calls (200ms becomes 600ms), but cache consensus results for 500ms to reduce effective latency to 1.5x. For globally distributed providers (US, EU, Asia), network latency means waiting 300-500ms for all three to respond, but aggressive caching covers this.
Detect staleness by caching consensus block height over the last 10 seconds. If current consensus hasn't advanced, something is wrong—either the providers are stalled or the blockchain stopped producing blocks. Detect reorgs by checking if consensus block height drops below what you've seen. Reject settlements on affected blocks. Apply a simple rule. Don't settle on a block less than 12 blocks behind consensus head (about 3 minutes on Ethereum).
Settlement requires choosing between latency and reorg risk. Twelve confirmations have nearly zero reorg risk but cost 3 minutes. One confirmation is faster but much riskier. Choose based on your tolerance.
Multi-Chain Consensus and Fallback Routing
Many payment platforms operate across multiple blockchains. Ethereum, Polygon, Arbitrum. An RPC outage on Ethereum doesn't mean an outage on Polygon. Support settlement on multiple blockchains with fallback routing. If Ethereum RPC consensus fails (two providers disagree on block height), route the transaction to Polygon instead. The customer still gets settled; it just happens on a different blockchain.
This requires cross-chain settlement support or bridges, but increases success rate significantly. If Ethereum consensus fails, you lose 1% of volume but can retry transactions 30 seconds later on a different chain.
An RPC provider could intentionally lie—returning fake transaction receipts or blocks that don't exist. Detect this by validating against logical inconsistencies such as payment amount mismatches or temporal contradictions like block height going backwards. If you run your own full node, validate against your local state (your node is the source of truth). Without a node, detect internal contradictions and flag them as suspicious.
Anomaly detection sensitivity versus false positives matters. Aggressive flagging (10% of calls suspicious) triggers unnecessary fallbacks and blocks transactions. Conservative flagging (0.01%) might miss real attacks. Choose based on costs. A false positive costs about $1 (transaction retry on another chain). A missed attack costs about $10K (fake settlement). This determines your threshold for anomaly detection aggression.
A resilient settlement system assumes every RPC provider is potentially compromised and validates every response. The complete architecture requires multiple validation layers.
1. Transaction arrives at settlement service.
2. Settlement service calls three independent RPC providers for current block height and transaction status.
3. Consensus calculation determines the truth (majority vote).
4. Temporal check detects if block height has gone backwards (reorg detection).
5. Staleness check ensures block height has advanced in the last 30 seconds.
6. If consensus fails or anomalies detected, route to fallback blockchain or queue for retry.
7. If all checks pass, proceed with settlement on the consensus block height.
8. Log every RPC response and every settlement decision for audit trail.
This process adds latency and RPC costs (3x the API calls). But it removes a class of risk that most platforms ignore until it happens.
The payment platforms that survived the FTX collapse and the various blockchain network attacks were the ones that had built zero-trust RPC validation. They didn't settle on stale data. They didn't trust a single RPC provider. When one provider failed or became unreliable, transactions automatically routed to a fallback.
Platforms that trusted a single RPC endpoint watched settlements fail and had to manually triage which transactions were valid and which ones were based on corrupted data.
Zero-trust RPC validation is not optional at scale. It's the difference between payment infrastructure that works when blockchains are stressed and payment infrastructure that fails when it matters most.