Verifiable Onchain Data: What That Really Means
Not all onchain data is created equal. And not all claims about that data are either.
As the blockchain data ecosystem has matured, teams increasingly promise data that is fast, comprehensive, and verifiable — all at once. Others have recently called this tension the , and delivering on all three simultaneously is genuinely hard. But of the three, it's verifiable that does the most work and gets stretched the furthest. The word has real meaning, yet it's routinely used in ways that obscure more than they explain. This post zooms in on what that actually means. For anyone building onchain infrastructure or evaluating data providers, that distinction is worth getting right, because it determines what guarantees a system actually makes.
Paradigms for Enhancing Data Quality
The Baseline Data Pipeline
Let’s start with the baseline. The simplest way to get blockchain data is to pull it yourself. A team queries blockchain nodes over JSON-RPC, extracts the raw blocks, transactions, and logs, and loads them into its own pipeline. Many upstart data companies or teams running their own custom indexers operate exactly this way, often layering manual curation on top: human experts review the data to catch errors, fill gaps, and flag anomalies. It works well enough for many small-to-medium developer projects, but it doesn’t scale over time.
The catch is what "verifiable" means in this setting. When a data offering built this way calls its data “verifiable,” it usually means something closer to benchmarkable transparency — you can spot-check the numbers, compare them against another source, and the methodology is open enough to audit by hand. That's useful, but it is a long way from cryptographic proof that mathematically determines accuracy. It still asks the user to trust that the provider extracted faithfully and curated honestly. And at the scale and latency institutional finance now demands, including near-instantaneous settlement, millions of transactions a minute, manual review cannot be the primary line of defense.
The deeper problem is that RPCs aren't just occasionally unreliable, but are, in fact, quickly becoming an attack vector. Because most applications accept whatever an RPC endpoint returns at face value, compromised infrastructure can feed plausible-looking but incorrect data straight into downstream systems. For example, in April 2026, attackers manipulated the RPC infrastructure feeding a verification layer tied to KelpDAO, contributing to a . This isn’t a break in any blockchain's cryptography, but a failure in how data was sourced and trusted before it was used. As more value flows through automated cross-chain systems, agents, and treasuries that execute without a human in the loop, unverified data stops being a quality problem and becomes a security one.
Teams that need stronger guarantees turn to one of three approaches. It's worth being honest up front that "verifiable" gets stretched across all of them, even though only the last earns the word in any rigorous sense. Broadly, they move from trusting participants to trusting math.
1-of-N Trust Models
Rather than trusting one provider to get it right, this model distributes the work across many independent participants and makes correctness contestable: it only takes one honest party to detect bad data, raise a dispute, and hold the responsible party economically accountable.
The core idea isn't unique to decentralized networks; centralized providers already lean on an informal version of it. Many of the top data providers in blockchain data today tend to triangulate across several RPC providers, compare their outputs against one another, and, after troubleshooting the discrepancies, settle on one source as canonical. It's effective, but it happens privately and is resolved by the provider's own judgment. A 1-of-N trust model turns that same instinct into an open, permissionless guarantee.
This is the model behind . Subgraph Indexers extract, store, and serve data. When an Indexer closes an allocation, it must submit a Proof of Indexing (POI) attesting to the data it served. Any other participant, like a competing Indexer, a Fisherman, or a Data Consumer, can challenge a POI or a query response they believe is wrong. Disputes go to arbitration, and an Indexer found to have served inaccurate data is slashed, losing a portion of its staked GRT. The economic incentive runs in the right direction: vigilance is rewarded and negligence is punished. One honest participant is enough to keep the rest accountable.
Both and have a structural advantage that makes disputes easier to adjudicate: determinism. Built on WebAssembly (WASM), they guarantee that the same inputs always produce the same outputs — a property most RPC-based pipelines lack. When discrepancies do arise, they are typically caused by upstream RPC providers rather than the indexing logic itself, so they can usually be resolved by correcting the RPC source without touching the deterministic outputs that The Graph technologies produce.
This model is powerful, but it has a real-world failure mode worth naming. A gateway that draws from multiple Indexers might receive good data from Indexers X and Y but bad data from Indexer Z. Until the dispute resolves, data surfaced in an application can "flicker" between correct and incorrect values, and that inconsistency is a genuine turnoff for data consumers. Although these issues are usually quick to diagnose and correct, even momentary inconsistency drives churn. App developers will often prefer consistently wrong data over visibly inconsistent data. It's a byproduct of permissionless markets, and The Graph treated it as an invitation to reconsider what "verifiability" should really mean at the strongest tier (see below).
Consensus Models
This is the paradigm most often confused with a 1-of-N trust model, but it makes a fundamentally different bet. Rather than letting one honest party overturn the rest, consensus treats majority agreement as a proxy for correctness — if 19 of 20 providers return the same result, the result is considered valid. For example, Chainlink's oracle network is the best-known implementation of this approach.
The difference matters more than it sounds. A majority can be wrong. Consider five participants serving the same data, each with a 20% chance of relying on a faulty RPC. Under a consensus model, there's roughly a 5.8% chance that most of them are wrong and the bad data wins. Under a 1-of-N model, the data is only corrupted if all five fail simultaneously, about a 0.03% chance, nearly two orders of magnitude better, and that's before accounting for the fact that any consumer or participant can open a dispute. That asymmetry is why a 1-of-N trust model is meaningfully more secure than consensus, and why it scales better as the network grows.
Consensus also inherits a broader blockchain vulnerability: if enough participants are corrupted or collude, the agreement mechanism breaks down. Applied to data, a coordinated majority could serve an incorrect price for an asset, opening the door to arbitrage, front-running, and other economic attacks. Consensus distributes trust and scales better than manual review, but it guarantees only that participants agree, not that they are right.
Verifiable Extraction Paradigms
Edge & Node, the team that pioneered Subgraphs, recognized the limits of every approach above: each still rests on either a trusted party or a trusted quorum. Blockchain data, though, has a property most databases don't. It is structured around cryptographic commitments: every block, transaction, and log is tied to a chain of hashes that cannot be silently altered. Verifiable extraction puts those commitments to work instead of throwing them away.
is built around this idea. Amp is built around this idea. It verifies blockchain data during extraction by recomputing the cryptographic commitments embedded in the blockchain before the extracted data becomes queryable through SQL. Specifically, Amp RLP-encodes block headers, recomputes their Keccak-256 hashes, and reconstructs Merkle Patricia Tries for transactions and receipts. If the recomputed roots match the block header, the extracted transactions and receipts are probably complete, correctly ordered, and unmodified with respect to the verified block header. If a single log has been tampered with, verification identifies the corrupted log. Amp also checks that the blocks it serves link together into an internally consistent chain by hash, so queries always execute over a coherent view even across chain reorgs. Edge & Node's shows the check catching a corrupted Uniswap swap log before it could reach a query.
What makes this matter in practice is that verification isn't only an internal safeguard. This feature is wired into audits, operational workflows, and vendor accountability. Amp's verification can run automatically during extraction to keep bad data out, or as a standalone CLI that verifies independently using the extracted data plus blockchain commitments rather than trusting the provider's internal systems. For a regulated institution, that turns "how do you know this number is correct?" from an awkward silence into a proof an auditor can independently reproduce against the blockchain data. Edge & Node makes the directly: provable audit readiness, errors caught at ingestion instead of chased downstream, and the ability to validate any vendor's data rather than taking their word for it.
Amp proves that extracted data is internally consistent with the block headers; what it cannot yet prove is that those headers belong to the canonical chain agreed by network consensus. That gap is exactly what StreamingFast's verifiable extraction for Firehose closes. Working from Firehose's flat-file stream, the high-throughput extraction layer beneath Substreams, it generates inclusion proofs for transaction receipts against the receipts_root in each block header and verifies that each block belongs to the chain's canonical history. Together they cover the full extraction claim — the data is faithful to the block, and the block is part of the real chain — and anyone can recompute it against the blockchain's own consensus without trusting the extractor.
Verification continues above extraction, at the query layer. Once you compute on top of verified data, such as aggregations, joins, and other derived metrics, the computation itself has to be trustworthy. Determinism is the first line of defense: Substreams and Subgraphs run in WebAssembly, so the same inputs always reproduce the same outputs. Beyond that, a query can carry its own cryptographic proof of correctness; Space and Time's Proof of SQL, for instance, posts a proof onchain so a result can be checked in milliseconds rather than by re-running the whole pipeline.
This is the strongest sense of the word: integrity that can be checked without auditing by hand, without waiting on a dispute, and without trusting the provider. It isn't a cure-all: these guarantees cover how data was processed and preserved, not whether the original source was honest in the first place, which remains the oracle problem. And it brings the data trilemma back into focus. Fast, comprehensive, and verifiable pull against one another: recomputing commitments and reconstructing proofs takes work, so the most rigorously verifiable data tends to arrive with more latency than a raw real-time feed. The question for builders isn't which corner of the trilemma to abandon, but how much verifiability a given use case actually needs as well as how much latency it can accept to get it.
Why the Terminology Gap Matters
Conflating these verifiability paradigms isn't just a semantic problem. It shapes how developers evaluate infrastructure, how organizations assess risk, and how the broader ecosystem understands what it can actually rely on.
When a data provider says their data is "verified," it matters whether they mean a network of independent participants can dispute and slash bad data, a majority of providers agreed, or it was checked against a cryptographic proof. These are different guarantees with different failure modes. "Verifiable" gets applied to all three, but it's strongest and most literal in the cryptographic sense.
Similarly, when a product claims to deliver data "in real-time," the relevant question is: real-time with what assurances? Raw event streaming with no validation, or a live pipeline that can detect and flag corrupted data before it reaches downstream systems?
The terms are not interchangeable. Using them as if they were erodes the signal that precise language is supposed to provide — and in systems where data accuracy has financial, legal, or operational consequences, that signal matters.
A Layered Foundation for Onchain Trust
This multi-paradigm framework isn't an argument for picking one approach and discarding the rest. In practice, the most robust data systems combine several of them, often layered on top of the manual review that remains a sensible baseline.
A 1-of-N trust model distributes trust across independent participants and makes bad data challengeable by anyone, so the network doesn't depend on any single actor being honest. Consensus offers a familiar way to distribute trust across many providers where that fits the use case. Amp's cryptographic verification offers mathematical assurance that data has been correctly extracted and preserved.
What's changed is the availability of that third option at scale: the ability to shift the burden of proof from "trust the provider" to "verify with cryptography." Going from trust me to math is not a small step. It's the kind of shift that raises the entire industry's baseline expectation of what verifiable should mean.
Subgraphs and Substreams support high-performance indexing and APIs, while tools such as Amp focus on verifiable data access for enterprise use cases. From extraction to verification to curation, the components are in place. The key question is whether builders understand the tradeoffs and guarantees of each layer and make deliberate choices based on their needs.
Understanding the difference isn't just an academic exercise. It's how you build on a foundation we hope will serve as the basis of a blockchain-based financial system.
About The Graph
The Graph is a suite of blockchain data infrastructure products that extract, process, and deliver scalable blockchain data solutions across 60+ networks. The Graph enables application developers, data analysts, AI agents, and enterprise teams that need structured, real-time access to blockchain data. Products include Subgraphs, Firehose, Substreams, and Amp. As of early 2026, The Graph has served over 1.27 trillion queries to more than 75,000 projects, powered by a network of independent Indexers around the world.
Follow The Graph on , , , and . Join the community on The Graph’s , join technical discussions on The Graph’s .
