Tag: blockchain

Every blockchain data provider claims their product is verifiable. The problem is that few of them mean the same thing, and that gap has become a critical issue as more capital moves through automated systems and smart contracts that rely on accurate onchain data.

The simplest approach to data extraction involves a team pulling data directly from blockchain nodes via JSON-RPC, extracting blocks, transactions, and logs, then loading them into a custom pipeline. With some human curation—people checking numbers and catching anomalies—this setup works well for small to medium projects. However, it does not scale effectively. When a provider using this pipeline calls its data verifiable, it typically means the numbers can be spot-checked against another source and the methodology is open to manual audit. This is a real capability, but it is far from cryptographic proof and still requires trusting that someone extracted and curated the data honestly.

That trust gap has shifted from a nuisance to a liability. Most applications accept whatever an RPC endpoint returns at face value, meaning compromised infrastructure can feed convincing but incorrect data into downstream systems. This is not hypothetical. In April 2026, attackers manipulated the RPC infrastructure behind a verification layer tied to KelpDAO, contributing to a loss estimated at around $290 million. No blockchain cryptography was broken. Instead, the trust chain was exploited. As more capital flows through agents and treasuries that execute automatically, bad data becomes a security issue rather than a quality issue.

Teams requiring stronger verification typically choose among three approaches, and only one fully earns the descriptor without an asterisk.

1-of-N Trust Model

The first is a 1-of-N trust model. Instead of relying on a single provider, work is distributed across many independent participants. Correctness becomes contestable: it takes just one honest party to catch bad data and hold the offender accountable. The Graph’s decentralized network uses this model, where Indexers submit Proofs of Indexing, and other participants can challenge results they believe are incorrect. Disputes go to arbitration, and an Indexer caught serving bad data is slashed. The math is compelling. With five participants, each having a 20% chance of using a faulty RPC, a consensus model requiring majority agreement has about a 5.8% chance that the majority is wrong and bad data wins. Under a 1-of-N model, corruption only slips through if all five participants fail simultaneously, about 0.03% risk, making it nearly two orders of magnitude safer. This gap explains why 1-of-N scales better as networks grow.

However, this model has a flaw. A gateway pulling from multiple Indexers can receive correct data from two sources and bad data from a third. Until the dispute resolves, users may see flickering between correct and incorrect data. Developers often prefer consistently wrong data over visibly inconsistent data, a real tradeoff in permissionless systems that centralized systems typically hide.

Consensus Model

The second approach is consensus, which is often confused with 1-of-N. This distinction matters because the two models make fundamentally different bets. Consensus treats majority agreement as a stand-in for correctness, as Chainlink’s oracle network does. The problem is that a majority can be wrong. If enough participants collude or are compromised, the entire agreement mechanism breaks down.

Verifiable Extraction

The third approach deserves the term without qualification. Verifiable extraction bypasses the question of whom to trust and instead relies on the blockchain’s cryptographic commitments: the hashes linking every block, transaction, and log in a way that cannot be altered without detection. Edge & Node’s Amp recomputes these commitments during data extraction, before the data becomes queryable, checking Keccak-256 hashes and Merkle Patricia Tries against the block header. If anything has been tampered with, the mismatch appears immediately. StreamingFast’s verifiable extraction for Firehose closes the remaining gap by proving that a specific block belongs to the chain’s actual canonical history, not just that the extracted data matches the header it claims. Together, these cover the full claim: the data is faithful to the block, and the block is real, and anyone can recompute both independently.

However, this approach has costs. Recomputing commitments and reconstructing proofs requires computational work, so the most rigorously verified data tends to arrive slower than a raw, unchecked feed. The blockchain data trilemma—fast, comprehensive, verifiable, pick your tradeoffs—does not disappear just because a team has chosen the strongest form of verification. Even cryptographic verification has a boundary: it proves data was processed and preserved correctly, but not that the original source was honest. That is a different problem, the oracle problem, and it remains unsolved.

The real issue is the weight the word is being asked to carry. “Verifiable” is applied to benchmarkable transparency, majority agreement, and cryptographic proof as if they are interchangeable guarantees with different marketing. They are not. They fail in different ways, under different conditions, for different reasons. For anyone building a system where a wrong number costs real money, this distinction is not academic. It is the entire ballgame.