Null Is Not Zero: The Input-Verification Gap in On-Chain Data Pipelines

Over the past 7 days I watched a monitoring dashboard render a perfectly flat line for a protocol that had, in fact, lost roughly 40% of its liquidity. The dashboard was not broken. The indexer was not down. The number it displayed was 0, and 0 was a valid answer to the query it had asked. The query was wrong. The schema had no way to say "unknown." The renderer drew a straight line because a straight line is what zero looks like when you do not know how to say nothing.

I have hit this shape of failure three times in six years — once in an audit harness, once in a lending market fork, and once in a data availability client. It is always the same bug wearing different clothes. The system distinguishes "the answer is zero" from "there is no answer" badly, or not at all, and every layer above it inherits that ambiguity and launders it into confidence.

That is the failure mode I want to dissect here. Not reentrancy. Not key management. The absence of data, and the industry's structural inability to encode absence.

Context: Why Deterministic Machines Need Oracles At All

A blockchain is a deterministic state machine. Given the same block and the same transaction, every node computes the same result. That property is what makes consensus possible, and it is also what makes oracles necessary. A deterministic machine cannot reach out and ask the weather. It can only read state that something else has already written.

So the whole architecture of "blockchain data" is a chain of custody. An off-chain reporter observes a fact. A signed transaction writes that fact into contract storage. A consuming protocol reads it. At every hop the fact can degrade. It can be stale. It can be manipulated. It can be absent.

The Chainlink aggregator interface — the one almost every DeFi protocol consumes, in some fork or wrapper — returns five values:

function latestRoundData()
    external
    view
    returns (
        uint80 roundId,
        int256 answer,
        uint256 startedAt,
        uint256 updatedAt,
        uint80 answeredInRound
    );

Five values, and only one of them is the number everyone actually cares about. The other four exist because the number alone cannot tell you whether it is trustworthy. updatedAt carries the heartbeat. answeredInRound tells you whether the current round was carried forward from an older one. roundId lets you detect a round that has closed but not been superseded.

That interface is a piece of quiet engineering pessimism. It assumes the answer might be a lie, a memory, or nothing at all. Most of the code that consumes it does not share that pessimism.

Core: The Type System Has No Slot For "I Don't Know"

Here is the canonical consumer, reproduced thousands of times across forks:

(, int256 answer, , , ) = priceFeed.latestRoundData();
require(answer > 0, "invalid price");
return uint256(answer);

Four of five return values are discarded with commas. The staleness check is gone. The round-consistency check is gone. What survives is a single guard against negative prices — a guard that exists mostly because int256 was the wrong type in the first place.

This is the most common bug class in DeFi, and it is not treated as a bug class. It is treated as a code-review nit.

The reason it persists is type-theoretic. Solidity has no nullable types. There is no uint256? that can hold either a number or the absence of a number. Every protocol that wants to express "we do not have a price" must invent a sentinel: 0, or type(uint256).max, or a separate bool valid flag riding alongside. Sentinels are ambiguous by construction. Zero is a legitimate price for some assets — a token pinned at a bonding curve floor, a share value before initialization, a funding rate sitting exactly at neutral. The moment you use 0 as your null, you have either made 0 unrepresentable as a value or made null indistinguishable from a real reading. You cannot have both.

I ran into the downstream consequence of this in 2021, while tracing a fork of a lending market that had inherited a 24-hour staleness window from a codebase built for a completely different asset class. The window was fine for a feed with a one-hour heartbeat. It was catastrophic for a feed that updated on a 0.5% deviation threshold, because a genuinely quiet market could drift eleven hours without a deviation update, and the protocol read that quiet as health. The exploit never happened; the window was tightened after I filed it. But the finding was never "the staleness check is missing." It was "the protocol has no model of its input's actual update cadence, so it cannot distinguish stale from quiet." The check existed. The semantics did not.

That distinction — stale versus quiet — is the heart of it. A feed that has not updated because nothing moved is healthy. A feed that has not updated because the reporter process is dead is insolvent. Both look identical at the storage layer. Separating them requires a heartbeat that fires regardless of deviation, or a second signal, or a liveness assumption you have actually written down somewhere. Most protocols have none of the three.

The same pattern appears everywhere once you start looking for it.

Take data availability sampling. Celestia's design rests on the claim that a light node can sample a small random subset of erasure-coded blobs and, with high probability, detect whether the full data is unavailable. The underlying result is elegant — Reed-Solomon coding turns a withholding attack into a probabilistic certainty at logarithmic sampling cost. But the implementation detail that decides whether it works in practice is the error taxonomy. When a sampling request fails, the node must separate three situations. The data is genuinely unavailable. The request timed out. The request was never dispatched. Only the first is a security event. The second is a liveness event. The third is a bug. Collapse all three into a single ErrNotFound and you have rebuilt the oracle consumer who threw away answeredInRound.

When I led analysis of Celestia's DAS mechanism in 2024, the finding that actually mattered was not in the proof. The proof was fine. It was in the gRPC layer, where a latency bottleneck under load could cause sampling requests to be dropped rather than retried, quietly degrading the availability guarantee from "probabilistic certainty" to "probabilistic certainty, conditional on the network being fast, which none of the documentation asserted." I proposed a Reed-Solomon-aware scheduling optimization that never shipped because it benchmarked slower than the version management already had. The community adopted a variant of the audit anyway.

Now consider AI agent oracles, which are the current fashion. A large language model asked to produce an on-chain prediction is a function with no reproducibility guarantee. Run it twice, get two answers. Consensus requires every validator to derive the same state transition from the same inputs. A non-deterministic oracle cannot satisfy that without a trusted third party rendering a verdict everyone else accepts on faith. And note the specific failure mode: when the model is uncertain, it does not return null. It returns a confident paragraph. There is no null in natural language. The absence of knowledge gets expressed as fluency. That is strictly worse than a missing staleness check, because a missing staleness check at least trips a require eventually.

The same pathology reaches the analytical layer. A growing share of protocol research is now generated, and the tell is never the prose. The tell is the shape of the argument: an elaborate scaffold of dimensions and headings, all of it resting on inputs that were never supplied. A framework that emits conclusions from an empty input set is not lying. It is doing exactly what it was written to do — likelihood-free inference, where the posterior collapses onto the prior, and the prior is the average of everything the model has already read. The output is real. It simply carries zero information gain.

A report with no new information is an oracle with no heartbeat: it answers, on time, forever, and the answer is whatever it was yesterday.

Let me make the trade-off explicit, because "always check staleness" is not free and the matrix is less obvious than the audit checklist implies.

| Strategy | Failure mode caught | Capital efficiency | Latency cost | Attack surface | |---|---|---|---|---| | Fail-closed (revert on stale) | Stale, absent | Low — halts on every heartbeat gap | High | Griefing via feed pause | | Sentinel (0 = unknown, continue) | Nothing | High | None | Sentinel collision, silent insolvency | | Circuit breaker (halt on deviation) | Manipulation, staleness | Medium | Medium | Breaker governance capture | | Fallback feed (secondary oracle) | Single-feed outage | Medium | Low | Correlated failure, both stale | | Optimistic (accept, dispute later) | Most, eventually | High | High (finality delay) | Cost of dispute bonds |

The fail-closed row is where institutional money lives. Every serious lending market that survived 2022 halts on stale data, because halting is a liveness problem and insolvency is a solvency problem, and liveness problems are recoverable. The sentinel row is where most of the TVL lives, because it never halts, and halting is expensive when depositors want out during exactly the volatility that makes a feed go stale.

That trade-off is real, and it is why the bug persists. Code is law, but bugs are reality — and this particular bug is a business decision that got compiled.

Contrarian: Verification Proves Computation, Never Provenance

The industry's answer to all of this is "verification." ZK proofs, optimistic fraud proofs, TEE attestations, restaking-backed economic security. Every one of those is a mechanism for verifying that a computation was performed correctly. None of them verifies that the computation was fed real data.

A Groth16 proof is a statement about a relation. It says: there exists a witness w such that the constraint system is satisfied. It does not say w is true. If your circuit accepts an unconstrained private input — and most circuits do, because hiding the input is the entire point — then a prover who controls the witness can generate a valid proof of any statement the circuit expresses. The proof is not a lie. The proof is a flawless answer to a question you should not have asked.

Zero-knowledge isn't mathematics wearing a mask. It is mathematics holding a mask, and the mask is yours to shape. Feed it nothing and it will prove nothing, beautifully. A valid proof of computation says nothing whatsoever about the validity of the witness. Verifying execution without verifying input provenance is a sealed room with an excellent lock mounted on the inside of the door.

That is the blind spot in the current verification narrative. Five years have gone into systems that can prove f(x) = y and almost none into systems that can prove x came from somewhere. The oracle problem was declared solved at the data layer and never solved at the semantics layer. Absence is still unencodable. Staleness is still a code-review nit. Every zk rollup inherits the ambiguity of its inputs while advertising the certainty of its outputs.

The corollary in the AI-adjacent corner is sharper still. Restaking markets will happily sell you economic security for a verifiable computation. Nobody is selling economic security for the claim that the input was real, because that claim is not a computation. It is a fact about the world, and facts about the world do not have proofs — only attestations, and attestations have signers, and signers have keys, and keys get compromised.

Takeaway

The next wave of significant exploits will not be reentrancy. Reentrancy is well understood, well tooled, and largely priced in. The next wave will be absence bugs: feeds that returned a sentinel, clients that collapsed a timeout into a negative, agents that answered fluently when they should have refused. In a sideways market, where nothing is moving and every feed is quiet, the difference between quiet and dead stays invisible right up until it is expensive.

So here is the question I would put to any protocol currently on my watchlist. When your oracle stops answering, does your contract know? Not "does it revert." Does it know. If the answer is a require(answer > 0) and four discarded return values, you do not have an oracle problem. You have an input problem — and the constraints for it were never written.