Last month a pipeline I helped design returned a report. Every field was populated. Every field was empty.
Nine analytical sections. Complete tables. Consistent formatting. And in every cell where a conclusion should have lived, the same four words: insufficient information. The system had not crashed. It had not hallucinated a number, which is the failure everyone worries about now that language models write our summaries. It had done something subtler and, I think, worse. It had produced a structurally perfect artifact containing zero semantic content โ and then, with the peculiar dignity of machines, it had graded its own output one star out of five and flagged its own upstream dependency as broken.
That last part is the only reason I trust it.
I have spent ten years watching crypto infrastructure fail, and I have come to believe that this is the failure mode that matters most and gets instrumented least. Not the exploit. Not the depeg. Not the halt. The output that looks like a number.
A crash announces itself. A halt pages someone at 3 a.m. A null does not. A null arrives wearing the same clothes as an answer: same schema, same units, same type signature, same font. The liquidation bot cannot tell the difference. Neither can the risk dashboard, the governance forum, or the analyst who has ninety seconds to decide whether to sign the transaction.
The most dangerous output in this industry is not the wrong number. It is the plausible void.
The summer I learned what silence costs
In the DeFi summer of 2020 I was an undergraduate interning at a small lending-focused DAO in Copenhagen. My assignment was algorithmic stablecoins. My actual education was twelve interviews with users who had lost savings, and almost none of them lost it because a contract did something the contract was not supposed to do. The contracts performed flawlessly. That was the problem.
One of those twelve was a builder in Lisbon who had a leveraged position against an ETH/USD feed. At 03:14 on a Sunday the feed stopped updating. Not manipulated โ simply quiet. The aggregator's heartbeat lapsed, the on-chain answer sat at its last value, and every downstream check in the protocol said the same thing: the number is greater than zero, therefore the number is valid. His collateral was priced at a figure that had been true six hours earlier in a market that had moved eleven percent. He was liquidated into a gap. When he tried to explain, the response he got โ from the docs, from the forum, from the code itself โ was that the system had behaved as specified.
Code is law, until the law breaks the code.
What stayed with me was not the loss. It was the category error. The protocol had asked is this value nonzero? when the meaningful question was does this value still refer to the world? Those are different questions, and only one of them can be answered by a type check.
There is exactly one place in this entire stack where absence is rigorously defined, and it is the oldest one. A Bitcoin UTXO either exists in the set or it does not. There is no third state, no ambiguity, no stale entry. Ethereum's state root gives you something similar: a proof of non-inclusion is a real, verifiable object. The base layer is magnificent at this. It is a machine for distinguishing has happened from has not happened.
Then you climb one layer up, to the place where the chain learns about anything outside itself, and the rigor evaporates. The ledger knows perfectly what the ledger contains and nothing else. Everything above that is a translation, and every translation has a moment where a word is missing and the translator writes something anyway.
Zero is a value. Null is a claim.
Start with the language itself, because the language encodes the mistake.
In Solidity, a mapping returns zero for any key that has never been touched. There is no exception, no sentinel, no undefined. A balance of zero and an absence of balance are the same eight bytes. This is a deliberate design decision made for gas efficiency and state determinism, and it is entirely reasonable in isolation. It has also been the load-bearing assumption underneath a remarkable amount of loss.
The clearest case remains Nomad, in August 2022. During a routine upgrade, a root value was initialized to zero rather than to a valid prior root. Because the verification path treated a zero root as a legitimate comparison target, any message could be proven against it โ and once one person demonstrated the pattern publicly, hundreds copied it in a free-for-all that drained roughly $190 million in a few hours. Nobody broke cryptography. Nobody found a collision. A field that should have meant uninitialized meant everything is valid, and the system could not tell the difference because the system had never been taught that the difference exists.
I have audited enough of these to recognize the smell. When I manually walked the tokenomics of three failed 2017-era projects for an essay I titled Code as Constitution, the recurring defect was never the arithmetic. The arithmetic was fine. The defect was that the contract had no vocabulary for I do not know, so it substituted a number and moved on.
Zero is a value. Null is a claim. Most smart contracts have a type for the first and no concept of the second.
This is not a Solidity problem. It is a modeling problem, and it reproduces at every level of the stack. The database column that defaults to 0. The indexer that backfills a gap with the previous row. The dashboard that renders a flat line when the API returns 500 because flat is what an empty array plots as. The CSV export where a missing field becomes an empty string and the empty string becomes zero at the next parse.
We built the temple, but forgot who the god is. The god, in this case, is correspondence โ the relationship between a number and the thing it claims about. Everything else in the temple is scaffolding.
The oracle problem is not accuracy. It is aliveness.
Ask anyone in this industry what an oracle does and they will say it brings external data on-chain. That description is correct and useless, in the way that saying a heart's job is to make a sound would be correct and useless.
An oracle's actual job is to maintain a continuously true statement about a changing world, and to fail loudly the instant it can no longer do so. The second clause is the one that gets under-built, because it is the one that produces no revenue.
Look at how a modern feed is specified. A price update is pushed when the deviation from the last reported value exceeds a threshold, or when a heartbeat interval elapses, whichever comes first. Both parameters are engineering tradeoffs: a tight deviation threshold costs more gas and more update transactions; a loose one means the on-chain price lags reality by however much the market can move inside that band. The heartbeat exists precisely because deviation-triggered updates have a blind spot โ a market that goes quiet produces no deviation, and a feed with no updates is indistinguishable from a feed with nothing to say.
The heartbeat is an admission that no news and no signal look identical from the outside. Someone had to build a timer to force the system to keep asserting that it is still alive.
Now look at how feeds are consumed, which is where the rot lives. A large fraction of integrations do something like: read the answer, check that it is greater than zero, use it. Some check updatedAt against a staleness window. Very few check both, and fewer still propagate the failure upward in a way that anything downstream can act on. When I read a lending market's oracle adapter, the question I ask is not what happens if the price is wrong โ that scenario is well-theorized and well-parameterized. The question is what happens if the price stops. In my experience the honest answer, far too often, is: nothing. Nothing happens. The market keeps quoting.
There is one design pattern in production that I hold up as the correct instinct, and it comes from the L2 era. When Aave deployed V3 on rollups, it added an explicit sequencer uptime feed alongside the price feeds. The reasoning is precise: on an optimistic rollup, if the sequencer goes down, the chain stops, and every price on it becomes frozen at its last value. A frozen price is not a stale price in the ordinary sense โ it is a price from a chain that is no longer processing. The protocol checks the sequencer's status separately and, if the downtime exceeds a grace window, refuses to accept the price at all. It fails closed.
That is a protocol admitting, in code, that it can be told nothing and must therefore do nothing. It cost engineering time to build, it produces no yield, and it has almost certainly saved more than it cost. It is also the kind of thing that never appears in a funding announcement.
Schema-valid, semantically empty
In 2024 I spent six months trying to build a bridge between the AI people and the crypto people in Copenhagen. Three workshops, fifty participants each, and a whitepaper co-authored with four engineers โ Trusted AI on Chain โ arguing that zero-knowledge proofs could let a model demonstrate properties of its training data without exposing the data itself. A local startup picked it up for a pilot. I still think the technical thesis holds.
But the thing I actually learned came from watching the two communities misread each other.
The crypto engineers assumed the AI people were careless about verification. They are not. They are obsessive about it, in a different coordinate system: eval suites, red teams, benchmark contamination checks, held-out sets. The AI people assumed the crypto engineers were paranoid about trust. They are, but about the wrong object โ they worry about who is lying and not nearly enough about what happens when nobody is talking.
Both communities share one blind spot, and structured output made it worse. When a model is constrained to emit valid JSON against a schema, every field will be present. The schema has no slot for I could not determine this. So the model fills the slot. It does not experience this as lying; it experiences it as completing a pattern. The result passes validation, type-checks cleanly, flows into the next stage of the pipeline, and gets consumed by an agent that has been instructed to act on it.
This is the part that should worry anyone building autonomous agents in 2026. A trading agent does not need to be hacked. It needs to be fed a null that has been formatted as a zero. It will then do exactly what it was built to do, with total confidence, at machine speed, with nobody in the loop to notice that the input never referred to anything.
Formatting is not verification. A well-formed answer is evidence of a well-formed process, not of a true one.
The pipeline that returned my empty report last month did the opposite, and it did so because a human had insisted on it. Somebody โ me, in a design review, being stubborn โ had argued that the minimum analyzable set should be explicit: a title, a source, a timestamp, at least three independently verifiable facts, and at least one identifiable subject. Below that threshold, the system returns nothing and says why. It is not a sophisticated safeguard. It is a checklist. But it forced the machine to distinguish between I analyzed and found nothing and I was given nothing to analyze, and those two states produce wildly different downstream behavior.
Most of our infrastructure does not make that distinction, because making it requires admitting that the system can be empty, and admitting that requires someone to be accountable for the emptiness.
Proof of absence
The cryptographic primitive for this already exists and is underused. A Merkle proof can demonstrate non-inclusion as rigorously as inclusion. You can prove, to a verifier who trusts only a root, that a particular key is not in a particular set. Ethereum's attestation ecosystem โ the Ethereum Attestation Service and its descendants โ extends the idea: an attestation is a signed statement, and a signed statement can be a negative one. I checked this address and found no sanctions match. I queried this feed and received no update within the window. I looked for this project's audit and there is none.
Negative attestations are the missing half of the trust layer, and they are missing for a predictable reason: nobody wants to pay for them. A positive attestation โ this asset is reserved, this credential is valid, this wallet passed KYC โ has a buyer. A negative attestation has a beneficiary but no customer, because its entire value is the disaster that did not occur.
There is a second primitive worth naming here, because it is often confused with the first. Data availability sampling, the machinery around blobs and the danksharding roadmap, answers a related but distinct question: not is this statement true but is this data actually retrievable by anyone who wants to check. Availability is a precondition for verification, and for years we conflated the two. A rollup that posts a state root but withholds the underlying data has given you a valid-looking commitment to nothing. The fraud-proof window is a timer on a claim nobody can currently evaluate. That is the same disease in a different organ: a structure that is formally complete and substantively vacant.
The general lesson, and the one I keep returning to in my own work, is that verification must be able to return three values, not two. True, false, and unknown. Every system that collapses unknown into either of the other two is lying, whether or not it has been programmed to.
The circuit breaker we never built
In traditional markets, exchanges halt. It is an ugly, inelegant, human mechanism, and it works because it is willing to say we cannot price this right now. Crypto spent fifteen years treating halts as a moral failure โ an admission that the market was not infinitely liquid, that the oracle was not omniscient, that the protocol was not, in fact, autonomous.
We got the worst of both arrangements. We built systems with all the fragility of a continuous market and none of the circuit breakers, and we called the absence of breakers decentralization.
What a breaker looks like in practice is unglamorous. A minimum quorum of independent sources, where independence means different operators, different infrastructure, different failure domains โ not three wrappers around the same upstream API. A freshness requirement enforced at the consumption site rather than assumed at the production site. A refusal to accept any input whose provenance cannot be traced to a signed, timestamped origin. A hard stop when the quorum is not met, rather than a fallback to the last known value, because the last known value is precisely the thing that is most likely to be wrong at the moment it matters.
I have watched teams argue against every one of these on the grounds that they reduce uptime. They do. That is the point. A system that is always available is a system that has decided, in advance, that it will never admit ignorance โ and a system that cannot admit ignorance will eventually assert something false with the full weight of its architecture behind it.
We traded soul for speed, and called it progress.
Who answers for silence?
The accountability question is where this stops being an engineering essay and becomes something closer to a legal one, and it is genuinely unresolved.
Consider the asymmetry. A developer whose code produces a harmful output faces, increasingly, the full weight of state power. The Tornado Cash designations in 2022 established a precedent that has been metastasizing ever since: that publishing and maintaining neutral, open-source software can be treated as conduct, and that the person who wrote the contract is the person responsible for every downstream use of it. The precedent is dangerous precisely because it is indiscriminate. It does not ask whether the developer intended the outcome, controlled the outcome, or could have prevented the outcome. It asks only whether the code existed and whether the code was used.
Now flip it. A developer whose code correctly refuses to act โ whose oracle adapter halts a market because the feed went stale, whose pipeline returns insufficient information instead of a fabricated number โ receives no protection, no credit, and no revenue. The good refusal and the bad silence are legally indistinguishable, and both are commercially invisible.
That asymmetry is a design pressure, and it pushes in exactly one direction. Rational developers build systems that always answer, because systems that always answer are the ones that get integrated, funded, and defended. Systems that sometimes decline are the ones that get replaced by a competitor who promises 99.99% uptime and quietly means 99.99% of queries return something.
If we want infrastructure that can say no, we have to make saying no a defensible act โ technically, commercially, and legally. Right now it is none of the three.
The redundancy delusion
The reflexive answer to everything in the previous sections is add more sources. Three oracles instead of one. Two RPC providers. Four indexers. A median instead of a mean. It sounds like rigor. It is usually theater.
Redundancy without diversity is correlation wearing a costume. Three feeds that all derive from the same exchange's API, all hosted in the same region, all updated by the same class of bot, will not disagree with each other. They will agree โ and their agreement will be wrong in the same direction at the same moment. The median of three identical errors is the error, computed with more confidence and reported with a tighter confidence interval.
The deeper problem is what redundancy does to the failure mode. A single feed that goes quiet is at least visible as quiet. A quorum of three feeds that all go quiet produces consensus. The aggregator sees three matching values, achieves quorum, and publishes. Nobody downstream learns that the input was three copies of the same silence.
This is where the industry's instinct inverts the actual risk. We spend enormous effort on Byzantine fault tolerance โ on the assumption that participants will actively lie โ and comparatively little on the assumption that participants will simply stop, or that they will all be reading from the same broken instrument. Honest failure is not covered by a model designed for dishonest actors. BFT gives you agreement. It does not give you correspondence, and it never claimed to.
The same pathology shows up in audit culture, which is the part of this industry I have the most personal exposure to. I have read audits with forty pages of methodology, a complete findings table, severity ratings from critical to informational, and a conclusion that amounts to we looked carefully. Every section filled. Nothing said. And it passes, because the deliverable is the document and the document is complete.
Authenticity is a signal lost in the noise. So is its absence.
What we would have to fund
There is a reason the staleness check, the sequencer uptime feed, the negative attestation, and the null-input circuit breaker all remain rare, and it is not that they are hard to build. They are trivially hard to build. They are hard to fund, because they are maintenance, and maintenance is the most systematically underfunded category of public good in this ecosystem.
I have been a consistent defender of Optimism's RetroPGF as the only public goods mechanism I have seen that actually works, and this is exactly why. Retroactive funding does not require a grant committee to predict which maintenance work will matter. It pays for demonstrated impact after the fact. A team that shipped a staleness guard which prevented a cascade during a volatile week has produced a measurable outcome, even though the outcome is a non-event.
But even RetroPGF struggles with the invisible case, because the evidence of a prevented failure is an absence, and absences are hard to point at in a funding round. The applicant writes we prevented something and the badgeholder reads we did nothing observable. The projects that win are the ones with a dashboard, a launch, a growth curve. The ones that keep the dashboard honest do not have a growth curve, because their entire job is to make sure the graph never has to be redrawn.
If I could change one thing about how this industry allocates capital, it would be to treat the check that did not fire as a deliverable. Log the refusals. Publish the count of times the market halted because the quorum failed. Make the negative attestation a first-class artifact with a hash and a timestamp and a place in the governance record. You cannot fund what you cannot see, and right now the most valuable work in the stack is invisible by construction.
The next primitive is a credible no
Everything above converges on one design principle, and I want to state it as plainly as I can, because I think it will define the next several years of infrastructure work.
The scarce resource is not data. Data is abundant, cheap, and increasingly synthetic. The scarce resource is credible refusal โ a signed, verifiable, auditable statement that a system looked and could not determine, and that this fact is itself a fact others can rely on.
A lending market that halts is more trustworthy than one that liquidates against a frozen price, because the halt is legible. A pipeline that returns an empty report is more trustworthy than one that returns a plausible one, because the emptiness can be traced to its cause. An agent that declines to trade is more trustworthy than one that trades on a stale feed, because the decline leaves a record.
Faith in the protocol is not faith in the people. But faith in a protocol that cannot say I do not know is not faith at all โ it is a bet that the world will never present the protocol with a question it cannot answer. That is a bet every one of us has already lost, at least once, at three in the morning, watching a number that looked exactly like a number.
The ledger remembers, but the heart forgets. What we need now is infrastructure that remembers its own silences, and treats them as the most important thing it has to report.
