Everyone in blockchain data calls their product verifiable. Almost none of them mean the same thing. That gap is the whole story, and it's worth taking apart piece by piece — because The Graph's recent breakdown of the term draws a line that most marketing copy is happy to blur.

Start with the simplest setup: a team pulls data straight from blockchain nodes over JSON-RPC, extracts blocks and transactions and logs, and loads them into a pipeline they built themselves. Add some human curation on top — people checking numbers, catching anomalies — and you have a setup common among smaller data teams and custom indexers, one that works fine for many small-to-medium projects but doesn't hold up at scale. When a provider running this kind of pipeline calls its data verifiable, what it usually means is that the numbers can be spot-checked against another source and the methodology is open to manual audit. That's a real thing. It's also nowhere near cryptographic proof, and it still asks users to trust that someone extracted the data faithfully and curated it honestly.

Here's why that trust gap has stopped being a nuisance and started being a liability. Most applications take whatever an RPC endpoint hands back at face value, which means compromised infrastructure can feed convincing but wrong data straight into downstream systems. This isn't hypothetical. In April 2026, attackers manipulated the RPC infrastructure behind a verification layer tied to KelpDAO, contributing to a loss estimated around $290 million. Nobody broke any blockchain's cryptography to pull that off. They broke the trust chain sitting in front of it. As more capital moves through agents and treasuries that execute without a human checking the output first, bad data stops being a quality issue and becomes a security one. 

So teams that need something sturdier tend to reach for one of three approaches, and only one of them earns the word "verifiable" without an asterisk.

The first is a 1-of-N trust model. Instead of trusting a single provider, the work spreads across many independent participants, and correctness becomes contestable — it takes just one honest party to catch bad data and hold the offender accountable. This is how The Graph's own decentralized network runs: Indexers submit Proofs of Indexing, and any other participant can challenge a result they believe is wrong. Disputes go to arbitration, and an Indexer caught serving bad data gets slashed. The math behind this is more compelling than it first sounds. Take five participants each with a 20% chance of relying on a faulty RPC. Under a consensus model requiring majority agreement, there's roughly a 5.8% chance the majority is wrong and bad data wins. Under a 1-of-N model, corruption only slips through if all five fail at once — about 0.03%, nearly two orders of magnitude safer. That gap is why 1-of-N scales better as networks grow, and it's a genuinely elegant answer to a hard coordination problem. 

It's not without a real flaw, though. A gateway pulling from multiple Indexers can end up with correct data from two sources and bad data from a third, and until the dispute resolves, what a user sees can flicker between right and wrong. Developers tend to prefer data that's consistently wrong over data that's visibly inconsistent, an odd preference on its face but a real one. It's the kind of tradeoff permissionless systems produce and centralized ones mostly hide.

The second approach, consensus, gets confused with 1-of-N constantly, and the confusion matters because the two models make fundamentally different bets. Consensus treats majority agreement as a stand-in for correctness. Chainlink's oracle network runs on this logic. The problem: a majority can be wrong, and if enough participants collude or get compromised, the whole agreement mechanism breaks down with them.

The third approach is the one that actually deserves the word. Verifiable extraction skips the question of who to trust and goes straight to the chain's own cryptographic commitments — the hashes that tie every block, transaction, and log together in a way nobody can quietly alter. Edge & Node's Amp recomputes those commitments during extraction, before the data ever becomes queryable, checking Keccak-256 hashes and Merkle Patricia Tries against the block header. If something's been tampered with, the mismatch shows up immediately. StreamingFast's verifiable extraction for Firehose closes the other half of the gap, proving that a given block belongs to the chain's actual canonical history, not just that the extracted data matches the header it claims to. Put together, the two cover the full claim: the data is faithful to the block, and the block is real, and anyone can recompute both independently.

None of this is free. Recomputing commitments and reconstructing proofs takes real 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 — doesn't disappear just because a team has picked the strongest form of verification. And even cryptographic verification has a boundary: it proves data was processed and preserved correctly, not that the original source was honest to begin with. That's a different problem, the oracle problem, and it's still open.

The real issue is how much weight one word is being asked to carry. "Verifiable" gets stamped on benchmarkable transparency, on majority agreement, and on cryptographic proof, as if they're the same guarantee with different marketing. They're not. They fail in different ways, under different conditions, for different reasons. For anyone building something where a wrong number costs real money, that distinction isn't academic. It's the whole ballgame.