A technical due-diligence framework for DeFi protocols

Technical diligence on a deployed protocol is not a code review and it is not a vibe check. It is a set of questions with observable answers — things you can determine from chain state and public artefacts without the team's cooperation and without trusting a single sentence they have written. The framework below is ordered by how much of the outcome each question explains.

1. Who can move the funds?

The first question dominates all others, because every other property is conditional on it. Enumerate the privileged roles and, for each, ask what it can reach: can any key withdraw user principal, redirect a payout destination, pause exits, or upgrade the logic that holds the assets? An upgrade path is a key that can reach everything, whatever the current code says.

The strong answer is not "the team is trustworthy" — it is that the powers touching funds have been permanently surrendered, verifiably, while any remaining powers can only add rather than redirect. The distinction is checkable: read the roles, read whether renunciation is irreversible, and read where withdrawals are allowed to go.

2. Does it still price with the team's servers off?

A protocol whose numbers come from a private server has a single point of failure that no amount of on-chain settlement removes. Test it directly: try to obtain a price with the hosted front end and API unreachable. If nothing answers, the pricing layer was never decentralised, and the protocol's continuity depends on a company remaining willing and able to run infrastructure.

3. Can every published figure be rebuilt from primitive state?

Protocols publish figures for trustless verification, and everyone — users, dashboards, monitors, the team's own tests — checks the system through those figures. That makes the reporting surface the highest-leverage place for an error to hide, because a defect that corrupts the instrument is invisible to every other check simultaneously.

The wrong test is confirming the published views agree with each other; two views derived from the same faulty helper agree perfectly and are both wrong. The right test rebuilds each figure independently from raw chain state and compares. If a protocol cannot survive that, its transparency is decorative.

4. What is the enforced worst case?

Every system that moves value has a bad path. Ask what bounds it. Is there a minimum the contract will accept before it reverts, and is that minimum derived on-chain from the real transaction, or supplied by whoever built the request? A bound that the caller can widen is not a bound. Look for the failure mode too: does the system fail closed — refusing to act when it cannot establish a fact — or does it fail open with a guess?

5. Which dimensions do the invariants actually cover?

Protocols advertise invariants, and invariants are the strongest guarantee available on-chain — but each one guards exactly the axis it measures and is silent about every other. A conservation property proves how much value exists; it says nothing about who is owed it, when it was earned, whether an honest user can exit, or whether the published numbers describe reality.

So the diligence question is not "does it have invariants" but "which dimensions are unguarded". Value, time, liveness, privilege, incentives, asset boundary, reporting truthfulness, deployment assumptions — for each, ask what enforces it. The unnamed dimension is where the next defect lives.

6. How does it behave at the asset boundary?

Tokens misbehave: some charge a fee inside the transfer, some change balances with no transfer at all, some return no success value or return the wrong one. Any protocol that credits the amount it REQUESTED rather than the amount that ARRIVED is mis-accounting against real holdings, and the error compounds through every downstream calculation. Check whether the code measures balance deltas or trusts its own arguments.

7. Does it survive being unmaintained?

Assume the team disappears tomorrow. Does the protocol keep functioning, or does it silently degrade? Look for dependencies on someone choosing to act: a keeper that must be paid to run, an oracle that must be updated, a parameter that must be tuned. A system that cleans itself from ordinary user activity has a fundamentally different survival curve from one that needs attention, and that difference is invisible while the team is still attentive.

8. Is severity assigned before or after reachability?

This one reveals the engineering culture rather than the code, and it predicts future defects better than any single finding. Ask how the team rated the issues they have already disclosed. A severity is a claim about the reachable world; asserted from an algebraic argument, it will eventually be asserted from one that is wrong, and every conclusion built on it inherits the error — including decisions to delete branches believed dead.

A team that measured reachability before rating, that publishes findings against itself, and that treats a negative result as a hypothesis rather than a conclusion, is a team whose next bug is more likely to be found by them than by an adversary. That is the property you are actually underwriting.

Using the framework

None of these eight requires source access, an NDA, or a conversation. Each is answerable from deployed bytecode, chain state and public artefacts — which is precisely the point: diligence that depends on the subject's cooperation is not diligence. Run them in order, because the first two constrain the value of every answer that follows.

Related engineering

• Verify your instrument: the research discipline that decides whether your findings are real ›
• Invariant-driven design: what a conservation law proves, and the dimension it cannot see ›
• Provable staking solvency: an invariant anyone can check, any block ›
• The Nakamoto Test: five questions that measure any protocol against the original vision ›