Technical due diligence on a blockchain or crypto company answers two questions for an investor or acquirer: does the technology do what the deck says, and what will it cost if it doesn't? It covers what any software target gets (architecture, code, security and the people the system depends on) and the risks that are specific to crypto: who controls the keys and the upgrade rights, whether the contracts running on-chain are the code that was audited, whether the cryptography is sound and correctly used, and what the system depends on outside its own code, such as bridges, oracles and the chain underneath. The result is a two-page red-flag summary for the investment committee, a full report and a 100-day plan with cost estimates.
These are the checks, in the order we run them.
1. What runs today, compared with the deck
Ask for the address of every deployed contract on every network and the version of every node, indexer and service the product runs. On a public chain, use is visible: whether the contracts are called, by how many addresses, and whether the product is on mainnet or still on a testnet. Anything the deck presents as live should show up on-chain.
2. Who holds the keys and the upgrade rights
List every privileged role: contract owners, upgrade admins, pausers, minters, bridge validators and multisig signers. For each one, find out who holds the key, how it is stored (a hardware security module, a custodian, a laptop), how many signatures an action needs and whether the signers are really independent of each other.
A signature threshold protects only as well as the separation between the people who hold the keys. In March 2022 the Ronin bridge needed five of its nine validator signatures to approve a withdrawal. Four of those validators belonged to one company, Sky Mavis, and an allowlist that let Sky Mavis sign for a fifth, run by the Axie DAO, had been granted months earlier and never revoked. Starting from one compromised employee, an attacker collected five signatures and withdrew 173,600 ETH and 25.5 million USDC.
3. Whether the deployed code is the audited code
Collect the audit reports and note what each one covered: which repository, which commit, which contracts. Then check that the bytecode deployed on-chain matches the source code at that commit. Sourcify, for example, reports an exact match when the deployed bytecode is byte for byte the compilation output of the source (excluding libraries and immutables), and a match when only the metadata hash differs. As its documentation says, "a verified contract does not necessarily mean it is safe to interact with it"; verification proves you are reading the code that runs, nothing more. Then check which audit findings were fixed, and whether anyone reviewed the fixes.
Upgradeable contracts need one more step. Behind a proxy, whoever holds the upgrade key can replace the code users interact with after the audit. In the words of ethereum.org's documentation, users "must trust developers not to modify smart contracts arbitrarily". Find out who can upgrade, whether a multisig or a governance vote stands in the way, and whether an upgrade takes effect immediately or after a delay. That takes you back to step 2.
4. Whether the cryptography is sound and correctly used
Find out which cryptography the product depends on: signature schemes, zero-knowledge proof systems, hash functions, randomness. Established, audited libraries used as documented are the good case. We look hardest at home-made constructions, forks of libraries that no longer follow upstream fixes, and circuits nobody outside the team has reviewed.
The details decide. A zero-knowledge circuit that is missing one constraint can prove false statements. BLS signature aggregation that simply adds public keys, with no proof of possession or other defence against rogue keys, lets a single participant forge an aggregate signature, as our note on BLS signature aggregation explains.
5. What the system depends on outside its own code
Bridges, oracles, the chain the product runs on, sequencers, RPC providers, custodians and AI models. For each, ask what happens to the product if it stops, misbehaves or changes its terms, and who carries the loss. For AI models, also ask what they cost per customer and who owns the data.
6. Architecture, code and tests
How the system is built and tested, how much of it the tests cover and what will break first at ten times the load. For a protocol that includes consensus, finality and how nodes behave when peers fail or lie; for an application, the indexers and back-end services the front end quietly depends on.
7. Security posture and incident history
How keys, secrets and customer data are handled, and what happened in the last incident. Ask for post-mortems, the bug bounty and what it has paid out, and whether on-chain activity is monitored with a way to pause contracts. Whoever can pause is another privileged role for step 2.
8. Team and key people
Who can change the system safely today, and what happens if one of them leaves. With your agreement, we interview the people who wrote the code. It is the fastest way to the truth.
9. What fixing it costs
Every red flag gets a fix and a cost estimate in the 100-day plan, so the committee can weigh it against the price rather than against a feeling.
How we run it
We sign the NDA and check for conflicts before any material is shared. We provide Dusk's technology leadership, so we disclose the Dusk connection in the engagement letter and decline targets that compete with Dusk or depend on it. The evidence comes from the data room, code access and interviews. The red-flag summary comes first, then the full report and a call with your deal team, timed to your committee date. The report is a technical opinion on technology, security and team, not investment, legal, accounting or regulatory advice.
Sources
- Ronin Network, Community Alert: Ronin Validators Compromised ↗, 29 March 2022, and Back to Building: Ronin Security Breach Postmortem ↗, 27 April 2022. Both are archived copies; the original pages are no longer online.
- Sourcify: Exact Match vs Match ↗
- ethereum.org: Upgrading smart contracts ↗
- Technical due diligence: what the report contains
This is the kind of work we do in technical due diligence. If you have a target to assess, start a project.
