Last month, in a glass-walled room in Copenhagen, I opened a due-diligence pack that weighed more than my laptop. The protocol had raised $100 million. Every field was populated: team biographies, token distribution charts, an audit report, a dashboard showing a healthy TVL curve. Nothing in it was false in a way a lawyer could act on. And yet when I pulled the same numbers from the chain, three of them moved. The TVL included a looped position between two wallets funded by the treasury. The audit covered a commit hash that no longer existed in the repository. The independent attestation had been signed by an entity sharing a registered address with the foundation.
I closed the file and thought about something I had been staring at all week: a data pipeline that returned a complete schema. Nine sections. Every header, every table, every confidence rating present and correctly formatted. Every field populated with the same phrase — insufficient information. A well-formed answer is not the same thing as a true one. The empty report had been produced honestly. Someone ran the process, found the inputs missing, and declined to invent. I respect that discipline enormously. What unsettled me was how closely it resembled the pack in front of me. One was empty and admitted it. The other was empty and had a cover page.
The industry calls this a verification problem, and I think that framing is too generous. It implies we have already agreed on what verification would mean. We have not. We have agreed on what verification looks like — tabs, dashboards, green checkmarks, a PDF titled Audit Report. The bull market has been extraordinary for the business of proving things. It has been far less good for the practice. Attestation vendors multiplied after 2024, proof-of-reserves became a marketing line item, oracle networks colonised every whitepaper's architecture diagram, and yet the number of claims a retail participant can actually check for themselves has barely moved.
So it is worth being precise about what a claim can even be. There are four registers. A claim can be declared — a sentence in a document. It can be signed — a cryptographic commitment by a key that somebody holds. It can be proven — a mathematical statement about a computation, verified by anyone. And it can be economically secured — backed by something that can actually be taken away when the claim fails. Most of what this market calls verification lives in the first two registers. A little of it reaches the third. The fourth is where the money is, and it is where the honesty is thinnest.
I learned that distinction the hard way in Berlin, and it took me three months to stop being wrong about it. In 2018 I was leading product for a privacy-focused mobile payments startup, and we were integrating ZK-SNARKs for transaction verification. The bottleneck everyone worried about was cryptographic: could we get sub-second confirmations without breaking anonymity? I ran an intensive review of our elliptic curve implementation with three core developers, we refactored the consensus layer, and we cut gas costs by roughly 40 percent while holding the zero-knowledge property intact. We shipped a beta to 5,000 early adopters and it worked.
What I took from that year was not that the math was hard. The math was the easy part. The hard part was the sentence immediately before the math — the claim that the proof was actually about. If your circuit proves the wrong statement beautifully, you have not built privacy. You have built an expensive lie with a clean formal specification. That experience is why I stopped writing technical tutorials and started writing about autonomy, and it is why I keep returning to the same line. Truth is not what is seen, but what is trusted. Everything downstream of that sentence is engineering. Everything upstream of it is judgement, and judgement does not have a proving system.
Oracles are where this becomes unavoidable. A price feed returns a payload. The HTTP response says 200 OK. The signature verifies against a known key. The schema validates. Everything about the response is correct, and the number inside it can be thirty seconds stale, sourced from a venue with four participants, or the product of a single market maker's internal model that nobody outside has ever seen. This is precisely the empty-schema problem, and it is structural rather than incidental. At the interface level, a meaningful payload and a meaningless one are indistinguishable. Oracles do not bring truth on-chain. They bring attestations with excellent uptime. The only questions that matter are who is attesting, under what incentives, and what actually happens to them when they are wrong. Most oracle designs answer the first two and quietly decline the third.
Proof of reserves has the same shape and a sharper edge. The Merkle sum tree is elegant mathematics, and I have built one. But reserves without liabilities is a photograph of a warehouse with no inventory list attached. The scope statement at the front of the report matters more than the proofs at the back, and almost nobody reads it. There is also a distinction that institutions understand and retail audiences generally do not: an attestation is a procedure agreed in advance with a client, while an audit is an opinion formed independently by a practitioner who accepts professional liability for it. Both arrive as PDFs with logos. Only one of them is designed to survive disagreement. Bridging that language gap has consumed most of my working life since 2024, and it is slow, unglamorous work.
Data availability sampling taught me a related lesson about the difference between a guarantee and an inference. Sampling gives a light client a probabilistic assurance that block data was published. That is genuinely valuable and it is genuinely limited — it says nothing about whether the data meant anything. A block of properly erasure-coded zeros passes every sampling check ever written. Availability is a necessary condition for verification and it is not verification, in the same way that a correctly formatted template is not a report.
Nobody has paid more dearly for confusing a trust transfer with a proof than the bridge ecosystem. Cumulative losses from cross-chain exploits have passed $2.5 billion, and the industry has responded by continuing to route an enormous share of its value through the same class of component. This is the security paradox at the centre of our architecture: message passing between chains is not verification, it is a trust transfer wearing cryptographic clothing. Light-client bridges that re-run consensus verification natively are the correct answer and they are expensive, slow, and jurisdictionally awkward to maintain. Externally validated bridges are cheap and fast and they fail catastrophically. We keep choosing the second, because the failure is deferred past the point where the choosing happens.
The Layer 2 conversation suffers from a similar category error. The contest between the OP Stack and the ZK Stack is usually narrated as a cryptographic rivalry, and it is not one. Both proving systems are good enough for what the market currently demands of them. The thing that actually decides which stack dominates is which one convinces more teams to deploy chains first — the quality of the documentation, the economics of sequencing, the availability of people who have already shipped on it, the social layer of standardisation. Cryptography is a tie. Distribution is the differentiator, and distribution is a governance phenomenon that happens to have a compiler.
What the rollup ecosystem has produced that I genuinely admire is not a proving system at all. It is a taxonomy: honest labels for how much of a chain has actually been decentralised, whether the sequencer can censor, whether there is a working escape hatch, what happens if the operator disappears. Labelling is a form of verification, and it is far cheaper than mathematics. It costs nothing but institutional courage, which is exactly why it is rare.
Uniswap V4 pushed the same problem down into the application layer. Hooks are contracts that execute at defined points in a pool's lifecycle, and they turn a DEX into programmable Lego, which is genuinely exciting and genuinely frightening. A pool address commits to a hook address. It does not commit to the hook's behaviour. Immutable addresses can point to mutable logic, upgradeable proxies can be swapped after liquidity arrives, and the state space a depositor would need to reason about grows faster than any human or any auditor can follow. I have walked through enough hook implementations to say this plainly: the complexity spike will scare off the large majority of developers who would otherwise have built on it, and the ones who remain will be the ones with enough sophistication to hide something. That is not an argument against programmability. It is an argument for treating every pool as a bespoke protocol rather than a standard one.
Identity is where this stops being an engineering curiosity and becomes a moral question. In 2025 I led development of a decentralised identity protocol that integrated AI-driven reputation scores, and the technical challenge was never the scoring model. It was preventing that model from entrenching inequalities that already existed. We convened a cross-functional ethics board with sociologists and philosophers, and we built a human-in-the-loop requirement: fifteen percent of all reputation updates were routed to manual review by a diverse panel of community members. It launched with 10,000 users, and the retention data convinced me that AI can amplify human judgement rather than replace it.
But the protocol also exposed something I had not anticipated. A score is a claim about a person, and it is almost always unappealable in practice. Verifying that a score was computed correctly by a model is a solved problem. Verifying that the model deserves to exist is not a technical problem at all. We can prove a judgement was made faithfully by a system whose legitimacy nobody can prove. Garbage in, proof out. The formal guarantee becomes a laundering mechanism for the assumption underneath it.
Institutions understand this instinctively, even when they cannot articulate it. In 2024 I joined a Nordic fintech firm to design custody for institutional clients on non-custodial principles, and I spent twenty deep interviews translating cryptographic guarantees into the vocabulary of risk committees. What sold was not decentralisation. What sold was a hybrid architecture that produced compliance reporting without ever exposing private keys, and a €2 million pilot contract followed. The lesson was not that values must be diluted. It was that values must be packaged in a language that can be audited by someone who does not share them.
That conviction is what produced the Copenhagen summit in 2026, two days and fifty stakeholders from regulators, technology firms, and civil society, drafting a voluntary code of conduct for AI and crypto integration. We put regulators and developers in the same roundtables and let them argue, and the breakthrough was a shared understanding of compliance as code — obligations expressed as executable checks rather than prose. Three major European exchanges adopted the resulting document. A voluntary code is soft law and I have no illusions about its enforceability, but soft law creates a reference artefact that both sides can point at, and artefacts outlive enthusiasm.
Which brings me to the contrarian half of this argument, and it is the half I find least comfortable. The industry's slogan is verify, don't trust. It is a good slogan and it was written by people who can verify. For everyone else, the result of radical transparency is not verification — it is the appearance of verification, paired with the full burden of scepticism and none of the tools. When every claim is published and almost none is checkable, the market does not price truth. It prices confidence. And confidence is cheap to manufacture at scale.
This is why I have come to believe that transparency can be worse than opacity when it is unaccompanied by verification capability. An opaque system at least signals that something is being withheld, and a counterparty can price that uncertainty. A fully transparent system that publishes numbers nobody can reproduce manufactures a false sense of due diligence. The reader in my Copenhagen room was not fooled by secrecy. They were fooled by disclosure. Privacy, in other words, is not the enemy of integrity. It is often its precondition, because a system that cannot protect its inputs will eventually have nothing worth verifying.
What I would argue for instead is narrower and harder. Fewer claims, each of them committed rather than merely disclosed. Guarantees with named counterparties, defined failure conditions, and something that can actually be taken away. Not fewer proofs — better-specified ones. The next generation of verification infrastructure will not be judged by how much it reveals. It will be judged by how much it can be wrong about, and by whether anyone pays for that.
So when the next $100 million raise lands on my desk with every field populated and every risk rated low, I know what I will be looking for. Not the audit logo. The commit hash, the attestation scope, the wallet graph behind the TVL, and the name of the entity that eats the loss when the claim fails. If none of those four things can be produced, the document is a template with good typography — and the most honest thing anyone in this industry can do is hand it back unsigned.
The bull market will keep rewarding confidence. The question worth carrying into the next cycle is whether we can build systems that reward being right, and whether anyone building them has the patience to publish an empty table when that is the truth.