Most technical due diligence is sector-agnostic by design. Architecture, delivery health, security posture, key-person risk. Those transfer well and you should still do them.
But in crypto and AI infrastructure, the questions that decide the deal are not on that list. Below are the ones we actually ask, from a fund that deploys its own capital into both: Fund I into blockchain and Web3 infrastructure globally, Fund II into AI-first companies in India.
The general framework — deliverable, timeline, pricing — is on the technical due diligence page. This is the sector-specific layer.
Crypto and blockchain infrastructure
The mechanism, not just the code
The most expensive failures in this sector are not bugs. They are correctly-implemented mechanisms that stop working when participants behave adversarially rather than as modelled.
So the first question is what the token is actually for. Not what the deck says it is for — what economic function it performs that could not be performed without it. A surprising number of tokens are a fundraising instrument wearing a utility argument, and that is a very different risk profile.
Then: what happens to this mechanism in a market where nobody is speculating? Designs that depend on continuous new entry are describing a condition, not a system.
Custody, halting, and who actually has power
Who can halt the chain. Who holds keys. What the recovery story is when a signer is unavailable. Whether the trust model described in the pitch is the one enforced in the contracts.
That last one is where the gap usually is. Teams describe decentralised systems and ship admin keys, not out of dishonesty but because the admin key was necessary during development and nobody scheduled its removal. An immutable contract with a bug and a mutable contract with an unaccountable admin key are different risks, not the same one, and both need naming.
The dependency surface
Bridges, oracles and sequencers the team does not control but whose failure is indistinguishable from their own, from the user's point of view and frequently from the press's.
A team that has thought about this can tell you exactly what happens when their oracle goes stale. A team that has not will tell you it is not their component, which is true and irrelevant.
AI and ML infrastructure
Evaluation infrastructure is the tell
If I could ask one question in an AI deal it would be this: how do you know when output quality regresses?
A team with a real eval set answers immediately and shows you the numbers. A team without one explains that they check manually, or that their users would tell them. Both mean the same thing: they are flying without instruments and will discover a regression from a customer complaint.
This is the most predictive negative finding I know of in the sector, because it is not really about evals. It is about whether the team treats model behaviour as something to be measured or something to be hoped for.
Inference cost curves at ten times volume
Model the unit economics at ten times current volume, not at current volume.
This is arithmetic rather than deep engineering, and it is skipped constantly. Traditional software got cheaper per user with scale. Inference frequently does not, and a product with healthy demo-scale margins can be gross-margin negative at the volume the model in the data room assumes.
Model and data dependency
What breaks if the underlying provider changes pricing, deprecates a version, or ships this feature natively. A moat that assumes today's model is the last one is not a moat.
And separately: what are they permitted to train on, what have they actually trained on, and are those the same sentence. Data rights are where AI deals most often fail a customer's legal review, usually months after close.
Moat durability
The specific question is which parts of the product get absorbed if the frontier moves six months, and what remains that is genuinely theirs.
Workflow depth, proprietary data, distribution and switching costs survive a model release. A thin orchestration layer over a public API does not. This is the same shift I wrote about in why agents change what products are — the substrate is commoditising faster than the surface.
What this changes about the report
Sector-specific findings tend to be binary in a way that general findings are not. Technical debt is a number. "The admin key can drain the contract" is not a number, and neither is "there is no way to detect quality regression".
So the report has to separate them: findings that reprice, and findings that decide. Mixing them into one risk register is how a genuinely disqualifying fact ends up as item fourteen of nineteen.
If the deal is venture-stage rather than a buyout, the framing differences are covered on the venture capital CTO page. If you are a family office investing directly rather than through funds, the reporting needs to be legible to a principal rather than an engineer, which is a different job again.
Need help thinking this through? Book a 30-min call — no pitch. Book a Free 30-Min Strategy Call →
