The most dangerous input in any system is the empty one.
In late 2025, a lending market with a nominal $340M in total value locked quietly began pricing its largest collateral asset at zero. Not the price of the asset—the asset itself. There was no exploit thread on X, no post-mortem, no bounty claim. The dashboard stayed green because the dashboard had nothing to render, and nothing, rendered faithfully, looks exactly like a healthy flat line. What had actually happened was simpler and far more damaging than a flash-loan attack: an oracle wrapper returned a zero-length byte string, the aggregator's fallback path decoded it as a valid integer, and the integer happened to be zero. For forty-one minutes, every position in that market was simultaneously under-collateralized by a number that did not exist.
I spent three weeks reconstructing the transaction trace from archive nodes. The exploit was not in the code they wrote. It was in the code they never considered—the path where the data simply is not there. Reentrancy doesn't announce itself, and neither does an empty return. Both exploit the gap between what a developer assumed and what the execution environment permits.
This is a story about that gap.
The Data Layer Nobody Audits
We have spent a decade building elaborate machinery to prove that data is correct. Zero-knowledge proofs, optimistic fraud windows, threshold signatures, multi-sig quorums. The entire intellectual capital of the industry has been directed at one question: how do we verify a claim?
Almost none of it has been directed at a prior question: what happens when there is no claim to verify?
The distinction matters because these are not the same failure mode. A false price feed can be slashed, disputed, or overridden. A missing price feed cannot be slashed, because there is nothing to slash—no signature to invalidate, no bond to seize, no actor to punish. The absence of data is not a lie. It is a silence, and silence does not lie, it simply gets interpreted. Every consuming contract must decide, on its own, what silence means. Most decide badly, because the Solidity type system gives them no help.
Consider the primitive. When a contract calls an external function, it executes a CALL opcode. The call returns two things that matter: a success flag and a block of return data. The success flag is a single boolean. The return data is an arbitrary byte array of arbitrary length, including length zero. Solidity's high-level syntax lets you write:
(uint256 price, ) = oracle.latestPrice();
require(price > 0, "bad price");This looks safe. It has a require. It checks for zero. But the ABI decoder runs before your require. If the oracle returns an empty byte string, the decoder reads the first 32-byte word of a zero-length buffer and—depending on the compiler version and the exact decoding path—either reverts cleanly or, in older and more permissive paths, yields 0 as the decoded value. If it yields 0, your require fires and you revert. Fine. But now rotate the scenario: what if the check is require(price != 0) and the intended semantic is "the feed has not been initialized"? Then a legitimate zero price and a missing data payload become indistinguishable, and the contract has no way to tell them apart. You have collapsed two orthogonal states onto a single value, and you have done it invisibly.
The art is the hash; the value is the proof. But a hash of nothing is a well-defined object, and that is precisely the trap. The empty input is not an error state that the type system protects you from. It is a legal state that your logic must explicitly exclude, and almost nobody does.
How Absence Propagates
The reason this is not a single-contract curiosity is composability. In a monolithic system, a null input triggers a null output and the failure is contained. In a composable system, the null input is passed downstream, reinterpreted at each hop, and amplified.
Let me trace the mechanics, because the amplification is not obvious until you watch it unfold on-chain.
At the base layer, an oracle reports a price. The report is a signed struct with a timestamp. Now suppose the data-availability guarantee behind that oracle degrades—a gateway goes dark, a sequencer drops a blob, a keeper bot fails to post. The oracle, being a well-engineered system, does not lie. It returns stale data, or it returns a sentinel, or it returns nothing. Each of these is a distinct failure, and each one is handled differently—or, more often, handled identically, which is the bug.
Stale data is the best case, and it is the one the industry has actually thought about. Chainlink solved decentralization of price feeds by running a set of independent nodes, but the node set is small, the operators are identifiable, and the update threshold is a function of deviation and heartbeat, not of truth. A heartbeat of one hour means that for sixty minutes, the feed reports yesterday's world. In a market that moves 4% in a block, that is not decentralization—it is a latency feature wearing a decentralization costume. Yet even this weak guarantee is stronger than the guarantee for missing data, because staleness at least carries a provable timestamp. You can write require(block.timestamp - updatedAt < 3600) and you have bounded the damage. There is no equivalent guard for absence. You cannot write require(data exists) in Solidity, because every bytes value "exists"—it just might be empty.
The middle layer is where amplification begins. A lending protocol consumes the oracle and computes a health factor. If the oracle returned a zero because the data was missing, the health factor collapses, and every borrower becomes liquidatable. This is not a theoretical cascade. I modeled it in a Python harness across 512 pools using the constant-product approximation I first built during the DeFi Summer reverse-engineering work, and the result was consistent: a single missing upstream datum, unrejected, produces a liquidation wave whose magnitude is proportional to the square of the pool's leverage distribution, not its mean. Concentrated leverage is not just risky for the borrower. It is a multiplying coefficient on the damage of every downstream data fault.
A liquidator bot, which is itself a piece of infrastructure, sees the collapsed health factor and acts. It cannot know the health factor was computed from silence. It receives a number, and numbers computed from nothing look exactly like numbers computed from something. So it liquidates. The liquidation moves price on the DEX that serves as the venue. That price move becomes a fresh input to the same oracle that just silently failed. The loop closes.
And at the application layer, the human sees a dashboard. The dashboard reads the same on-chain state. It shows green, because green is the default CSS class for a value that parsed, and a value that parsed from silence is a value that parsed. We have built an industry where the visual representation of truth and the visual representation of a missing truth are pixel-identical.
This is the structure of the problem. It is not an exploit. It is a missing require statement, replicated across four layers of abstraction, each of which trusted the layer beneath to have already checked.
The Return-Data Decoding Minefield
If you want to find these bugs, you do not read the protocol's own functions. You read every place it calls out—every CALL, every STATICCALL, every DELEGATECALL—and you ask one question: what happens if this returns less than I expect?
I keep a running list of the decode paths that fail open rather than fail closed. It is not short.
The ERC-20 boolean problem. The standard says transfer returns a boolean. Many tokens, most notoriously the largest stablecoin by volume, return nothing at all. The bytes buffer is empty. A contract that writes require(IERC20(token).transfer(to, amount)) will, on a strictly-typed decoder, revert—because there is no 32-byte word to read. On a permissive decoder, it may read zero and revert anyway, or it may interpret an empty return as success depending on how the assembly was written. There is a widely-deployed pattern using inline assembly that explicitly checks returndatasize() and treats a zero-size return as success, in order to be compatible with these tokens. It is correct for its purpose. It is also the same pattern that, generalized carelessly, treats any empty return as success, including the empty return of an oracle that has nothing to say.
The same bytes, 0x, mean "success" in one context and "I have no data" in another. The opcode layer does not distinguish. Only the developer's intent does, and intent is not enforced at runtime.
The try/catch illusion. Solidity added try/catch for external calls. Many developers believe it catches everything. It does not catch the most dangerous case. try catches a reverting call. It does not catch a call that succeeds and returns a value that is semantically empty. An oracle that returns (0, 0) with a successful status is not caught by any catch block. The call succeeded. The data is garbage. Your catch will never fire, and you will proceed to price the world at zero with the full confidence of a system that believes it handled its errors.
The timestamp sentinel. Some feeds communicate "unavailable" by returning updatedAt = 0. Others return updatedAt = type(uint256).max. Others return the current block timestamp, which is technically true and totally useless for freshness. If your staleness check is block.timestamp - updatedAt < MAX_AGE, an attacker who controls a feed's availability can pass the check by returning block.timestamp—fresh, valid, and empty of meaning. This is not hypothetical; it is a pattern I flagged in a 2024 review of an oracle adapter whose fallback path set updatedAt to the current timestamp so that the require would not fire. The developer thought they were hardening the code against stale data. They had actually defeated their own staleness guard.
The multi-hop re-encoding. In aggregator designs, a round's answer is passed through a reporting layer, a median layer, and a final wrapper. Each layer re-encodes the value. If a middle layer receives an empty buffer and default-initializes its output to zero rather than reverting, the final layer sees a perfectly normal zero and has no way to know it originated as absence. By the time the value reaches the consuming protocol, all evidence of the original silence has been laundered away. Forensic tracing becomes archaeology: to find the origin, I have had to replay the entire round from archive state, because the on-chain record only shows the well-formed lie at the end, not the empty truth at the beginning.
The off-chain ingestion. Not all data faults live in the EVM. Many protocols ingest off-chain feeds—CEX prices, API responses, signed reports—through a keeper. If the keeper's HTTP client hits a timeout and returns an empty body, and the parser's json.loads("") is wrapped in a broad except that substitutes a default, the default flows on-chain as if it were observed. I have traced liquidations back to a keeper whose API returned HTTP 204 No Content, which the deserializer silently coerced to a zero-valued struct, which was signed and posted, because the signing key had no schema validation before it signed. The chain confirmed the transaction. The chain confirms everything, including the absence of the thing you thought you signed.
This is why I argue that the correct mental model is not "the oracle can be wrong." That model is already priced into every risk framework. The correct model is "the oracle can be absent, and absence is not covered by any existing risk framework." There is no slashing for silence. There is no dispute for a value that was never claimed.
What Missing Data Actually Costs
Let me put numbers on this, because the industry is allergic to anything it cannot price.
A single liquidation event in a deep market costs the liquidated borrower a penalty—typically 5–10% of the position—of which the liquidator takes a share and the protocol's insurance fund absorbs the rest. That is the visible cost and it is well understood. The invisible cost is the withdrawal of liquidity that follows. When lenders observe that a market can be liquidated by an event that has nothing to do with price, they do not re-price risk; they exit the market entirely, because they cannot model a risk whose trigger is the absence of information. I have seen TVL in a mid-cap lending pool fall 60% in the two weeks following a data-fault liquidation wave, not because the pool was insolvent—it was not—but because depositors could not answer the question "what would prevent this from happening again?" and a market that cannot answer that question experiences a permanent discount to a market that can.
That discount is the real cost. It is uninsurable, it is uncollateralized, and it compounds. Every protocol that has suffered a data-fault liquidation carries it forever in its rate spreads.
We do not build for today. The protocols that will survive the next cycle are the ones that treat the empty input as a first-class adversary, not a rounding error.
The Contrarian Angle: Your Resilience Score Is Lying
Now the part that will be unpopular.
The industry has responded to this class of problem by building dashboards. "Resilience scores." "Decentralization metrics." I have contributed to this tendency myself—after the NFT metadata work, I built resilience scoring into my own audits, and I still use it. But I have come to believe that a resilience score is a liability when it is computed from observable availability rather than from tested absence.
Here is the difference. An availability metric asks: is the feed up? A resilience metric asks: is the feed up? They are the same question wearing different clothes. Neither asks the only question that matters: what does the system do when the feed is down? And I can tell you from having audited dozens of these systems that almost nobody tests the down case in production-like conditions, because the down case is inconvenient to simulate. So the score is computed from the happy path, and the happy path is always a five.
The score itself becomes an attack surface. A protocol that publishes a high resilience score creates an incentive to demonstrate that the score is wrong—not through an exploit, but through the far cheaper act of inducing a missing-data condition. You do not need to break the oracle. You need only to make one node's gateway time out during a window when the deviation threshold is not triggered, and the absence propagates through a system that everyone believes is resilient because the dashboard says so. A metric that cannot be falsified under adversarial conditions is not a metric. It is marketing.
This connects to a broader pattern I have watched for years. The projects that pass their audits most comfortably are often the ones with the smallest attack surfaces in their written code and the largest ones in their unwritten assumptions. Auditors review what is deployed. The empty-input path is, by definition, undeployed logic—it is the branch that never runs in testing and runs exactly once in production, at the worst possible moment, on the most leveraged position. Reentrancy gets audited because it has a name and a Wikipedia page. The null-decode path does not get audited because it has no name, and things without names do not get budgets.
There is a regulatory echo here too. The compliance frameworks being layered onto DeFi in 2025 and 2026—KYC gates, transfer restrictions, sanctions screening—are all designed around the assumption that data exists and can be filtered. Screening requires a payload. A wallet-holdings check requires a balance that can be enumerated. These systems are themselves built on the assumption of complete data, and they fail in exactly the same way when data is missing: they fail open, because the default posture of a filter is to pass what it cannot parse. The compliance costs fall, as they always do, on the honest users who submit complete data and wait, while the system's blind spots are the paths that carry no data at all. I will go further: the entire apparatus of on-chain surveillance assumes a legibility that the infrastructure does not actually guarantee. It is theater staged on top of a data layer that cannot promise the audience will even be present.
And it points, finally, at the deepest structural divide in the industry. A system that cannot represent absence cannot represent privacy. The two are the same problem. Privacy is the deliberate withholding of information; absence is the accidental withholding of it. A protocol that panics on absence can never be trusted with intentional silence, and a system that demands total data completeness is, by construction, a system that cannot tolerate a user who simply declines to speak. The CBDC designs now circulating—programmable, fully-enumerated, requiring complete disclosure of every transaction—are built on precisely the assumption I am describing: that all data is present, all of the time. That assumption is not a security model. It is a surveillance model, and it is technically indistinguishable from the fragile systems I have spent this article dissecting. Where one fails toward zero, the other fails toward total exposure. Neither is a design that respects the possibility of the empty input.
Technical Debt, Priced Honestly
I want to be concrete about what a fix looks like, because criticism without a patch is just noise.
The first fix is at the interface level: every external data call must treat the empty return as a distinct, explicit state. In Solidity, this means checking returndatasize() before decoding, and reverting—not defaulting—on a zero-length buffer. It means never writing a fallback that substitutes a default value for a decode failure, because a default is a lie of omission. It means decoupling "zero" from "missing" in the type system wherever the language permits, and where it does not, using a separate boolean validity flag that must be set explicitly at the source.
The second fix is at the aggregation level: staleness bounds must be enforced against a monotonic source, not against a value the feed itself supplies. If a feed can return the current timestamp as its update time, your freshness check is not a check. Anchor the bound to something the feed cannot forge.
The third fix is at the testing level, and it is the one nobody does: fault injection for absence. Before any protocol is deployed with meaningful TVL, run its entire relevant call graph against a mock that returns empty buffers, reverts intermittently, and returns well-formed zeros with successful status codes. I have made this a mandatory step in my own reviews since the ZK-Rollup benchmarking work in 2022, and the hit rate is brutal—roughly one in four protocols I test this way fails at least one downstream invariant within the first hour. That number is a measure of how much of this industry's claimed resilience is untested.
The fourth fix is cultural: stop scoring what you have not broken. A resilience score should be a function of adversarial absence tests passed, not of node counts and uptime percentages. If you cannot demonstrate the system failing gracefully under data starvation, the score is a story, not an assessment.
The art is the hash; the value is the proof. But there is a corollary the industry has not internalized: the absence of a hash is also a signal, and a system that cannot read that signal is not secure—it is merely lucky.
Look Forward: The Vulnerability Forecast
So here is my forward-looking judgment, offered in the exact form I would give it to a fund making an allocation decision.
Within the next eighteen months, I expect at least one top-20 lending protocol to suffer a liquidation event whose primary cause is a missing-data condition rather than a price move. The mechanism will not be novel; it will be one of the four decode paths I listed above, unpatched because it has never been tested. The damage will be concentrated in the deepest, most leveraged pools, because that is where the amplification is quadratic. The post-mortem will describe it as an "oracle anomaly," which is the industry's phrase for a bug it does not want to name, and the fix will be a patch to a single protocol rather than a change to how the industry tests data availability.
We do not build for today. We build for the version of the system that has to survive contact with a world where information is sometimes simply not there—where gateways go dark, blobs go missing, signatures go unsigned, and the honest, correct answer to "what is the price?" is "I do not know."
The protocols that can say "I do not know" and act accordingly will inherit the market. The ones that cannot will keep printing zeros to their dashboards, green and serene, all the way down—and they will wonder, in the post-mortem, why the code they audited so carefully never warned them about the input that never came.
The art is the hash. The value is the proof. But the danger, always, is the signal that never arrives—and the system that was never built to notice its silence.
