Ninety-one fields. Nine dimensions. A star rating, a risk matrix, a disclaimer, and a priority-ordered list of follow-up signals. Every cell in the report contained the same three characters: N/A.
The pipeline that produced it did not error out. It did not throw. It returned a status of complete, with a clean schema, valid types, and a rendering layer that formatted everything correctly. Downstream, a scoring function read those ninety-one cells, found no risk flag raised, and assigned the asset a neutral conviction weight. Neutral, inside a risk engine, means no red flags.
The report was not wrong. It was worse than wrong โ it was structurally valid.
A system that cannot represent "I do not know" will represent it as "no." This is not a data problem. It is a type problem, and it is the most under-audited failure mode in the entire crypto stack.
Modern crypto research is a pipeline, and almost nobody has written down its type signatures. A document enters a scraper. The scraper hands bytes to an extractor โ increasingly an LLM โ which emits entities, claims, and attributes. A scorer maps attributes onto analytical dimensions. A decision layer converts dimensions into conviction weights, and conviction weights into positions. Five stages. Five opportunities for a null to be silently coerced into a value.
The coercion is always locally defensible. report.get("tech") returning None is correct Python. A risk engine that treats a None input as "insufficient signal, therefore neutral" is a reasonable default. A conviction function that maps neutral to 0.5 is a defensible calibration. Each branch passes code review in isolation. Composition is where the soundness dies.
The EVM taught us this lesson a decade ago and we keep relearning it. There is no null in the Ethereum Virtual Machine. There is address(0), which is simultaneously a valid address and an invalid address, a burn sink and a default constructor argument, a bug and a feature depending on which line reads it. There is uint256.max, which is both "infinite approval" and "uninitialized counter" depending on context. There is block.timestamp == 0, which is both genesis and test fixture. Every one of these is a null wearing an integer's clothing. Type confusion at the protocol layer, patched with convention instead of types.
Sideways markets are where this gets expensive. In a trending tape, momentum overrides the decision layer โ you are long because everything is long, and your flawed conviction function gets carried by beta. In consolidation, the tape gives no signal, so people reach for the research layer, and what the research layer hands them is its default branch. Chop is not where bad judgment gets punished. Chop is where bad plumbing gets exposed.
The invariant I use when reviewing any decision system, whether it settles on-chain or just allocates capital, is one line:
INVARIANT P1
for all dimensions d, for all fields f in d:
isUnknown(f) => decision(f) == HALTIts corollary is the part people skip: UNKNOWN is not FALSE. Unknown is a third state, and any system with only two states will collapse it โ and it will collapse it downward, toward zero, toward permissive, toward "no finding." Compute has a direction here. None is falsy. "" is falsy. [] is falsy. 0 is falsy. Every default you will reach for when you do not know something is a value that evaluates as no.
Here is the vulnerable pattern, stripped to its skeleton:
# VULNERABLE โ three silent coercions
report = parse(source) # may return {}
tech = report.get("tech") # -> None
risk = risk_engine(tech) # risk_engine(None) -> "neutral"
return conviction(risk) # "neutral" -> 0.5 -> "no flags"And here is the patch, which is not a patch to the parser but to the type system:
# FAIL-CLOSED
class Unknown: # a type, not a value
__bool__ = None # deliberately undefined
def __repr__(self): return "UNKNOWN"def score(asset): report = parse(source) facts = report.facts if report else [] if len(facts) < MIN_FACTS: raise InsufficientEvidence(asset) # HALT, do not rate ... ```
The distinction is load-bearing: make the unknown a type, not a value. Go's (value, ok) idiom exists because its designers had watched C return -1 for failure and then watched callers ignore it. Rust's Option exists for the same reason. Python, Solidity, and every LLM's structured output mode give you a default constructor that will happily manufacture a plausible zero.
The smart-contract analogue is not hypothetical โ it is the single most common unchecked-return bug in production DeFi. Consider the low-level call:
(bool success, ) = token.call(data);
require(success); // SUCCESS MEANS: DID NOT REVERTsuccess is not an outcome flag. It is a revert flag. A callee that executes cleanly, returns false, and leaves the transfer unmade will set success = true. The semantics have been flattened from {succeeded, failed, unknown} into {reverted, not-reverted}, and the caller then treats not-reverted as succeeded. I have watched a minting contract do exactly this: the token returned false, the require passed, the state updated, and the receipt was valid. A bug is just an unspoken assumption made visible โ here, the assumption that a non-reverting call is a successful call.
The same shape appears in every oracle integration I have audited since 2021. latestRoundData() returns five values, and the price is the only one most integrations read.
(, int256 answer, , uint256 updatedAt, ) = feed.latestRoundData();
// answer has no null. a stale answer and a fresh answer share a type.answer is int256. There is no way for it to say "I have not updated in eleven hours." Staleness lives in updatedAt and answeredInRound, and if you discard those, you have built a system in which a frozen feed is indistinguishable from a live one. During the 2022 volatility I traced a lending market whose feed heartbeat was longer than its liquidation cadence. Every parameter was within spec. The contract was working as coded. That phrase should terrify you more than any exploit report โ working as coded is precisely the failure mode when the code has no state for "unknown."
The 2026 twist is that the extractor is now often a language model, and the executor is often an agent. This is where the coercion becomes structural rather than incidental. An LLM's honest output for absence is a hedge: "insufficient information," "not specified," "unverified." An execution layer needs a boolean. The mismatch is not a bug in the model and not a bug in the chain โ it is a type mismatch at the human-machine boundary, and it will resolve in whichever direction the falsy check happens to fall.
I wrote a formal verification protocol for agent-driven transactions last year, and the requirement that consumed the most review cycles was not cryptographic. It was this: every transaction intent must carry an explicit UNKNOWN state that propagates to the executor and forces a halt. In the implementations I have since inspected, roughly four in five collapse it at the first if. The failure is mundane:
intent = auditor.check(target) # -> {"ownership": "unverified"}
risk = intent.get("ownership") # -> "unverified" (truthy string!)
if not risk: # never taken
target.enter() # the agent enters anywayNo line is wrong. The string "unverified" is not empty. The guard never fires. The agent establishes a position on a contract whose owner is an unrenounced EOA.
Here is the contrarian read, and it is uncomfortable for my own profession.
We have spent a decade and an enormous amount of capital auditing contracts. We have fuzzers, formal verifiers, invariant checkers, and a generation of security researchers who can read Yul. Almost none of that effort has been turned on the apparatus that decides which contracts to audit. Security is not a feature; it is the architecture โ and the architecture of due diligence is a fail-open system that has never been threat-modeled. Nobody fuzzes the analyst. Nobody fuzzes the pipeline that produces the queue.
The second inversion is mathematical. In options pricing, uncertainty raises the premium: ฯ โ โ price โ. In due diligence, missing data lowers perceived risk: data โ โ flags โ. The sign is inverted. An asset with no verifiable information should be priced at maximum uncertainty, not minimum. Instead, every dashboard renders "no red flags" and "no data" as the same empty state, because both produce zero output from a detector that only knows how to look for positives.
And the deepest irony: the report that returned ninety-one N/As was behaving correctly. It refused to fabricate. That refusal is a virtue at the reporting layer and a vulnerability at the system layer โ because the correct behavior was to throw, not to print. A report is an artifact; a halt is a control. Clarity is the highest form of optimization, and the clearest possible output from a system with no inputs is an exception, not a table.
Where this lands: the next headline loss will not be a reentrancy bug. Reentrancy is twenty years old, well-understood, and largely solved at the library level. The next loss will be a fail-open data path inside an autonomous decision loop โ an agent that was told to halt on uncertainty, and that inherited a falsy default from a language designer's reasonable choice in 1991.
My forecast is unglamorous and testable: within the current cycle, at least one material exploit will trace to a provenance gap rather than a logic error โ stale data, an unverified field, or an empty extraction result that the executor read as a clean bill of health. Compiling truth from the noise of the blockchain means accepting that some of the noise is the absence of signal, and that absence must be a first-class type.
So, the bug report you should file against your own stack, before you file it against anyone else's: if every field in your risk engine came back N/A tomorrow, would it halt โ or would it hand you a rating?