The query came back HTTP 200. The JSON validated cleanly against the schema. Every key was present โ price, timestamp, roundId, decimals. Every value was empty. The dashboard rendered it green. The risk engine, reading a missing number as zero, computed a health factor of infinity. No exception. No alert. No revert.
That was the moment I stopped trusting the phrase "the data loaded." I have spent the better part of a year tearing apart the pipelines that feed DeFi risk engines โ oracles, subgraphs, indexers, RPC aggregators โ and the failure that keeps surfacing is not the dramatic one. It is not the crash. It is the empty template: a well-formed response with nothing inside it. A schema without data is not a null. It is a lie that compiles.
On-chain data does not simply appear. It moves. Extraction feeds normalization, normalization feeds indexing, indexing feeds serving. At every hop, a schema declares what a "valid" response must look like. That schema is a contract โ but a thin one. It validates shape. It never validates substance.
Consider what a feed actually returns. A Chainlink aggregator answers latestRoundData() with a five-tuple: roundId, answer, startedAt, updatedAt, answeredInRound. A subgraph answers with entities. An RPC node answers with a JSON-RPC object. All of these can be structurally perfect and semantically hollow. The keys are right. The values are gone.
The reason is that extraction is the fragile stage, and everything downstream assumes it succeeded. A URL rots. A rate limit returns a 200 with a captcha body where the price should be. An indexer falls behind the chain head and serves a snapshot from two hours ago. A parser does not know it received garbage โ it knows it received something, and something with the correct keys passes validation. The pipeline reports success because success is defined as "parseable," not "true."
There are four ways this happens, and they map cleanly onto the four ways any data pipeline dies. Fetch failure: the endpoint returns stale or default data. Pipeline breakage: a queue drops a message and the next stage reads an empty default. Template-as-result: an API returns an unfilled object instead of an error code. Type failure: the payload is not text at all โ an image, a PDF, a captcha page โ and the extractor silently coerces it to an empty string. None of these raise a flag, because none of them violate the schema. The schema was never asked whether the data was real. It was only asked whether the data had the right shape.
This is why the empty template is so hard to see from the outside. Every observable signal โ the status code, the response time, the payload size โ looks healthy. A failed fetch that returns a 500 is trivial to catch. A failed fetch that returns a 200 with a null-filled body is invisible to everything except the code that reads the value, and that code has already been told the request succeeded.
Here is the part that matters, and it lives in the type system.
In JavaScript, null and 0 are different values, and a careless comparison can still be caught. In Solidity, they are the same thing. A uint256 has no null. Zero is a valid price and a valid absence, and the compiler has no obligation to tell you which one you are holding. This is the mechanical root of the null template problem. The chain cannot represent "I don't know." It can only represent zero, and zero is a number it will happily do arithmetic with.
I have written the exact bug more than once. A risk engine reads answer from an aggregator, multiplies it by collateral, divides debt by the result. If answer is zero, the collateral value is zero and the health factor collapses toward a division-by-zero that either reverts โ the safe case โ or, in a contract that guards the division with a conditional, quietly marks the position as infinitely safe. The second branch is the one that kills. It compiles. It runs. It is wrong.
The naive fix is to check updatedAt and answeredInRound, which is the advice every audit checklist repeats. It is necessary and it is not sufficient. A round can be fresh and still carry a default answer. A feed can update its timestamp while its upstream source is dark. The check confirms liveness, not truth.
The reorg case deserves its own line, because it is where availability and integrity blur. A round that was valid at block N can be orphaned by block N+2. An indexer reading the head at N+1 caches a price that no longer exists on the canonical chain. The value was correct. The value is now fiction. There is no attacker and no bug โ only the ordinary physics of probabilistic finality, which no schema was ever designed to represent.
The indexing layer has the same shape with a friendlier face. When a subgraph fails to sync, it does not return an error to the frontend. It returns an empty array. data.markets.length === 0 renders as "no active positions" and, in the UI, as a green checkmark. Empty is indistinguishable from safe. The dashboard is not lying to you. It is reporting the absence of data as the presence of calm.
Consider a DEX aggregator that quotes routes off a price feed. If the feed returns zero, the router does not refuse the trade โ it prices the pair at zero, and a zero price looks like a perfect arbitrage to any bot watching the mempool. The aggregator is not compromised. It is not even wrong by its own logic. It computed a route from the number it was given. The number was nothing, and nothing is the best price in any market.
And here is the trade-off that guarantees the bug persists. Teams choose between failing open and failing closed. Failing closed means the contract reverts when data is missing โ which is correct and which breaks every integration the moment a feed hiccups. Failing open means returning a default โ which keeps the product online and silently launders absence into a number. Almost every production system I have inspected fails open, because failing closed costs users and failing open costs truth, and truth does not have a support ticket.
The defensive move that actually works is unglamorous: you must separate zero from nothing at the boundary, before the number enters the type system. That means every feed needs a positive control โ a canary value you know is real, refreshed on a known cadence, checked independently of the payload you are about to trust. If the canary is missing, the feed is dark, regardless of what the schema says. Most systems skip this because it requires a second source of truth, and a second source of truth is expensive. The cheap version โ trusting the primary because it returned 200 โ is exactly the version that fails silently.
The detection problem is genuinely hard because absence has no signature. A wrong price is a spike you can chart. A missing price is a flat line you can mistake for a stable one. You cannot monitor for an anomaly that never arrives. This is why availability monitoring has to be built as a heartbeat, not a threshold โ you do not watch for something to go wrong, you watch for something to stop going right.
I ran into the same class of problem auditing Lido DAO's treasury machinery. The documented security model assumed that misconfiguration required an attacker. It did not. Three gaps in the upgradeability path meant that a parameter could drift to a default value under ordinary governance conditions, with no malicious actor anywhere in the loop. The theoretical model was intact. The runtime was not. The gap between a system's documentation and its behavior is always measured in defaults.
When I built a prototype oracle fusing zero-knowledge proofs with machine-learning outputs, the same ghost appeared. The model, unable to reach its data source, returned its prior โ a number. The proof verified the number. The proof was correct. The number was nothing. A verifiable computation over an empty input is still a verifiable computation, and it will still validate.
This is the distinction I want on the record: availability failure is not integrity failure, and the entire audit industry is staffed to catch the second one. Integrity asks "is this value correct?" Availability asks "is there a value at all?" Reentrancy guards, access controls, overflow checks โ every one of them is an integrity tool. None of them will notice that the feed returned a well-formed nothing. Code is the only law that compiles without mercy โ and the empty template compiles cleanly.
Everyone is braced for oracle manipulation โ the attacker who feeds a wrong price and drains a pool. That threat is loud, cinematic, and requires an adversary. The quieter threat is the feed that returns no price, and the system that accepts it. Manipulation needs a person. Absence needs only entropy: a lapsed subscription, a deprecated endpoint, a chain reorg that orphans the round an indexer was reading.
The security blind spot is structural. Audit reports are scoped to code paths a human can trigger. Data-availability failure is triggered by the world, not by an attacker, and it does not appear in a diff. I have read reports that spend forty pages on reentrancy and not one line on what happens when the oracle returns zero. The finding is invisible not because it is subtle but because nobody is assigned to look.
There is also a perverse incentive. A system that fails loudly gets fixed. A system that fails quietly gets shipped, because its failure looks like success on every dashboard it touches. The bug that reverts is a bug report. The bug that returns zero is a feature.
The forecast is not comforting. As AI oracles converge with on-chain data, the null template problem compounds rather than resolves. A model that returns its prior when it cannot reach its source is a null template with a larger parameter count and a better alibi. The next major DeFi incident will not look like a hack. It will look like a dashboard that was green because it was empty.
When your risk engine shows zero, how do you know it is zero โ and not nothing?