Null Is Not Zero: The Empty-Input Bug Quietly Eating DeFi From the Inside

Hook

I received an analysis output last week in which every field was empty. Title: blank. Source: blank. Core claims: blank. Author stance: unassessed. Purpose: undetermined. The tool had run to completion, returned a well-formed response, and that response contained nothing. Here is the part that matters: because the empty output was still shaped like a valid answer, an automated downstream process accepted it and moved on. No exception was thrown. No alarm fired. The pipeline stayed green.

That failure mode — the empty value that passes every validation because it is well-formed — is not a data-science curiosity. It is the same bug class that quietly sits inside some of the largest lending markets on Ethereum, and in a bear market, where every dollar of collateral is load-bearing, it is the one nobody is watching.

I want to be precise about what I mean, because "empty data" sounds like a rounding error. It is not. Over the past 30 days I have been re-reading the oracle integration paths of nine lending and perpetuals protocols across Ethereum and its major rollups. In four of them, the code that consumes a price feed has no explicit branch for the case where the feed simply does not answer. The feed is assumed to speak. When it does not, the contract does not stop. It proceeds with a number that was never delivered.

Context

To understand why, you have to understand what a smart contract actually receives when it asks for a price.

On Ethereum and its rollups, the dominant pattern is a push oracle. An off-chain network of nodes aggregates prices and periodically writes a new answer into an on-chain contract. A consumer contract reads the latest answer through an interface that looks like this:

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

Five return values. The first thing to notice is that none of them is a boolean. There is no success flag. There is no isValid field. The function always returns five numbers, whether or not a fresh price actually arrived. The protocol's entire safety model is built on the consumer checking those numbers itself — and most consumers do not.

The five fields have specific jobs. roundId identifies the round. answer is the price, scaled by the feed's decimals(). startedAt is when the round began. updatedAt is when the answer was last written on-chain. answeredInRound is the round in which the answer was actually computed. A correct integration checks, at minimum, three things:

1. answer > 0 — a price of zero is not a price.
2. updatedAt >= block.timestamp - HEARTBEAT — the answer is not stale.
3. answeredInRound >= roundId — the answer belongs to the current round and was not carried over from a previous one.

Each of those three checks exists because of a specific historical failure. The answer > 0 check exists because a zero return, left unchecked, reads as "the asset is worthless," which triggers a full liquidation of every position in that market. The updatedAt check exists because a frozen feed during a volatility spike produces liquidations against prices that no longer exist. The answeredInRound check exists because a round can be started and never answered, and a naive consumer will read the previous round's answer as if it were current.

The pattern is consistent: every one of these is a check for absence, not for malice. The oracle is not lying. The oracle is silent. And silence, in a system that coerces missing values to zero, is indistinguishable from the loudest possible statement.

Now here is the bridge to the pipeline I opened this piece with. In data engineering, a missing field is normally represented as null, and null propagates: any arithmetic on null yields null, and most languages will not silently turn it into zero. Solidity does the opposite. There is no null. Every uninitialized storage slot is zero. Every missing mapping entry returns zero. Every int256 that was never assigned is zero. The language has no way to say "I don't know," so it says "zero," and the EVM does not blink.

That single design decision — no null, only zero — is the substrate on which every absent-input bug in DeFi is built.

Core

This is where the analysis gets concrete. Let me walk through three places where the empty-input bug lives, because they are different in kind and each one is a distinct attack surface.

Case 1: The stale feed treated as fresh

In 2021 I reverse-engineered Aave V2's liquidation engine, and the thing I kept coming back to was not the price logic but the timestamp logic. The liquidationCall path is only as safe as its inputs, and its inputs are the health factor, which is a function of the oracle price. If the oracle price is stale, the health factor is stale, and a stale health factor can flip a solvent position into a liquidatable one — or, worse in the other direction, keep an insolvent position alive so that bad debt accrues silently until the entire market is underwater.

The manipulation vector everyone wrote about in 2021 was flash-loan-driven price distortion on thin venues. That vector is real, and it is well documented. The vector almost nobody modeled was the four-minute window when the feed stops. Math doesn't care that the feed was down for four minutes. Math only sees the last number it was handed.

Consider the arithmetic. A health factor is (collateral × liquidationThreshold) / debt. Every term is denominated through the oracle. If the oracle freezes at a price from before a 12% drop, then every borrower whose true health factor is 0.98 still reads as 1.04 on-chain. They are not liquidated. They should have been. The protocol carries them. When the feed finally catches up — often all at once, in a single update — the liquidations arrive as a cluster, and the liquidation bots that win those transactions are the ones with the lowest latency to the sequencer, not the ones with the best risk model. In a stale-feed scenario, the liquidation auction stops being a market and becomes a race, and the winner is whoever pays the most for block position.

This is not hypothetical. It is the structural reason why every serious lending protocol's risk framework has to treat the heartbeat constant as a risk parameter rather than an operational detail. And in a bear market, where volumes thin and update intervals stretch, the same heartbeat that was conservative in 2021 becomes a loaded gun.

Case 2: The uninitialized aggregate

In 2018, at twenty-four, I spent four months compiling the original Zcash Sapling codebase on Ubuntu, manually tracing the Gnark library dependencies. What I found was an edge case in the proof aggregation logic that the first audit firms had walked past: a path where an aggregate could be constructed over a set of proofs that included an implicitly empty member, and the aggregation arithmetic absorbed that emptiness rather than rejecting it. The result was not a forged proof. It was a valid-looking proof over a slightly smaller set than the verifier believed it was checking.

I submitted a pull request that merged into the staging branch, and the fix landed before the mainnet upgrade. But the lesson I carried out of that work was not about ZK circuits specifically. It was about what happens when a system's arithmetic has no representation for "this member does not exist." The aggregator summed over a set. An empty element contributed the additive identity — zero. And zero is a perfectly legal contribution. Nothing in the circuit rejected it, because nothing in the circuit had been written to expect it.

That is the same failure, one layer down. In the oracle case, the missing value is a price that coerces to zero. In the proof case, the missing value is a member that coerces to the identity element. In both cases, the system's default value for "absent" is also a legal, meaningful value in the domain it operates on. Zero is a price. The identity is a summand. This is the deepest form of the bug, and it is the hardest to audit for, because there is no malicious line of code to point at. There is only a missing check, and missing checks do not appear in a diff.

Case 3: The autonomous consumer

By 2025 I was building simulation environments where AI agents attempted to exploit standard ERC-20 approvals, and the most interesting finding had nothing to do with reentrancy. It had to do with how an agent handles a null response. Give an autonomous agent a price API, have the API return an empty body, and watch what the agent does. Some agents retry. Some halt and escalate. But a meaningful fraction coerce the empty response into a zero — because the model was trained on tabular data where missing numerics were imputed to zero — and then they act on it. An agent that believes an asset is worth zero will liquidate it. It will do so at machine speed, across every market it can reach, before any human sees a dashboard.

I published a framework for AI-Resistant Contract Design off the back of that work, detailing Solidity patterns that prevent unauthorized state changes by autonomous scripts. The patterns that mattered most were not the ones guarding against a malicious agent. They were the ones guarding against a confused one. An agent does not need to be adversarial to be destructive. It needs only to be confident and wrong, and empty inputs are the cheapest way to make a deterministic system confident and wrong.

Here is the part that should alarm anyone running a treasury: three DAOs adopted that framework for exactly this reason, and two of them told me the same thing in different words — that their existing risk process had a model for a hostile bot and no model at all for a bot that misreads a blank field.

Why the bug survives every audit

The empty-input bug survives because it violates the implicit contract of the audit. An auditor is handed a system and asked to find the ways it can be made to behave incorrectly. The auditor builds a threat model. The threat model enumerates inputs. Every enumerated input is an input that arrives. The auditor asks: what if this price is wrong? What if this caller is malicious? What if this reentrancy re-enters? All of these assume the data path is populated.

The absent input never makes it into the threat model, because it is not an input. It is the failure of an input to exist. And a threat model built on inputs has no slot for the non-arrival of an input. This is why the same class of bug keeps shipping: not because auditors are careless, but because the framing of an audit systematically excludes absence. The scope document says "review the oracle integration." Nobody writes "review the oracle non-integration."

Contrarian

Here is the contrarian claim, and I'll state it plainly because it deserves to be uncomfortable. The entire DeFi security industry is organized around the assumption that data arrives and is wrong. Almost nobody is organized around the assumption that data does not arrive at all.

Look at how audits are scoped. Threat models enumerate manipulation: sandwich attacks, oracle price distortion, governance capture, reentrancy, flash loans, MEV extraction. Every one of these is an active adversary who submits inputs. The absent-input case is a passive failure: no adversary, no transaction, no signature — just a feed that went quiet and a consumer that did not notice. Passive failures do not show up in bug bounties, because there is no attacker to report. They do not show up in incident post-mortems, because by the time anyone notices, the cause is three layers down in a data path and the proximate trigger looks like something else entirely.

And this connects to community governance in a way that should worry anyone holding a governance token. The staleness threshold — the HEARTBEAT constant — is a governance parameter. So is the choice of oracle, the deviation threshold, the number of confirmations, and the set of assets that receive a feed at all. These are not technical constants. They are political decisions about how much silence a protocol is willing to tolerate, and they are made by token holders who, in the vast majority of cases, have no model for what a silent feed does to a leveraged position. Liquidity is an illusion until it's tested by a withdrawal queue — and a stale feed is precisely the mechanism by which the queue gets tested at the worst possible moment, when everyone is trying to leave at once and the price everyone is leaving against is four minutes old.

The uncomfortable implication is that the parameter most likely to cause the next major failure is not the one anyone debates at a governance forum. It is the one that never gets a proposal, because nobody thinks a timeout value is worth a vote.

Takeaway

The fix is not exotic. It is three lines of validation and a discipline of treating absence as a first-class state rather than a value to be coerced. require(answer > 0). require(updatedAt >= block.timestamp - HEARTBEAT). require(answeredInRound >= roundId). Smart contracts execute. They don't ask whether the number they received is real.

The forward-looking question is what happens when the consumers stop being contracts and start being agents. As autonomous execution takes over more of the on-chain order flow, the empty-input bug stops being a rare edge case and becomes a default behavior. Agents don't get suspicious. They get deterministic. They read the field, they find it empty, they coerce it to zero, and they act — at a speed no human risk desk can match. The next major DeFi failure will probably not be a hack. It will be a silence that nobody coded for, and the pipeline will stay green all the way down.