Last week I watched a production data pipeline fail. Not crash. Fail. The distinction matters. A crash is loud — the process dies, the alert fires, an on-call engineer gets paged at three in the morning. This pipeline did the opposite. It ran to completion. Every stage reported success. The schema validated. The HTTP layer returned 200. And every single field in the output document came back as N/A.
No title. No source. No information points. No core thesis. A nine-dimensional analytical framework, populated end to end with placeholders.
If you have spent any time inside Solidity, you already recognize the shape. This is the external call that returns (true, "") — the transaction succeeded, the gas was spent, the state was written, and the value you were waiting for never arrived. The EVM does not consider this an error. Neither did the pipeline. That is precisely the problem.
I do not treat empty output as a bug in the analysis layer. I treat it as a soundness property. The pipeline that refuses to fabricate is more trustworthy than the pipeline that invents. But the industry has not internalized this. We have constructed an entire infrastructure — oracles, indexers, subgraphs, LLM research agents — optimized to always return something. Never nothing. And "always returns something" is not a design goal. It is an attack surface.
Context: fail-open versus fail-closed
Let me define the terms before I go further, because this industry is sloppy about them.
A fail-open system continues operating when a component fails. It returns a default value, a stale value, or a cached value. The caller cannot tell that anything went wrong. DNS resolvers that hand back the last-known-good IP are fail-open. Most oracle networks are fail-open: when a price feed goes stale, they keep serving the last price until a heartbeat threshold trips.
A fail-closed system halts or returns an explicit null when a component fails. The caller must handle the absence. Firewall rule sets are fail-closed. A cryptographic verifier is fail-closed: if the proof does not verify, the answer is not "maybe," it is false.
The pipeline I described is, by design, fail-closed. When the upstream text failed to ingest, when the parser threw, when the deconstruction stage produced no extractable information points, the correct output was null. The pipeline did not hallucinate a title. It did not invent a thesis from market context. It returned absence.
Now place that behavior next to the rest of the stack. A price oracle with a two-billion-dollar TVL dependency, sized for a 0.5% deviation threshold and a 3600-second heartbeat. When the primary data source goes down, what does the aggregator return? In the good implementations, the deviation threshold trips and the feed halts. In the bad ones, the aggregator averages the remaining — possibly manipulated — sources and publishes a number that looks clean. The consuming contract has no way to distinguish a fresh price from a poisoned one. Same shape, different stakes.
The industry has spent a decade hardening the on-chain layer — reentrancy guards, invariant checks, formal verification of bytecode — while leaving the off-chain data layer almost entirely unguarded. Indexers return partial data with no completeness proof. RPC providers silently load-balance across nodes that may be at different heights. Subgraph results carry no freshness attestation. And the newest layer, the LLM-based research agent, returns confident prose regardless of whether the underlying input existed.
The empty output is the alarm. The industry treats it as a malfunction. That reflex is the vulnerability.
The taxonomy of empty
Engineers collapse many distinct states into the word "empty." This is the first mistake. In JavaScript alone: null is a value explicitly set to represent absence; undefined is a variable never assigned; "" is a legitimate string of length zero; 0 is a legitimate number; false is a legitimate boolean; [] is a valid array with no elements; NaN is the result of undefined arithmetic.
These are not interchangeable. null == 0 is false in JavaScript, but null >= 0 is true. The coercion rules are a security liability precisely because they let a downstream consumer treat "no value" as "the value zero."
In Solidity the taxonomy is different but the hazard is identical. address(0) is the null address; sending ETH there burns it; it is used as a sentinel for "unset." bytes32(0) is the zero hash — simultaneously a valid hash value and the conventional sentinel for "no hash." 0x is empty bytes, distinct from 0x00 (one zero byte) and from bytes32(0) (thirty-two zero bytes). 0 for uint256 is a valid amount.
The dangerous ambiguity is that address(0) and bytes32(0) are at once "the absence of a value" and "a value." A contract that uses address(0) as a null sentinel cannot distinguish "user has not set a recipient" from "user set the recipient to the burn address." Historically this has burned funds. The fix is not to eliminate the sentinel but to make the type system carry the distinction — a pattern Rust enforces with Option and that Solidity does not enforce at all.
I ran into a cousin of this problem during a six-week dissection of the Gnosis Safe source in late 2018. I compiled the Solidity v0.4.24 contracts on a local testnet and found three signature malleability issues that early auditors had missed. Signature malleability is the same category error in a different costume: a single logical authorization that has two distinct valid encodings. The verifier sees a valid signature. The replay protection sees a different one. The absence of canonicalization — the empty space where a constraint should have been — was the vulnerability. Empty and valid are the same thing to a check that was never written.
Every one of these states is a candidate for the pipeline's N/A. And every downstream consumer that coerces N/A into a default is the exploit.
ERC-20 and the empty return
This is where the abstraction becomes gas-priced.
The ERC-20 standard states that transfer and transferFrom SHOULD return a boolean indicating success. SHOULD, not MUST. The consequence is a class of tokens that return nothing at all. USDT on Ethereum was the canonical example for years; the Tether contract's transfer returns no data.
Solidity's low-level call returns two values:
(bool success, bytes memory data) = token.call(
abi.encodeWithSelector(token.transfer.selector, to, amount)
);For a standard token, data decodes to a bool. For a non-standard token, data is 0x — length zero. For a token that returns false without reverting, data decodes to false while success is true.
Now look at the naive integration:
require(success, "transfer failed");This passes in all three cases. A non-standard token "succeeds" without any confirmation. A token that returned false — a legitimate failure signal — is treated as success, and the calling contract updates its internal accounting as if the funds moved.
OpenZeppelin's SafeERC20 exists to close this gap:
function _callOptionalReturn(IERC20 token, bytes memory data) private {
bytes memory returndata = address(token).functionCall(
data, "SafeERC20: low-level call failed"
);
if (returndata.length > 0) {
require(
abi.decode(returndata, (bool)),
"SafeERC20: ERC20 operation did not succeed"
);
}
}Read the if carefully. When returndata.length == 0, SafeERC20 treats the call as successful. It does not require a boolean. It only checks the decoded value when return data exists. This is a deliberate compatibility choice: it lets the library support non-standard tokens. But it also means a token contract that returns nothing — or a token address that is, in fact, an externally owned account with no code — slips through unless the caller separately checks token.code.length > 0.
The empty return is not an edge case. It is a fork in the logic that thousands of integrations handle incorrectly. I have found this pattern in audit after audit: the integrator writes require(success) and believes they have verified the transfer. They have verified that a call did not revert. That is a different claim.
A call that returns nothing and a call that returns "everything is fine" are indistinguishable to code that only checks the first boolean. That is the on-chain version of the pipeline returning N/A while the downstream stage reads it as OK.
Merkle trees and the empty root
Move up a layer. Consider the Merkle tree — the workhorse behind Ethereum's state trie, rollup state commitments, airdrop allowlists, and light-client proofs.
An empty Merkle tree has a well-defined root. For Ethereum's trie, the empty root is keccak256(RLP("")), which equals keccak256(0x80), which is 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421.
That 32-byte constant is a valid root. It is the root of no data. And it is the same root for an empty set regardless of whether the emptiness is legitimate — a fresh account with no storage — or adversarial — an attacker who has stripped the data.
The vulnerability shows up in sparse Merkle trees, used by rollups, airdrop contracts, and zero-knowledge circuits. A sparse tree of depth d has 2^d leaves, most of them zero. The empty-subtree hashes are precomputed and reused. The verifier, to prove membership of a leaf, walks from the leaf to the root, hashing in sibling nodes. If the tree is empty and the prover supplies a path of all-zero siblings, the computed root is the empty root — and if the verifier accepts the empty root as a valid commitment, it accepts a proof of membership for a leaf that belongs to no one.
The history of airdrop contracts is littered with variants of this: a verifier that forgot to check the root was non-zero at initialization, or a claim function that never checked amount > 0, allowing a caller to claim zero tokens while still touching state — a griefing vector, or worse if the claim also mutated a counter.
The structural lesson is the same one running through this entire article. The empty value must be a distinct type from the valid value. When 0x0 and 0x56e81f... are both "roots," and the zero root is accepted, you have collapsed the two. The system cannot tell "no one is in the set" from "the set is undefined." That is the same category error as null coerced into 0.
Zero-knowledge proofs and the trivial instance
Now the layer I live in.
Zero knowledge isn't magic; it's math you can verify. A proof system has two properties that matter here: completeness — a true statement can be proven — and soundness — a false statement cannot. Empty output lives in the space between them.
Consider what "empty" means for a proof. There are three distinct cases. First, a proof for an empty public input vector. The circuit takes no public inputs. The prover still produces a proof, and it verifies. This is legitimate if the statement is genuinely parameterless — but it becomes the empty-root problem again if the verifier expects inputs and none are supplied. Second, a trivial proof. For some circuits, the proof that satisfies the relation for a specific witness is trivial to compute — for instance, if the constraint system has a free variable that is never constrained. This is a circuit bug, not a proof-system bug, but it is the ZK analogue of the empty return: the verifier reports "valid" and the statement was never checked. Third, a proof of a vacuous statement. "For all x in the empty set, P(x)" is true. Circuits that quantify over empty domains verify anything.
The Fiat–Shamir transform adds a fourth case. If the challenge is derived from a transcript that does not include all public inputs — the Frozen Heart class of vulnerabilities disclosed against multiple proof systems — an attacker can produce a valid proof for a statement the verifier did not intend to accept.
In every one of these cases, the verifier returns true. The system reports success. The information content of the output is zero. A verifier that accepts an empty instance is a verifier that has stopped verifying. The empty output is the soundness violation wearing the costume of a passing check.
This is why modern circuits include range checks, non-zero checks, and explicit constraint counts. It is also why, during the three months I spent compiling and testing ZK-SNARK circuits on local hardware after the Terra collapse in 2022, I stopped trusting any verification result that did not come with a non-vacuity witness. I produced a comparative analysis of SNARKs versus STARKs at the time, focused on the trade-off between succinctness and post-quantum security. The lesson underneath the comparison was simpler: the security lives in the constraints, not in the proofs. A proof is only as meaningful as the relation it constrains, and an unconstrained relation is an empty return in algebraic clothing.
The AMM invariant as a completeness check
I spent a chunk of 2020 tracing Uniswap V2's swap function at the opcode level, specifically the integer-overflow guards and the fee distribution logic. The constant-product model hides its truth in the invariant: after every swap, x * y must be greater than or equal to the pre-swap k, with >= rather than == accounting for accumulated fees. That single comparison is the AMM's completeness check. It is the thing that separates a valid state transition from a fabricated one.
Contrast that with a data pipeline. Where is the invariant? Where is the k_after >= k_before that certifies the output was derived from the input and not from the model's priors?
There isn't one. That is the gap. A ZK proof has a verifier. An AMM has an invariant. A Merkle accumulator has a root. An ERC-20 transfer should have a return value, but a lot of the time it does not. And a research pipeline has no schema gate at all, so when the input is empty, the output is empty, and the empty output flows downstream as if it were data.
The absence of an invariant is not a neutral state. It is a fail-open condition.
Simulating the propagation
Let me make the failure legible with a small model. I simulate a five-stage pipeline — ingest, parse, deconstruct, map, analyze — each with a probability of returning a valid artifact or a null. I inject a null at each starting stage and observe how far it propagates before something catches it.
import randomSTAGES = ["ingest", "parse", "deconstruct", "map", "analyze"]
# Probability a stage HALLUCINATES rather than returns null, # given a null input. This is the fail-open coefficient. HALLUCINATION_RATE = { "ingest": 0.00, "parse": 0.05, "deconstruct": 0.35, "map": 0.60, "analyze": 0.85, }
def run_pipeline(inject_null_at="ingest", trials=100_000): fabricated = 0 for _ in range(trials): value = "DATA" nulled = False for stage in STAGES: if stage == inject_null_at: value = None nulled = True if nulled: if random.random() < HALLUCINATION_RATE[stage]: value = "FABRICATED" # fail-open else: value = None # fail-closed else: value = "DATA" if value == "FABRICATED": fabricated += 1 return fabricated / trials
for stage in STAGES: print(stage, round(run_pipeline(stage), 4)) ```
The result is not subtle. A null injected at ingest survives to the analysis stage only if every downstream stage independently chooses to fail closed. With the rates above, the probability that no stage hallucinates is 0.95 0 0.40 * 0.15, which is roughly 0.037. In other words, about 96% of null inputs are converted into confident, fabricated output by the time they reach the analyst.
The simulation is a toy. The coefficients are illustrative, not measured. But the structural conclusion is robust to the exact numbers: fail-open stages compose multiplicatively, and a chain of them is almost certain to launder an absence into a presence.
Now invert the design. Make every stage fail closed. Any stage that receives a null returns a null. The probability of fabrication drops to zero, and the cost is that legitimate edge cases — an input that is genuinely empty but valid — are also rejected. That trade-off is the entire game. In an analysis pipeline where the cost of a false positive, a fabricated thesis driving a trade, dwarfs the cost of a false negative, a missed story, the correct setting is unambiguous.
The AMM model hides its truth in the invariant. The pipeline hides its truth in the schema. If the schema admits null and the downstream consumer coerces it, you have built a machine that generates plausible noise at scale.
Where the industry's numbers live
A short detour, because it connects to a claim I have made repeatedly.
The industry loves dashboards that never return empty. TVL is the canonical example. The thesis that capital is scattered across too many chains and pools and must be aggregated by a new product — let me be direct about my reading: the fragmentation is real, but the claim that it needs a new aggregator to solve it is a sales pitch. What the aggregator actually does is call the same RPC endpoints everyone else calls, return the same numbers, and wrap the empty-output case in a loading spinner. When the endpoint returns nothing, the dashboard shows the last value.
Layer 2 data availability is the same pattern. The DA layer is overhyped. The overwhelming majority of rollups do not generate enough data per block to saturate even a cheap calldata posting strategy, let alone require dedicated DA. The "DA problem" is constructed to justify a product. And when the DA provider returns an empty blob — because the batch was empty, or the sequencer stalled — the rollup's state commitment quietly carries forward.
None of this is fraud. It is fail-open design at the infrastructure layer, sold as redundancy. The number that is never missing is the number nobody is checking.
The stablecoin payment rail
There is a second place where null output has a body count, and it is not in DeFi. It is in remittance corridors.
The narrative around crypto payments in developing countries is usually told as ideology: censorship resistance, financial sovereignty, the unbanked. The reality I have seen in the data is more mundane. The driver is local currency inflation forcing people into survival alternatives. When the Argentine peso or the Nigerian naira or the Turkish lira loses value at a rate that makes holding it irrational, a dollar-denominated instrument becomes a practical necessity. The blockchain is incidental. What matters is that the instrument preserves value and settles in minutes.
That settlement depends on data pipelines. An on-ramp quotes a rate. The rate comes from an oracle. The oracle aggregates exchange feeds. When one feed returns null — the exchange API times out, the region is rate-limited, the market is closed — the aggregator does one of two things: halt, or average the survivors.
If it averages the survivors, and two of five sources are down, the published rate is computed from three quotes with no weight adjustment, no freshness attestation, and no disclosure. A user on the other end receives the rate and executes. The null was laundered into a number. The magnitude is smaller than an oracle manipulation attack against a lending protocol, but the frequency is higher and the victims are less sophisticated.
The fix is boring: freshness windows, source-count minimums, and an explicit N/A when the quorum is not met. The boring fix is the one that gets traded away for uptime.
RPC providers, indexers, and the height problem
The same failure mode appears one layer down, in the infrastructure that reads the chain.
An RPC provider is, in almost every production deployment, a load balancer over a pool of nodes. Those nodes are not guaranteed to be at the same block height. Query the same eth_getBalance twice in quick succession and you may be served by a node that is three blocks behind. The response carries no height attestation in the standard JSON-RPC schema. Your application sees a number. The number is stale.
This is fail-open at the transport layer. The correct design would attach a block height and a node identity to every response and let the consumer pin. Some providers do this with non-standard extensions. Most do not.
Indexers — subgraphs, custom ETL, the newer query layers — inherit the problem. A subgraph that missed an indexing range returns a result set that looks complete. There is no completeness proof. Contrast this with a cryptographic accumulator, which could in principle produce a proof that the returned set is the entire set matching the filter. Almost nobody builds this, because it is expensive and the market does not pay for it. The market pays for latency and uptime, and the cheapest way to deliver uptime is to return something.
Cross-chain messages and the empty payload
Bridges add another surface. A cross-chain message is a payload delivered by a relayer, validated by a light client or a committee, and executed on the destination chain. The payload is arbitrary bytes. Nothing in the base protocol requires the bytes to be non-empty.
Consider a bridge whose message handler decodes a payload into a struct and applies an action. If the payload is empty, and the decoder is written defensively, it reverts. If the decoder is written loosely — using defaults for missing fields — it interprets empty bytes as a struct of zeros: recipient address(0), amount 0, action byte 0x00. The action byte 0x00 might map to a no-op, which is harmless. Or it might map to index zero of a dispatch table, which in some designs is a privileged operation.
The empty payload is the cross-chain edition of the empty return. It is the same question: does the decoder treat absence as a distinct case, or does it coerce absence into the first element of the domain? Every bridge I have reviewed that got this wrong did so by accident. Nobody writes a decoder intending to accept empty input. They write it intending to accept a specific struct and forget that the empty byte string is a member of the type.
Building the schema gate
If the failure is "no invariant on the data path," the fix is to add one. Concretely, a schema gate at each stage boundary with four checks.
The first is non-null. The field exists and is not the language's null sentinel. In Python, is not None; in TypeScript, !== undefined && !== null. This is table stakes, and it is skipped constantly. The second is type. The field is the declared type. The empty string is a str and will pass a naive type check. The zero address is an address and will pass a Solidity type check. Type alone is insufficient. The third is domain. The value falls inside its declared domain. For a token amount, amount > 0 if zero is not a valid transfer. For a Merkle root, root != bytes32(0) and root != emptyRoot if the tree must be non-empty. For a price, the deviation is within bounds of the last observation. The fourth is provenance. The value is attributable to a source with a timestamp. A value that cannot be traced to an input is, by definition, a fabricated value.
The pipeline in the opening anecdote passed all four checks by returning absence. That is the correct behavior. The gate did its job: it refused to emit a value it could not ground. The failure — the reason this is worth writing about — is that the consumer of the gate may not have been prepared to receive the absence.
That is the actual vulnerability. The gate is fine. The downstream code path is the part missing a bolt.
Vacuity: the formal-verification version of the empty return
Formal verification promises the strongest guarantee: a proof that the bytecode cannot enter an unsafe state. I have used it. I also know its blind spot, and it is the same blind spot running through this entire article.
A specification can be vacuous. A property of the form "for all reachable states, P" holds trivially if no state is reachable. A rule written in a formal rule language, or an invariant in a semantic framework, can be satisfied by an empty execution trace. The verifier returns "verified." The system is no safer than it was.
This is not a theoretical edge case. It is a common failure in specifications. If a precondition is unsatisfiable — because it references a function that is internal and never called externally, or because an arithmetic bound can never be met — the rule verifies against zero paths. Modern tooling has started to expose this, reporting "rule is vacuous" and similar diagnostics. But the default reading of a green checkmark is "safe," and that reading is wrong when the check was taken over an empty set.
The connection is exact. The pipeline returned N/A for every field because the input was empty. A vacuous specification verifies because the path set is empty. A sparse Merkle tree accepts an all-zero path because the leaf set is empty. An ERC-20 call "succeeds" because the return data is empty. In each case, an empty domain is being treated as a satisfied predicate.
The remedy is the same everywhere: assert reachability, assert non-vacuity, and treat an empty witness set as a failure rather than a pass. A test that can never fire proves nothing. A rule that cannot be reached safeguards nothing.
The LLM research layer is the highest-stakes fail-open in the stack
Here is the part that should worry anyone allocating capital on the basis of automated research.
A large language model, given an empty retrieval result, does not fail closed. It fails open by construction. The architecture is a next-token predictor; when the context is empty, the prior distribution over plausible continuations is not empty. The model produces the most likely-sounding answer given the prompt, the fine-tuning, and the world it absorbed during pretraining. That answer is fluent. It is structurally coherent. It cites plausible sources, some of which may exist.
When the retrieval layer returns documents, the model can ground. When retrieval returns nothing — because the index is stale, the source is rate-limited, the document was deleted — the model does not know it should stop. It continues from priors. The output is indistinguishable, at the surface level, from a grounded answer.
This is the exact failure that the pipeline in the opening anecdote avoided by returning N/A. And the industry is racing to deploy the opposite. Research agents that always produce a report. Sentiment scanners that always produce a score. Anomaly detectors that always produce an alert. Each one is a fail-open stage, and the analysis above showed what a chain of fail-open stages does to an absence: it launders it.
The mitigations exist and are not exotic. Grounding with citations that are verified to resolve. A refusal path trained explicitly and tested with an adversarial empty-context suite. A calibration check: does the model's confidence drop when the context is empty? In the systems I have probed, it does not drop enough. That is the vulnerability class I would bet the next decade on — the confident fabrication produced by a system that was never designed to say "I don't know."
I don't trust; I verify. And the verification target is no longer only the contract. It is the pipeline that describes the contract.
The economics of the gate
Why is fail-open the default? Because fail-closed has a unit cost and fail-open does not, at least not on the timeline that procurement measures.
A schema gate costs a check. On-chain, a check costs gas. The require(root != bytes32(0)) is a few hundred gas. The token.code.length > 0 check is a few hundred more. Multiplied across millions of transactions, the aggregate cost is real, and the benefit — the attack that did not happen — is invisible on the balance sheet. So it gets cut. This is the same dynamic that produced the empty-return problem in the first place: the cheapest integration is the one that checks the least.
Off-chain, the cost is latency. A pipeline that verifies provenance on every field is slower than one that does not. In a market where being first to a headline is worth more than being correct about it, the fast pipeline wins the deployment and the correct pipeline wins the post-mortem.
Here is the pricing that would fix it, stated as a claim: a data output with a cryptographic completeness proof should trade at a premium to a data output without one, the way an audited contract trades at a premium to an unaudited one. Right now it does not, because the market cannot tell the difference — which is precisely the condition that fail-open design creates. You cannot price a guarantee that was never made.
The correction will come from the demand side, not the supply side. In 2024, ahead of the spot Ethereum ETF approvals, I read the custody architecture in the institutional filings closely — the multisig designs, the threshold signature schemes, the comparison against open-source alternatives like Gnosis Safe — and I flagged the centralization risks that the marketing material did not. The relevant point here is that when a custodian puts real balance-sheet capital behind an on-chain feed, the tolerance for un-attested data collapses. A custodian cannot explain to a regulator that the price came from "an aggregator that seemed up." The appetite for provenance becomes contractual. That is the pressure that closes the gap.
Contrarian: the empty output is the honest component
The conventional reading of the opening anecdote is that it is a bug report. A pipeline returned nothing; the pipeline is broken; fix the pipeline. I want to argue the opposite, and then qualify it hard, because the qualification is the point.
The pipeline was the only component in the chain behaving correctly. It received no information and returned no information. Every other design choice available to it — insert a plausible title, infer a thesis from market context, fill the fields with defaults — would have produced a more "useful" output and a more dangerous one. The industry's instinct to fix the empty output is the instinct to install the vulnerability.
Now the qualification. Fail-closed is correct at the boundary and catastrophic in the interior. A pipeline that returns N/A on every field because one field failed is not sound; it is brittle. The correct behavior is to fail closed per field, not per document. A missing title should not suppress a set of information points that were successfully extracted. A single stale oracle feed should not halt an entire protocol's price surface — it should halt the fraction that depends on the stale feed, and the protocol should declare, on-chain, which fraction that is.
This is the granularity problem, and it is where the industry's abstractions are thinnest. Solidity reverts the whole transaction. That atomicity is a feature for state transitions and a blunt instrument for data availability. Modern rollup architectures have started to decouple — posting compressed batch data separately from the state root — which is the right direction, whatever one thinks of dedicated DA layers. The data layer needs the same decoupling: partial results, per-field freshness, explicit nulls, and a consumer written to branch on them.
The second qualification concerns the audience. A fail-closed pipeline is only sound if the consumer can act on the absence. Most consumers cannot, because most consumers were built by people who never saw a null and assumed they never would. So the gate is necessary but not sufficient. You also need the consumer to have a defined behavior for N/A: skip, retry with backoff, or escalate — but never coerce. The coercion is the bug. The empty output is the signal.
The AMM model hides its truth in the invariant. The pipeline hides its truth in the schema. The consumer hides its truth in the default value it silently substitutes. All three are the same statement, written in three languages.
Takeaway
The vulnerability forecast is short. The next class of high-severity exploits in this industry will not be found in Solidity. They will be found in the layer that decides whether data exists — the schema, the oracle quorum, the retrieval index, the verifier's treatment of the empty instance. The attack will not be a reentrancy. It will be a null, laundered into a number, acted on by a system that was never written to say "I don't know."
Zero knowledge isn't magic; it's math you can verify. The corollary the last decade taught us is that a system which produces output is not thereby sound, and a system which produces nothing is not thereby broken. The soundness is in the check. And the check, in the data layer, has not been written yet.
When there is no invariant, treat the empty return as the alarm it is. The pipeline that refused to fabricate was the only honest component in the chain. The question worth carrying forward is whether the rest of the stack is ready to receive the truth that it has nothing to say — and whether it will have the discipline to say so out loud, in a schema, before the next null becomes a position.