The pipeline returned empty.
Not zero. Not null. Not a revert. Empty. Six fields in, six fields out, and every one of them read N/A. For a data analyst, that is an annoyance โ a throttled API, a broken connector, a Tuesday. For an on-chain consumer, it is an existential ambiguity. If a feed returns nothing, you cannot distinguish it from a feed that lies. And the blockchain, by design, cannot tell you which one you are reading.
I spent the past week auditing a small oracle integration for a mid-sized protocol. The integration had passed its unit tests. It had passed staging. It had, according to the team's status page, 99.98% uptime. What the status page did not show was that the feed had been returning a stale cached value โ not empty, not wrong, just old โ for the better part of two days. Consumers downstream never noticed. Positions settled. Liquidations fired. Everything worked.
This is the verifiability gap. It is the distance between a system that returns an answer and a system that can prove the answer is the one it should have returned. In a sideways market, when everyone is waiting for direction and nobody is paying for infrastructure, that gap widens quietly. The verifiability gap is not a security bug. It is a pricing bug: the market pays for throughput and assumes correctness for free.
Before the context, one constraint, stated up front. Everything below is anchored to a mechanism I can trace in code or in a proof system. Where I cannot trace it, I say so. That is the entire argument.
What Available Actually Means
The modular thesis was sold as a decomposition. Execution, settlement, consensus, and data availability, each pulled apart and optimized in isolation. Rollups would compress execution. A shared settlement layer would resolve disputes. And a data availability layer โ Celestia, EigenDA, the Ethereum blob market, Avail โ would guarantee that the transaction data behind every rollup block was actually published, retrievable, and reconstructable.
That last guarantee is the one everyone leans on and almost nobody audits.
Here is the mechanical problem. A rollup posts a batch of transactions to a DA layer. The sequencer posts a commitment โ a Merkle root, a KZG commitment โ and then, in theory, the data behind it. A light node does not download the data. It samples a handful of random chunks. If the chunks resolve, the node assumes the whole block is available. This is Data Availability Sampling, DAS. The mathematical claim underneath it is elegant: if a block producer withholds even a small fraction of the data, a random sample of a small number of chunks will fail with overwhelming probability.
I believe that math. I have re-derived it. Zero-knowledge isn't mathematics wearing a mask; it is mathematics with the mask removed, and you are forced to look at the face. The same is true of erasure-coding arguments. They hold.
What they do not hold is the layer above. The proof guarantees availability conditional on the sampler behaving correctly, conditional on the network of samplers being honest and independent, conditional on the sampling transport actually reaching a peer that holds the data. None of those conditions is a cryptographic fact. All of them are operational facts. And operational facts are exactly the ones that failed in my audit this week.
To see why, you have to separate three things that the industry routinely conflates: data availability, data integrity, and data provenance. Availability means the bytes exist somewhere retrievable. Integrity means the bytes match the commitment. Provenance means the bytes came from the source you think they came from. DAS addresses the first. Merkle and KZG proofs address the second. Almost nothing in production addresses the third โ and provenance is where every silent failure I have ever found actually lives.
The Sampling Illusion
The Celestia design is the cleanest example of the trade-off I want to make explicit. I led the analysis of its DAS mechanism in 2024, and I spent weeks on the proof that a node only needs to sample a small subset of blobs to guarantee availability. The result is that a light node with a laptop and a home connection can, in principle, hold a full node's worth of security. That is a genuine achievement. It collapses the cost of verification from bandwidth to randomness.
But the achievement is stated as a theoretical maximum. The practical constraint is the transport. Sampling is not a mathematical operation that runs in a vacuum; it runs over gRPC, over libp2p, over whatever request-response protocol the implementation chose. And request-response protocols have latency, retries, and failure modes that the proof never modeled.
Here is the anomaly I found. Under load, the sampler issues requests for random chunks across many peers. If a subset of those requests times out โ not fails, times out โ the sampler has two choices. It can treat the timeout as unavailability and reject the block. Or it can treat the timeout as a transport hiccup and retry. The first choice is safe but produces false negatives: honest blocks get rejected because a peer was slow, which erodes liveness. The second choice is live but produces a subtle hole: an attacker who can selectively delay requests can convert a withholding attack into an apparent transport problem, and the sampler retries until it eventually resolves the chunks it is allowed to resolve.
The theoretical guarantee assumes the adversary controls data, not latency. In practice, the adversary can rent latency. You do not need to withhold a whole block; you need to be the fastest responder for the chunks you are willing to serve and the slowest for the chunks you are not. The proof was sound. The deployment was not. Code is law, but bugs are reality.
I proposed an optimization based on Reed-Solomon erasure coding โ encode the blob so that any fraction of chunks reconstructs the whole, then sample against the reconstruction threshold rather than the chunk set. It does not remove the latency adversary. It changes the cost curve so that the adversary has to delay more requests to achieve the same withholding effect, which raises the attack's resource requirement from trivial to expensive. It was adopted in discussion. It was not adopted in code, because the team had a roadmap, and the roadmap had a launch date, and the launch date had a marketing budget attached.
The Latency Nobody Models
I want to dwell on the latency point, because it generalizes far beyond Celestia.
Every DA proof I have read treats the network as a reliable channel with bounded delay. Real networks are not that. They are adversarial queues. And the difference between a proof and a deployment is almost always a queue.
Consider the failure mode concretely. A rollup sequencer posts a batch at height N. The DA layer accepts the commitment. The blob is propagated. A light node samples at height N and the samples resolve. The node marks the block available. Now the node samples at height N+1, and one peer has dropped the blob. The node does not re-sample N. Why would it? N was resolved. The node moves on. Two days later, the sequencer's archive node has pruned the blob, the honest full nodes have garbage-collected it, and the only copies left are held by whoever chose to keep them. If that set is empty, the rollup's history is gone, and the state root it committed to is now unverifiable in practice.
This is not a cryptographic break. It is a garbage collection policy. But the consequence is the same as a break: the chain cannot be reconstructed, and reconstruction is the only thing that makes a rollup a rollup rather than a trusted database.
The retry-versus-reject dilemma, the latency adversary, the retention horizon โ none of these appear in the whitepapers because none of them are mathematical. They are systems engineering. And the industry has spent four years optimizing the math while the engineering accrued technical debt that is now coming due in a sideways market where the fee revenue that used to subsidize redundancy has thinned.
This is where I part company with the maximalist reading of the modular thesis. Modularity does not eliminate trust. It relocates it. You move trust from the consensus layer to the transport layer, from the block producer to the peer set, from the proof to the deployment. Every relocation is a trade, and most teams never write the trade down. The trade-off matrix is the document that does not exist, and its absence is why nobody prices the risk.
The Input Problem
The DA discussion is about data leaving the chain. The oracle discussion is about data entering it. Both are verifiability problems. The oracle one is worse.
A price oracle is a claim about the external world. The chain cannot check the claim. It can only check that the claim was signed by a key it trusts. Everything about whether the price is right โ whether the exchange is real, whether the volume is wash-traded, whether the market is manipulated at the exact block the read executes โ is outside the chain's reach.
I have audited this class of system for years, and the pattern never changes. The output is verified. The input is assumed. A median of five reported prices is computed, and the median is treated as truth. But the median of five inputs is only as good as the provenance of those five inputs, and provenance is exactly what the oracle cannot prove.
Here is the concrete shape of the failure. Five feeds report a price. Four of them are honest and one is stale. The stale feed is not malicious; it just has not updated because its source exchange is throttling it. The median is now pulled toward the stale value. The deviation is small โ under a basis point. Nothing triggers. No circuit breaker fires. Over a thousand blocks, the small deviation compounds into a systematic mispricing, and someone with a fast read and a slow counterparty arbitrages the gap.
This is not a hack. It is a leak. And leaks do not show up in an incident report, because there is no incident. There is just a slow transfer of value from the people who trust the number to the people who know how the number was built.
An empty feed and a lying feed are indistinguishable to the consumer, and a stale feed is the most dangerous of the three because it passes every sanity check. A zero is obviously wrong. An empty return triggers a revert. A stale value looks exactly like a fresh one, because it is formatted identically and signed identically. The only thing that distinguishes them is a timestamp that most consumers never read.
Sidebar: Polynomial Commitments and the Cost of Proof
A short detour, because the cost of verification is the reason all of this is underprovisioned.
A KZG commitment binds a polynomial to a single group element. To open it at a point, the prover computes a quotient polynomial and a pairing. The verifier does two pairings and a hash-to-curve mapping. That is the whole trick. It is compact โ one group element to commit, one to prove โ and it is cheap to verify, which is why every modern DA scheme and every modern zk-rollup uses it.
The catch is the trusted setup. A KZG commitment is only binding if the toxic waste from the ceremony was destroyed. If a single participant retained it, they can forge openings โ prove a value that is not in the committed polynomial. I built a minimal Rust implementation of a Groth16 prover to understand the overhead of the pairings, and the thing that stayed with me was not the arithmetic. It was the ceremony.
A trusted setup is a cryptographic assumption that is socially constructed. The math is perfect. The assumption is a claim about the behavior of a set of strangers who ran a multi-party computation and then claimed to have deleted a file. The security of billions of dollars rests on that claim. It is, in the precise sense, a social consensus masquerading as a mathematical one.
This is why I am skeptical of the framing that proofs remove trust. Proofs relocate trust, again, from the runtime to the ceremony. That is often a good trade. It is not a free one.
The Non-Determinism Wall
Now the 2026 problem, which is the reason this article exists.
As AI and crypto converged, I investigated whether large language models could generate deterministic smart contract code, and I audited a new oracle network that claimed to feed AI-generated predictions on-chain. The pitch was straightforward: an LLM ingests market data, emits a directional call, and the call settles on-chain. The network called it an AI oracle. The market called it an AI coin. The distinction mattered to nobody with a marketing budget.
The technical problem is not subtle, and it is not fixable by better prompting. A blockchain requires deterministic execution. Every node must arrive at the same state given the same inputs. A neural network is a function of its weights, its activations, its temperature, its sampling seed, and its floating-point environment. Change any one of those and you get a different output. Change the hardware and you can get a different output for the same weights, because floating-point non-associativity is real and GPU kernels are not bit-reproducible across vendors.
So the network did what every system does when it cannot verify a computation: it introduced a trusted third party. A designated node ran the model off-chain, signed the output, and the chain accepted the signature. The AI oracle was an API call with extra steps. The intelligence was off-chain. The verification was a signature. The consensus layer had learned nothing.
The claim was AI plus crypto. The reality was a multisig wearing a neural network as a hat. And I want to be precise about why this is not merely disappointing but structurally wrong. A prediction oracle that cannot be verified is not an oracle. It is an opinion. The chain does not consume the model's reasoning. It consumes a signature, and a signature proves authorship, not correctness.
For true convergence, you need a new consensus layer for probabilistic verification โ a way for the network to agree not on the exact output of a non-deterministic function, but on whether an output falls within an accepted distribution. That is a genuinely hard problem. It is not an integration problem. It is a consensus-design problem, and the teams shipping AI oracles in 2026 have, almost without exception, chosen to solve the marketing problem instead.
This is why I now run every AI-integration claim through the same test: show me an auditable path from input to on-chain output. Not the model. Not the weights. The path. If the path terminates at a signature, the system is a trusted signer, and it should be priced as one.
The Trade-off Matrix
Here is the matrix I promised, the one that does not exist in the decks. Four verification strategies, scored on the axes that actually decide whether a system survives a sideways market.
Full node verification is the baseline. Maximum security, maximum cost. Every consumer downloads and validates everything. It does not scale and it never will. It is the reference point, not the product.
Light-client verification with fraud proofs is the optimistic path. Cheap to run, cheap to verify, and secure only if someone is watching. The cost is social, not computational: you need honest watchers with an economic incentive to run them. In a bull market, watchers are funded by fees. In a bear market, they are funded by conviction, and conviction is not a security budget.
Data availability sampling is the sampling path. It collapses verification cost from bandwidth to randomness, and it inherits the transport-layer assumptions I described above. It is the best available trade for scale. It is not a proof of provenance.
Trusted-signer oracles โ including every AI oracle currently in production โ are the cheap path. They are cheap because they verify nothing. The cost is deferred, not eliminated, and it lands on whoever is holding the position when the signer is wrong or slow or gone.
The matrix says one thing. Every step down in verification cost is a step up in assumption surface, and the market currently pays for the cheap path while believing it bought the expensive one. That is the mispricing. It is not that people choose trusted signers; that is a legitimate engineering choice under constraints. It is that they choose trusted signers and then describe the system as trustless, which means the risk is unpriced and therefore unbounded.
I have watched this pattern for fourteen years. It shows up in DeFi composability first. When I analyzed the interaction between Lido's stETH and Aave's lending protocol in 2021, the discovery was not a bug in either protocol. It was that Lido's node operators held an effective censorship vector over stETH transfers, which violated the permissionless assumption that Aave's risk model had silently inherited. Aave was pricing stETH as if it were ETH. The matrix said otherwise. The matrix always says otherwise.
The Blind Spot
Here is the contrarian angle, and it is uncomfortable.
The entire industry is optimizing output verification. ZK-rollups prove the state transition. DAS proves the data exists. Fraud proofs prove the batch is honest. Proof markets prove the proof was computed. Every dollar of research is going into proving that what the machine produced is correct.
Almost nobody is funding input verification. Proving that what the machine was fed is real.
This is the blind spot because it is structurally invisible. An output proof has a clean object to verify: a state root, a computation trace. An input has no such object. The input is a claim about the world, and the world does not produce Merkle roots. So the industry verifies the part it can formalize and quietly assumes the part it cannot, and then calls the whole system trustless because the formalizable half is trustless.
Consider what this means for the RWA narrative that has dominated the last three years of storytelling. The pitch is that real-world assets come on-chain and inherit the composability of DeFi. But an on-chain RWA is a token whose value depends entirely on an off-chain legal claim about an off-chain asset, verified by an off-chain custodian, reported by an off-chain feed. The on-chain part โ the token, the transfer, the collateralization โ is the part that is verifiable and therefore the part that is least likely to fail. The off-chain part is the part that determines whether the token is worth anything, and it is the part that is unverifiable by construction.
This is why the RWA story has been a three-year exercise in narrative rather than settlement. The institutions that would bring real assets on-chain do not need a public chain to move a legal claim from one balance sheet to another. They have custodians, transfer agents, and decades of settlement infrastructure that handles exactly this. What they need, and what a public chain cannot give them, is a verifiable bridge between the legal claim and the token. That bridge does not exist in a cryptographic sense. It exists as a signature from a custodian, which is to say it exists as a trusted signer, which is to say the RWA token is an oracle wearing a security as a hat.
The same logic runs through the Layer 2 debate. The real difference between the OP Stack and the ZK Stack is not the proof system. It is who can convince more projects to deploy a chain first. The OP Stack won the distribution war with a simpler, cheaper, more composable model and a shared sequencer roadmap that trades some trustlessness for liquidity. The ZK Stack won the ideological war with a proof system that is more expensive to generate and more honest to verify. Both are correct. Neither is decisive. The decisive variable is the deployment count, and the deployment count is a business metric, not a cryptographic one. The proof system is the moat only in the whitepaper. In the market, the moat is the integration surface.
The Forecast
So where does this go?
The verifiability gap will be repriced, and the repricing will not come from a hack. Hacks are loud and get patched. It will come from a slow realization, during a sideways market, that a large fraction of on-chain systems are consuming data whose provenance they cannot check, and that the redundancy which used to paper over the gap has been defunded by thin fee revenue.
I expect three things to matter over the next cycle.
First, provenance proofs will move from research to production. The primitive exists โ attestation frameworks, verifiable credentials, signed data pipelines โ and the demand is arriving because the cheap paths are failing quietly. The teams that ship provenance will not be the ones with the best model. They will be the ones who wrote down their assumptions.
Second, the retention problem will become a first-class design constraint. Reconstruction is the whole point of a rollup, and reconstruction requires that someone keeps the data. Economic design that pays for retention will look obvious in hindsight and will be painful to retrofit, because it changes the fee model, and the fee model is the thing nobody wants to touch in a bear market.
Third, the AI-oracle wave will bifurcate. The integration-shaped projects โ API calls with signatures โ will be repriced as trusted signers and will lose their narrative premium. The consensus-shaped projects โ probabilistic verification, distribution agreement, verifiable inference โ will remain hard and will remain small, because hard things stay small until they do not.
Here is the question I keep coming back to, and it is the one I would ask every team building in this space. If your system returns nothing, can you tell? If your feed goes stale, does anything fire? If your proof is sound but your transport is not, which one is your user actually trusting? Because I have audited enough of these systems to know that the answer, in most cases, is that nobody knows, nobody checks, and the failure is not that the machine lies. The failure is that the machine can be silent and the market calls it availability.
An empty feed is not a neutral fact. It is a claim. And in a market that pays for throughput and assumes correctness for free, the claim is the most underpriced asset in the stack.