Last Tuesday a research pipeline I advise delivered a report to my inbox. It passed validation. Roughly four thousand tokens. Nine analytical sections. Thirty-one tables. Every heading present, every schema field populated, no parse errors, no required violations, no nulls. It was also, in its entirety, empty. Each cell contained the literal string "N/A" — not a missing key, not a failure code, not a truncation. The string. The document was structurally immaculate and semantically void, and every automated gate in the pipeline waved it through.
I have met this failure mode before, though never in a document. I have met it in a Solidity function that returned true and nothing else. I have met it in a Bitcoin block containing a coinbase transaction and no other transaction at all. I have met it in a storage slot holding zero that the contract was designed to read as a pointer to somewhere else. Each of those artifacts was valid, well-formed, and protocol-conformant. Each of them meant nothing. Each of them moved money.
What arrived in my inbox was the same bug wearing a researcher's clothes. And the reason it matters right now — in this particular quarter, with this particular volume of capital sloshing through freshly funded L2s and agent-run vaults — is that empty-but-authentic data is the one input class nobody is pricing.
Context: how these pipelines are actually built
The report came out of a four-stage pipeline. Ingest, which pulls source material from feeds, RPC endpoints, and document stores. Parse, which segments text and extracts typed fields. Score, which assigns weights and confidence. Publish, which renders a template.
Based on my audit experience, the gate that everyone builds sits at the boundary between parse and score. It is a schema. It looks like this in most implementations: a JSON object with required keys, type constraints, and occasionally minLength on strings. Ingest must return an object. Parse must return an array of information points. Each point must carry a claim field of type string and a confidence field of type number. If those conditions hold, the pipeline proceeds.
Notice what is not constrained. There is no minItems on the array. There is no check that the strings are anything other than placeholders. There is no assertion that the aggregate confidence distribution is non-degenerate. The schema enforces shape and shape only. An array of zero items satisfies "type": "array". A string containing "N/A" satisfies "type": "string" and, at four hundred characters, satisfies most minLength guards anyone bothers to write.
This is not a sloppy implementation. It is the correct implementation of the wrong contract. The schema does exactly what it was designed to do: guarantee that downstream consumers can safely index into the structure. It was never designed to guarantee that there was anything inside.
Three correct components produced one meaningless output, and the mechanism matters because the surface presentation — "the model hallucinated" or "the scraper failed" — obscures it. The upstream source returned a 200 with a body that was structurally a document but contained only a header and a disclaimer; that is a valid HTTP response. The extractor, asked to produce information points from a document with no information, correctly produced an empty list, because empty is the right answer to "extract everything relevant from nothing." The renderer, handed an empty list and a fixed template, rendered every heading with an empty value, because empty is the right rendering of empty.
The failure was not in any single stage. It was in the composition of stages that were individually correct.
That property has several names in crypto. I want to trace three of them, because each has already extracted a measurable amount of money from real protocols, and the fourth — the one arriving now — is worse.
Core: tracing the gas limits back to the genesis block
Tracing the gas limits back to the genesis block is instructive here. Ethereum's Frontier genesis block carried a gasLimit of 5,000. That is enough for roughly twelve simple transfers. It was not a protocol constant; it was a parameter chosen at launch, and it has been adjusted upward by miners and validators ever since, at a bound of one 1024th per block. The number is a political artifact with an engineering interface.
I bring it up because a block is defined by its header, and the header does not require transactions. A block with a coinbase transaction, a state root, and a receipts root computed over an empty transaction list is a valid block. Consensus does not care. Had the gas limit stayed at 5,000, an empty block would have been indistinguishable in cost from a full one.
Bitcoin made this concrete long before Ethereum did. In 2020, BitMEX Research documented sustained stretches in which a measurable share of Bitcoin blocks contained nothing but the coinbase. The explanations were mundane — a pool's block assembler had not yet received the mempool delta after the prior block, so it published a template it already held rather than wait. Publication beat optimization. The block was valid, the network accepted it, the miner collected the subsidy, and every full node performed the full work of validation, checked a merkle root over a single transaction, and advanced the chain.
The Bitcoin empty block is a liveness artifact: a miner chose speed over revenue. The Ethereum version is more interesting because post-Merge it became a safety mechanism. Under proposer-builder separation, a validator proposes via a relay. The relay returns a signed header, the validator signs it, the relay releases the block. If the relay fails to deliver the payload inside a deadline measured in seconds, the validator falls back to a locally built block. Geth's local builder will include pending transactions if it has any. If the node is a bare validator with an empty txpool, or if the local builder was misconfigured during a client migration, the fallback block is empty.
That empty block is not a failure. It is the protocol's graceful degradation path. An empty block is what a validator publishes when it decides that producing nothing is preferable to producing something late. The system was designed so that emptiness is always an available answer.
Hold that. It is the same design decision that produced my report.
Core: the empty call
Now the code level, where emptiness stops being a philosophical property and becomes a transfer of value.
Consider the low-level call pattern that has appeared in roughly every generation of Solidity since 0.5:
(bool success, ) = target.call(data); require(success);
This is idiomatic. It is also, in a specific and reachable case, wrong. If target has no code — an externally owned account, an address never deployed, or a contract that has already executed selfdestruct — the EVM does not fail. A CALL to a codeless address returns 1 and leaves the return data buffer empty. success is true. The require passes. The caller believes a state transition occurred. None did.
The exploitable form is subtler, and it is the one that has actually drained contracts. Find a function where the caller decodes the result. If the code reads (bool success, bytes memory result) = target.call(data); require(success); uint256 value = abi.decode(result, (uint256)); then the abi.decode on an empty buffer reverts, and that specific form is safe. The dangerous form is where emptiness silently satisfies a boolean:
bool ok = result.length == 0 || abi.decode(result, (bool));
That line — result.length == 0 || ... — is the most expensive || in Solidity. It reads as defensive coding. It is a backdoor. It declares that "returned nothing" and "returned true" are equivalent. They are not. One means the callee asserted success. The other means the callee has no opinion, because the callee does not exist.
OpenZeppelin's Address.functionCall family closed this by adding an explicit check that the target has code, reverting with AddressEmptyCode when return data is empty and the target's code length is zero. That library update was not cosmetic. It patched a class of bugs sharing one property: the malicious input and the absent input produced the same success signal.
There is a sibling worth naming because it survives extcodesize guards. extcodesize returns zero for a contract still executing its constructor. A guard reading "revert if target.code.length == 0" will let a contract under construction through, and that contract can call back into the guarded function before its own runtime code exists. The empty-code check and the empty-code exploit are two faces of the same measurement.
Core: emptiness as a pointer
The most elegant version of this failure mode lives in the ERC-721A batch minting standard, and I want to describe it precisely, because it shows how deliberate emptiness-as-meaning can be — and how fast that meaning inverts.
When I spent two weeks in 2021 reading the Bored Ape contract for gas structure, the finding that mattered was not the artwork layer. It was that the original ERC-721 implementation wrote an owner slot for every token in a mint. Mint ten thousand, pay ten thousand storage writes at twenty thousand gas each. ERC-721A inverted the model: it writes the owner slot only for the first token in a batch and leaves the rest zeroed. ownerOf then walks backward from the queried token ID until it finds a non-zero slot and returns that owner.
Zero, in other words, does not mean "unowned." Zero means "look elsewhere." The absence is a pointer. The gas savings — north of ninety percent on a large batch — come precisely from declining to store the answer and trusting the reader to reconstruct it.
That is a good design and a loaded gun, because the semantics of a token's ownership then depend on a walk across storage slots. Burn a token in the middle of a batch and the walk for that token ID terminates at the batch's first token, returning the owner of a token you did not ask about. Azuki's implementation handles this by zeroing the slot and explicitly re-assigning the next token in the batch — a patch that would be unnecessary if empty slots were not meaningful.
NFTs are not art, they are state channels. The image is a rendering artifact of a storage layout. And the layout's most load-bearing value is the one that was never written.
I will confess a bias here. The doc I received had nine sections, and every one was zero. The pipeline had no mechanism for distinguishing "the source contained no information" from "the source contained information and we are representing it compactly." It had no _burn fix. It read through to the beginning of the batch and returned the owner of a document that did not exist.
Core: the empty oracle and the empty blob
Two shorter cases, because they generalize the pattern into infrastructure.
A price oracle that cannot reach quorum does not produce a round. But a price oracle that reaches quorum on the wrong thing produces a perfectly well-formed number, and at the interface, a well-formed number that is wrong is indistinguishable from a well-formed number that is right. The May 2022 LUNA feed is canonical: Chainlink's aggregator was bounded by a minAnswer parameter, and when market price collapsed below that floor, the feed kept reporting the floor. Protocols that checked answer > 0 — several of them, notably on BSC — saw a valid, non-stale, positive price. Venus Protocol accrued bad debt against a feed functioning exactly as configured. The output was not empty. It was emptied of information by a bound no consumer could observe in the return values.
That is the oracle version of the schema problem. The consumer validated the shape — five fields, correct ordering, positive answer — and the shape was correct.
Now the version being built right now. Under EIP-4844 a rollup posts blobs, and a blob is a fixed-size vector of field elements committed to by a KZG commitment. The blinding factor can be zero. The all-zero blob is a valid blob. It is committed to by a valid commitment, passes the point-evaluation precompile, and is available to every node that samples it. A data availability sampler proves availability. It does not prove content. A rollup posting zero-knowledge blobs, or blobs whose decoded payload is a well-formed but empty batch, has satisfied every availability guarantee the architecture provides.
Optimism is a gamble. ZK is a proof. Neither is a statement about whether the thing proved is worth proving.
Contrarian: your threat model is built for the wrong adversary
Here is where I depart from the standard security posture, and where I think most audit budget is currently misallocated.
The industry's threat models are built for malicious data. We audit for reentrancy, price manipulation, signature replay, sequencer censorship of withdrawals. Every one of those assumes an adversary who submits something. Fuzzing is the archetype: generate adversarial inputs, observe invariant violations. Foundry's invariant testing, Echidna, Medusa — all of them are generators of content.
Almost nobody fuzzes for absence, in the sense that matters. Foundry will happily let a handler be called with zero arguments, but the corpus distribution is still over function calls. The case where the entire target contract has no code, where the oracle has never updated, where the information point list is empty — that is not a generated input. It is a state.
Formal verification has a name for this and treats it as a first-class defect, which is telling. A require(false) at the top of a function makes every subsequent invariant trivially hold. A specification whose precondition is unsatisfiable is vacuously satisfied. Certora and the K-framework toolchain both ship vacuity detection because a verification report saying "all properties hold" over an empty reachable state space is worse than a report saying "failed." Both are meaningless; only one looks like success. Vacuity detection exists because a proof of nothing is the most convincing artifact in the discipline.
Composability is a double-edged sword for security, and this is the edge people keep cutting themselves on. When protocol B integrates protocol A, B's risk surface includes A's return values. If A's fallback returns empty and B treats empty as benign, then A's non-existence is B's exploit. The empty return propagates through the composition the same way a true return does, because at the ABI boundary they are the same four bytes of nothing.
And the L2 bridge is just a pessimistic oracle: it assumes invalid until a proof arrives, which is the right instinct. But a proof of an empty state transition is a valid proof. The bridge does not check whether the L2's state root advanced by doing something. It checks that the root is committed and the proof verifies.
Takeaway
In a bull market this failure mode compounds. When capital is abundant, the absence of bad news is read as good news, and an empty analytical artifact is read as a clean one. A pipeline returning "N/A" across all nine dimensions does not trigger an alert; it produces a report a fund manager skims, an agent ingests, and a dashboard renders green. The $100M project with no findings is not a safe project. It is a project whose findings have not been generated yet.
The next twelve months will wire autonomous agents directly into these read paths. I spent the last year at a Seoul L2 firm looking at exactly this — how agents execute multi-sig transactions against contract state with no human in the loop. An agent does not stall on an empty report the way a person does. It does not feel the pause that comes when a page is full of "N/A." It reads a well-formed artifact, extracts no signal, and executes the default branch. The default branch is almost always the permissive one.
The question I would put to anyone shipping an analysis pipeline, an oracle consumer, or an agent policy this cycle is not whether the data can be forged. It is whether the system can tell the difference between a value that is correct and a value that is merely well-formed — and, more uncomfortably, whether anyone in the organization is responsible for asking.
Because the empty block will always be valid. The question is who is counting.