What 'Verifiable' Onchain Data Actually Means, According to The Graph

The Graph breaks down three onchain data verification models after a $292M RPC-poisoning attack on KelpDAO's bridge verifier in April.

·Bohdan Oboishev·
What 'Verifiable' Onchain Data Actually Means, According to The Graph

Blockchain data providers all market their feeds as "verifiable," but according to The Graph the word hides three fundamentally different guarantees: 1-of-N trust, majority consensus, and cryptographic verification. The gap between them stopped being theoretical in April, when attackers poisoned the RPC infrastructure feeding KelpDAO's bridge verifier and extracted $292 million without ever touching a smart contract.

Key takeaways

  • Attackers stole $292 million from KelpDAO's bridge in April by poisoning RPC infrastructure, not by exploiting a smart contract bug.
  • Chainlink's consensus model, with five data providers each carrying a 20% failure rate, gives roughly 5.8% odds that bad data wins a majority vote versus just 0.03% odds that all five fail simultaneously.
  • The Graph's own network runs on 1-of-N trust, where a single honest participant can dispute bad data and get the offender slashed.
  • The Graph's Amp system recomputes a chain's own hashes and Merkle roots during extraction, catching a single tampered log before it becomes queryable.
  • Even the strongest verification tier only proves data was extracted and preserved faithfully — it cannot prove the original source was honest, and it costs latency.

What Do the Three Verification Models Actually Guarantee?

The table below lays out the three models The Graph describes, along with the KelpDAO incident and the consensus math it uses to illustrate the weakness of majority voting.

Model / EventMechanismKey figure(s)
1-of-N trust (The Graph network)Any single honest participant can dispute bad data and get the offender slashedNo majority required to catch fraud
Consensus (Chainlink model)A majority vote among providers stands in for correctness5 providers at 20% failure rate each: about 5.8% odds bad data wins the vote vs about 0.03% odds all 5 fail at once
Cryptographic verification (The Graph's Amp)Recomputes the chain's own hashes and Merkle roots during extractionCatches a single tampered log before it becomes queryable
KelpDAO bridge exploit (April)RPC infrastructure poisoned, feeding corrupted data to the bridge verifier$292M stolen without touching a smart contract

Why Did the KelpDAO Attack Matter So Much?

The KelpDAO exploit mattered because it proved a bridge can be drained without a single line of smart contract code being touched. Attackers targeted the RPC infrastructure — the layer that feeds real-world blockchain state to a verifier — and corrupted what the verifier believed was true. The result was a $292 million loss that no audit of the bridge's contracts would have caught, since the contracts themselves executed exactly as written on the data they were given. This is why The Graph frames the incident as the moment the difference between verification models stopped being an academic debate.

RPC infrastructure refers to the remote procedure call servers and endpoints that relay blockchain state — transactions, blocks, logs — to applications and verifiers that don't run their own full node. If that relay layer is compromised, everything downstream that trusts it inherits the corruption, regardless of how secure the smart contracts themselves are. The KelpDAO case shows that securing the endpoints of the data pipeline matters as much as securing the endpoint of the contract logic.

Why Can a Majority Vote Still Be Wrong?

Majority consensus can fail because a majority of independently unreliable sources can still agree on the same wrong answer more often than all of them failing together. The Graph's own math shows this: with five providers each carrying a 20% individual failure rate, the odds that a majority (three or more) simultaneously produce bad data and "win" the vote sit around 5.8% — nearly 200 times higher than the roughly 0.03% odds that all five fail at the exact same time. Consensus, the model behind Chainlink's oracle design, treats agreement as a proxy for truth, but agreement and truth are not the same thing when failures are correlated or when an attacker only needs to compromise enough nodes to tip the vote, not all of them.

This is the mathematical core of why consensus-based oracle designs remain vulnerable even when individual node reliability looks reasonably high on paper. A 20% failure rate per node sounds tolerable in isolation, but once five nodes vote together, the probability of the group producing a wrong majority outcome is meaningfully higher than the probability of total system failure. Anyone relying on DeFi protocols secured by consensus oracles is implicitly accepting that 5.8%-class risk, whether or not it is disclosed.

What Does Cryptographic Verification Actually Prove — and Not Prove?

Cryptographic verification, as implemented in The Graph's Amp, recomputes a blockchain's own hashes and Merkle roots during the data extraction process, which means a single tampered log gets caught before it can ever reach an application as "clean" queryable data. This is the strongest of the three tiers because it does not depend on trusting a majority or a single honest watcher — it mathematically re-derives the correctness of the extracted data against the chain's own cryptographic structure. That said, The Graph is explicit that even this tier has a boundary: it proves the data was extracted and preserved faithfully from the source, not that the underlying source itself was honest in the first place.

The cost of this stronger guarantee is latency. Recomputing hashes and Merkle roots during extraction takes measurably more time than simply relaying data or waiting for a vote to settle, which is why The Graph frames the choice as a genuine trilemma rather than a solved problem: fast, comprehensive, and verifiable rarely coexist in the same pipeline. Teams building on Ethereum or any chain with high-value verifier logic have to decide which corner of that trilemma their use case can survive — a lending protocol liquidation engine has very different tolerance for latency than a dashboard displaying historical volume.

Bottom Line

The KelpDAO exploit turned an abstract distinction between 1-of-N trust, consensus, and cryptographic verification into a $292 million lesson: the weakest link in a data pipeline is often the infrastructure relaying information, not the contract executing on it. The Graph's own math on consensus — 5.8% odds of a wrong majority versus 0.03% odds of total failure — makes a concrete case for why cryptographic re-derivation, despite its latency cost, is the more defensible default for high-value use cases. What to watch next is whether more protocols start disclosing which verification tier actually backs their "verifiable" data claims, since the KelpDAO case shows the label alone tells you almost nothing about the risk you're actually carrying. For a broader grounding in how these systems fit into DeFi infrastructure, see the research hub and the site's learn section.

Frequently Asked Questions

1.What happened in the KelpDAO bridge exploit?

Attackers poisoned the RPC infrastructure feeding KelpDAO's bridge verifier and extracted $292 million without touching any smart contract. The exploit worked entirely by corrupting the data the verifier trusted, not by breaking on-chain logic, which is why The Graph cites it as proof that 'verifiable' data claims need scrutiny.

2.What is the difference between consensus and cryptographic verification?

Consensus, the model Chainlink uses, treats a majority vote among data providers as correctness — but majorities can still be wrong, with five providers at a 20% failure rate carrying 5.8% odds that bad data wins the vote. Cryptographic verification, used in The Graph's Amp, instead recomputes the chain's own hashes and Merkle roots during extraction, catching a single tampered log before it ever becomes queryable.

3.Does cryptographic verification guarantee the data source was honest?

No. Even The Graph's strongest verification tier only proves that data was extracted and preserved faithfully from the source, not that the original source itself was truthful. It also adds latency, which is the trade-off users accept for that stronger guarantee.

4.What is 1-of-N trust in The Graph's network design?

1-of-N trust is a model where any single honest participant in the network can dispute bad data and get the dishonest party slashed. It doesn't require a majority to catch fraud — just one honest actor watching.

5.What is the 'trilemma' The Graph describes for onchain data?

The trilemma is choosing between fast, comprehensive, and verifiable data — according to The Graph, no system delivers all three at once. Teams have to pick the mix their specific use case can tolerate, since maximizing verification typically costs latency or coverage.

Sources

thegraph.com/blog/verifiable-onchain-data-what-that-really-means

Related