On a Tuesday in the middle of a sideways market, a research pipeline returned a report. Every field was populated. Every heading was present. Every table had rows, every row had cells, and every cell contained the same string: "N/A - insufficient information." The document passed schema validation. It rendered cleanly in the dashboard. By every automated measure the ingestion layer used, it was a successful output.
It was also empty. Not empty in the way a draft is empty. Empty in the way a checksum is empty when the file never arrived. The hash is valid. The payload is not.
I have spent nineteen years reading code and post-mortems, and the failures that worry me are no longer the ones that throw exceptions. Those are cheap. An exception is a loud alarm in a quiet building. The failures that matter now return a well-formed object with nothing inside it, because those objects get consumed, aggregated, and shipped to decision-makers who cannot distinguish between "we measured the risk and found none" and "we never measured the risk at all."
The report in front of me was a null report. A null report is not a non-event. It is an incident that has not been classified yet.
Context: how a framework can succeed and fail at the same time
To understand why an empty document is more dangerous than a broken one, you have to understand the architecture that produced it. Modern crypto research does not happen in a single mind. It happens in a pipeline. There is an ingestion layer that scrapes articles, filings, and on-chain data. There is a parsing layer that extracts entities, claims, and data points. There is an analysis layer that maps those extractions onto a fixed schema of questions. And there is a rendering layer that formats the answers into something a human or a machine can read.
Each of those layers can fail in two ways. It can fail loudly, by crashing, by returning an error, by emitting a malformed object that the next layer rejects. Or it can fail quietly, by returning a structurally valid object that is semantically empty. The first failure is a gift. The second failure is a liability, because it passes every gate designed to catch the first.
The schema in question is a nine-dimension framework. Technical. Token economics. Market. Ecosystem position. Regulatory. Team and governance. Risk. Narrative. Supply-chain transmission. Nine dimensions, each with sub-fields, each sub-field expecting a value. It is, on its face, a rigorous instrument. It forces the analyst to answer the same questions in the same order for every subject, which is exactly what you want if your goal is comparability. Simplicity in logic, complexity in execution. The logic here is simple: fill the cells. The execution is where it fractures.
Because the framework has a fixed schema, it can always be filled. That is its strength and its trap. A fixed schema does not require truth. It requires only that each cell be non-null. And there is a string that is non-null while carrying no information: "N/A." The schema cannot tell the difference between a cell that says "0% team allocation" and a cell that says "N/A." Both are strings. Both pass validation. Only one of them is data.
This is not a hypothetical. This is the structural condition of every automated research system I have audited since 2017, and it is getting worse, not better, because the volume of content being processed has grown faster than the discipline of the processors. The economics push in one direction. Producing a complete report is expensive. Producing a complete-looking report is cheap. When the two are indistinguishable at the output layer, the market will always choose cheap.
I want to be precise about what the framework did and did not do. It did not invent data. That is important. The failure mode I am describing is not hallucination. Hallucination is a different disease, common to language models, in which the system fabricates a plausible value. The null report is the opposite pathology. It refuses to fabricate. It correctly reports that it has nothing. It is, in a narrow sense, honest.
The problem is that honesty at the cell level produces dishonesty at the document level. A document full of "N/A" reads, to a skimming consumer, as a document that has been completed and found wanting. It reads as "this subject is unremarkable." It does not read as "this pipeline failed." The rendering layer flattens the distinction between absence of evidence and evidence of absence, and it does so silently, without a warning flag, without a confidence score, without an exception.
History records the same pattern in every system that has ever conflated the two. In 2008, the models did not fail because they had bad data. They failed because they imputed missing data as if it were average data, and the missing data was not average. It was the tail. The nulls were the risk. Nobody had a field for "the input was never delivered." So the model treated the missing correlation as zero correlation, and zero correlation is a very comfortable number, and comfortable numbers get leveraged. The ledger remembers what the market forgets. The market forgot the nulls. The ledger did not.
Core: the semantics of nothing
Let me get technical, because the abstraction is hiding a concrete engineering problem.
In relational databases, NULL is not a value. It is the absence of a value, and it obeys a different logic. NULL does not equal NULL. NULL is not greater than zero and not less than zero. Any arithmetic expression involving NULL evaluates to NULL. This is not a quirk. It is a deliberate design decision to prevent the exact class of error I am describing: the silent propagation of absence as if it were presence. If you add a missing number to a real number and get a real number, you have invented data. SQL refuses to invent data. It returns NULL, and it forces the application layer to decide what NULL means.
That is the correct behavior. It is also the behavior that most crypto research pipelines do not implement. They implement a string type. The string "N/A" is a real string. It concatenates. It sorts. It renders. It can be counted, and a document full of it can be counted as complete. The type system has already lost the information that mattered, and it lost it at the moment of ingestion, long before any human looked at the output.
I built a small simulation to quantify how badly this propagates. It is crude, but the shape of the result is the point. Take a ten-field risk template. Assign each field a probability of receiving real data from the upstream parser. Then propagate the document through three downstream consumers: an aggregation layer that averages numeric fields, a scoring layer that assigns a risk grade, and a routing layer that sends high-risk subjects to human review. The only thing the simulation assumes is that nulls are not flagged.
At a 90% per-field fill rate, the probability that all ten fields contain real data is 0.9^10, which is about 35%. Two-thirds of documents are partially empty. If the aggregation layer treats "N/A" as a neutral value, and if the scoring layer maps a neutral average onto a "low risk" grade, then a majority of documents get routed away from human review on the basis of data that does not exist. The failure is not in any single field. It is in the composition. Stress tests reveal the fractures before the flood. This is the fracture: not one broken cell, but a document that is 65% air and grades as solid.
The simulation also shows something subtler, which is the real insight. The damage is not linear in the fill rate. It is exponential in the number of fields, and it is catastrophic at the aggregation step, because aggregation is where absence gets converted into a number. A cell that says "N/A" is at least honest. An average that includes that cell as a zero is a lie with a decimal point. Once the null becomes a number, every downstream consumer treats it as measured, and the provenance is gone. You cannot audit your way back to the null, because the null no longer exists in the record. It has been laundered into a statistic.
I have seen this exact laundering in the wild, and it is why I stopped trusting dashboard risk scores years ago. In 2020, when I was a mid-level auditor during the DeFi Summer, I wrote a Python script to simulate ten thousand random liquidity events against the Compound V1 interest rate model. The point was not the events. The point was the states between the events. In a meaningful fraction of the simulated paths, the model's inputs were stale: an oracle that had not updated, a utilization figure computed from a block that was already superseded. The model did not crash. It returned a rate. And the rate was wrong precisely because the model had treated a stale value as a fresh one.
I published the exploit path as a GitHub gist, and a larger audit firm later referenced it. But the lesson I carried forward was not about Compound. It was about the general shape of the bug. The dangerous state is not the missing value. It is the missing value that has been silently replaced by the last known value, which is the default behavior of almost every caching layer in DeFi. A cache exists to turn absence into presence. That is its function. That is also its hazard.
This is where formal verification becomes relevant, and where I part company with the parts of this industry that treat verification as a checkbox. Formal verification is the only truth in code. Not because it is fashionable, but because it is the only method that can prove a property about all states, including the states where data is absent. A hand-written test suite tests the states you thought of. A proof tests the states you did not. When I disassembled the Tezos pre-mainnet codebase in 2017, reviewing the self-amendment protocol's OCaml proofs, what struck me was not the elegance of the governance logic. It was that the proofs had to specify behavior for every input, including inputs that were never expected to occur. The proofs forced the developers to answer the question the null report never asks: what happens when the data is not there?
Three of the logical flaws I identified in that governance voting mechanism were exactly of this type. They were not errors in the happy path. They were undefined behavior in the edge path, in the states the spec had not bothered to enumerate because the developers assumed they would never occur. A voting mechanism that does not specify what happens when a quorum is reached but a delegation is null is a voting mechanism that can halt an upgrade. The code compiled. The tests passed. The null was still a hole.
Immutability is a promise, not a guarantee. The same is true of completeness. A document is not complete because its schema is full. It is complete because every field has a verified provenance, and every absent field is explicitly marked as absent, with a reason. That distinction — verified absence versus silent absence — is the entire ballgame, and almost nobody implements it.
Let me make the proposal concrete, because a critique without a mechanism is just noise.
The mechanism I want is a completeness attestation. Think of it as a Merkle proof, but for data presence instead of data content. In a Merkle tree, you can prove that a specific leaf exists in a set without revealing the whole set, because the path from leaf to root is verifiable. You can do the analogous thing for a research document. Hash each field. Build a tree. Publish the root. Now anyone can verify, later, that a given field was populated, and can verify that a given field was not. The provenance of absence becomes as checkable as the provenance of presence.
This matters for exactly one reason, and it is a compliance reason. In an institutional context — the context I entered when I analyzed the BlackRock Bitcoin ETF infrastructure in 2024, tracing the on-chain movements of the issuers and verifying the security posture of their multi-signature custodial wallets — an undocumented gap is a liability. Traditional finance does not accept "we did not check." It accepts "we checked and found nothing" only if the checking is itself documented. The friction points I found in cross-chain settlement were not, for the most part, technical failures. They were provenance failures: a transfer whose origin could not be fully attested, a custodian whose key ceremony was described in prose but not provable in code. Verification precedes value. An institution will not move size through a rail whose completeness it cannot prove, no matter how fast the rail is.
The AI-agent audit I completed in 2025 sharpened this further. The protocol I examined had autonomous agents executing smart contracts, and the critical vulnerability I found was a prompt-injection path that let a linguistic tweak bypass the access controls. The agent did not malfunction. It behaved exactly as designed, given the input. The problem was that the agent had no deterministic layer separating "instruction" from "data," so an attacker could smuggle one inside the other. The fix I proposed was a deterministic verification layer between the agent's reasoning and the chain's execution — a layer that does not care how confident the model is, only whether the output satisfies a formal predicate. That is the same medicine as the completeness attestation. It is the refusal to let a plausible-looking output stand in for a verified one.
The connection to the null report is direct. An AI agent that hallucinates a value is dangerous. An AI agent that returns "N/A" and has that "N/A" treated as neutral is equally dangerous, and harder to catch, because it is not wrong. It is merely empty. And emptiness, in a system that rewards throughput, is indistinguishable from success.
I want to name the failure precisely, because naming is the first step of remediation. The failure is a type confusion. The pipeline confuses the type "insufficient information" with the type "information indicating low risk." These are different types. They require different handling. One should halt the pipeline. The other should proceed. Because they were both represented as strings in the same field, the pipeline could not tell them apart, and so it did what all software does when it cannot tell two things apart: it treated them the same. Chaos is just unverified data. The null report is chaos wearing the costume of order.
There is a version of this argument that is purely technical, and there is a version that is about incentives. I want to hold both, because neither alone explains the phenomenon.
Technically, the fix is known. Distinguish null from value at the type level. Propagate null through aggregation as null, not as zero. Require every document to carry a completeness score and a provenance root. Fail closed: if a required field is null, the document does not render as complete; it renders as incomplete, and it is routed to a human. None of this is novel. It is standard data-engineering discipline, and it has existed for decades in fields that learned the lesson the hard way.
The reason it does not exist here is the incentive layer. The crypto research industry is measured on coverage. How many projects did you analyze this week? How many reports did you ship? Coverage is a volume metric, and volume metrics reward completion, not correctness. A pipeline that refuses to complete a document because a field is null produces fewer documents. A pipeline that fills every field with "N/A" produces more. If the consumer cannot tell the difference, the second pipeline wins, and it wins by a lot, and it wins in exactly the market conditions where the difference matters most: a sideways chop, where nobody is being forced to look, and where the temptation to ship volume is highest.
This is why I am suspicious of the current consolidation, and why I have been watching fill rates rather than price. In a trending market, mistakes get punished quickly. In a chop, mistakes get rewarded, because nothing resolves. The null report is a chop-market artifact. It survives because the market is not yet forcing a resolution. When the resolution comes, the nulls will be the first things to break, and they will break in the projects that looked the most thoroughly analyzed.
Contrarian: the blind spot is the clean report
The consensus view in security is that more analysis equals more safety. I think that is backwards in a specific and important way, and I will state the contrarian claim plainly: a clean-looking empty report is more dangerous than a loud error, and the industry is systematically training its consumers to prefer the former.
Here is the mechanism. Humans are pattern-matchers, and a full table is a pattern of thoroughness. An error is a pattern of failure. When a consumer sees a completed report, they lower their guard. When a consumer sees an error, they raise it. So the incentives reward the pipeline that never errors and never fills, and punish the pipeline that errors honestly. Over time, the population of reports shifts toward the former, and the apparent average quality of research rises while the actual information content falls. This is Goodhart's law applied to due diligence: the measure becomes the target, and the target ceases to be a good measure.
The deeper blind spot is that nobody audits the auditor's nulls. When a project gets exploited, the post-mortem examines the code. When a project does not get exploited, nobody examines the report that cleared it. So the false-negative rate of research is structurally invisible. You can measure how many risky projects a research process flagged. You cannot easily measure how many safe-looking projects it failed to flag, because the failure only becomes visible when something breaks, and by then the report is forgotten. The ledger remembers what the market forgets, but only if someone writes the nulls into the ledger. If the report says "N/A," and the project later collapses, the report did not miss the risk. It recorded nothing. And nothing cannot be wrong.
I have a specific reason to distrust clean reports, and it comes from the Terra/Luna collapse in May 2022. I spent seventy-two hours straight analyzing the Anchor Protocol's smart contract interactions and the LUNA burn mechanism, documenting the exact sequence of oracle manipulation and liquidation logic failures. What I found in the aftermath was that the system had been, in many reports, cleared. Not because the reports were corrupt, but because the reports had no field for the thing that killed it. The thing that killed it was a feedback loop between an incentive and a price, and the templates of the time did not have a dimension for feedback loops. They had a dimension for "audit status," and the audit status was green, and green is a value, and the report was complete.
The report was complete. The report was also empty of the one fact that mattered. Those two statements are not contradictory, and that is the whole problem.
There is a second-order effect that I find more disturbing than the first. Once an empty report becomes the norm, it becomes a defense. A team that wants to appear diligent can point to a stack of completed reports. A team that wants to avoid scrutiny can ensure that the scrutiny, when it comes, is conducted through a template that cannot ask the dangerous questions. The template becomes a shield. The "N/A" becomes a claim of diligence without the content of diligence. This is not conspiracy. It is emergent. No one has to intend it. The structure produces it.
And there is a compliance angle that I have watched mature since the ETF approvals. Institutional allocators are, correctly, demanding documentation. But documentation requirements are satisfiable by form as well as by substance. A fill-rate requirement — "every field must be populated" — is satisfied by "N/A." A substance requirement — "every field must carry a verified provenance" — is not. If the industry converges on the former because it is cheaper to satisfy, it will have built a compliance theater in which the appearance of rigor is inversely correlated with its reality. I have audited enough key ceremonies described in confident prose to know how easy that theater is to erect.
The contrarian conclusion, then, is uncomfortable for people who like clean dashboards: the absence of a red flag is not a green flag. It is a null. And a null should be rendered in the same color as a red flag, because it carries the same operational meaning. We do not know. We do not know is not safe. We do not know is the least safe state there is, because it is the only state from which you cannot estimate the downside.
Takeaway: completeness is a property you can prove
I will not end with a summary, because a summary of this argument would be exactly the kind of comfortable completion this article is about. I will end with a forecast and a checklist.
The forecast: over the next cycle, as AI-assisted research pipelines scale, the null report will become the dominant failure mode of crypto due diligence. Not hallucination. Nulls. The systems will be honest at the cell level and dishonest at the document level, and the industry will discover the gap only after a cluster of "thoroughly analyzed" projects fails in ways their reports could not have predicted, because their reports had no field for the failure and filled that field with a string. The block height does not lie, but the report does, and it lies by saying nothing.
The checklist, for anyone building or consuming these pipelines:
First, distinguish null from value at the type level, before ingestion. If your schema stores both as strings, you have already lost the information.
Second, propagate null through aggregation as null. Never let an absent value enter an average. An average that includes a null is a fabrication.
Third, attach a completeness score and a provenance root to every document, and render the score. A document that is 65% null should look 65% null.
Fourth, fail closed. If a required field is null, route to a human, do not render as complete.
Fifth, and this is the one that matters most, audit your nulls the way you audit your code. Sample the documents you cleared. Check whether the fields you filled with "N/A" would have changed the conclusion had they carried real data. Formal verification is the only truth in code, and the same is true of data. A field you did not verify is a field you cannot trust, no matter how neatly it renders.
The question I want to leave with the reader is not whether your pipeline produced a report. It is whether your pipeline could tell the difference between a report and a null. If it cannot, then every clean document it produces is a small, quiet incident, waiting for a market that is no longer sideways to classify it. The ledger remembers. Make sure your report does too.
