Decentralised finance (DeFi) protocols hold and move value through code, oracles and token-holder governance, and each of those layers can fail in ways that traditional financial due diligence does not look for. Losses in DeFi rarely come from a single bug: they come from a price feed that can be pushed, an upgrade key held by too few people, a governance vote that can be bought for one block, or a liquidity pool that empties under stress. This guide gives a risk taxonomy for DeFi protocols and a repeatable due diligence process covering smart contract, oracle, liquidity, governance, operational and legal risk. It is written for risk, security and investment teams at funds, treasuries, exchanges and fintechs assessing exposure to a protocol, and for protocol teams preparing for that scrutiny. For the wider landscape of wallets, keys and exchanges, start with the Web3 and Crypto Security Guide.
Key takeaways
- Decentralised does not mean ownerless. Most protocols have admin keys, upgrade paths or concentrated governance; find who can change the code and how fast.
- Oracles are the most exploited dependency. Any protocol that prices collateral from a thin on-chain market can be manipulated with borrowed capital in a single transaction.
- An audit is a point-in-time opinion, not a guarantee. Check what was audited, which version is deployed, and what changed since.
- Liquidity disappears exactly when you need it. Model exit under stress, including liquidation cascades and stablecoin depegs, not average conditions.
- Regulators look through the decentralisation claim. IOSCO and the CFTC both treat founders, developers and active governance participants as potentially responsible persons.
Why DeFi risk is different
A DeFi protocol replaces an intermediary with smart contracts on a public blockchain: lending pools, automated market makers (AMMs), derivatives and yield strategies that anyone can call. The Financial Stability Board's February 2023 report on the financial stability risks of DeFi concluded that DeFi inherits, and can amplify, the familiar vulnerabilities of traditional finance: operational fragilities, liquidity and maturity mismatches, leverage and interconnectedness. What is new is where those risks sit and who can act on them.
- The decentralisation illusion: the BIS Quarterly Review (December 2021) argued that some centralisation is unavoidable because no set of smart contracts can anticipate every contingency, and that blockchain consensus and insider token allocations tend to concentrate power. For due diligence this means identifying the real control points, not accepting the label.
- Composability: protocols build on each other's tokens and prices. IOSCO's December 2023 DeFi report notes that integrations and reused components add risk, so a failure in one protocol can propagate into every protocol that accepts its token as collateral.
- Atomic, borrowed capital: flash loans are uncollateralised loans repaid within the same transaction. The BIS paper describes how they can be used to move prices in AMM pools, and cites the Harvest exploit of October 2020 with about $27 million lost.
- Irreversibility: once a malicious transaction is final, recovery depends on negotiation, freezes by centralised stablecoin issuers or exchanges, or law enforcement, not on a chargeback.
A DeFi risk taxonomy
Use one taxonomy across every protocol so that assessments are comparable. The categories below follow the risk areas named by IOSCO Recommendation 5 (operational and technology risk, including smart contracts, oracles, bridges and governance) and the FSB's financial vulnerabilities.
| Risk category | What fails | Due diligence evidence | Typical mitigations |
|---|---|---|---|
| Smart contract | Logic error, access control flaw, reentrancy, unsafe external call | Audit reports matched to deployed bytecode, bug bounty, test coverage, verified source | Multiple audits, formal verification of core invariants, bug bounty sized to value at risk |
| Upgrade and admin | Owner or proxy admin key replaces logic or drains funds | List of privileged roles, multisig threshold and signers, timelock duration | Timelock on upgrades, multisig with independent signers, renounced or limited roles |
| Oracle | Price feed manipulated, stale or unavailable | Oracle source per asset, update thresholds, fallback logic, liquidity of reference markets | Decentralised oracle network, TWAP over long windows, circuit breakers on deviation |
| Liquidity and market | Users cannot exit, collateral cannot be liquidated, impermanent loss | Pool depth, concentration of liquidity providers, slippage at your position size | Position limits, exit modelling, conservative collateral factors |
| Leverage and liquidation | Cascading liquidations and bad debt | Collateral factors, liquidation incentives, historical bad debt, reserve fund | Caps per collateral asset, isolation modes, insurance or safety module |
| Governance | Vote captured, malicious proposal executed | Token distribution, quorum, voting snapshot method, proposal delay | Past-block snapshots, timelocks, guardian veto with limited scope |
| Dependency and bridge | Wrapped or bridged asset loses its backing; stablecoin depegs | Every external token, bridge and stablecoin the protocol relies on | Limits on bridged collateral, depeg circuit breakers |
| Operational and front end | Website, DNS, deployer key or signing interface compromised | Key custody of deployers and signers, front-end hosting controls, incident plan | Hardware keys, independent transaction verification, monitored deployments |
| Legal and regulatory | Enforcement, sanctions exposure, unclear liability | Responsible persons, jurisdiction, AML controls of front ends | Legal opinion, sanctions screening, exposure limits |
Smart contract and upgrade risk
The OWASP Smart Contract Top 10 (2025) is a useful checklist for what auditors and internal reviewers should have covered. Read it alongside the protocol's audit reports: an audit that does not discuss oracle or access control design for a lending protocol has a gap.
| OWASP ID | Risk | What to ask the protocol |
|---|---|---|
| SC01 | Access Control Vulnerabilities | Which functions are privileged, who holds each role, and is every role behind a multisig or timelock? |
| SC02 | Price Oracle Manipulation | Which oracle prices each collateral asset, and what happens if it reports a 50% move in one block? |
| SC03 | Logic Errors | Which invariants (total supply, solvency) are tested or formally verified? |
| SC04 | Lack of Input Validation | Are user-supplied addresses, amounts and calldata validated on every external function? |
| SC05 | Reentrancy Attacks | Is checks-effects-interactions followed and are reentrancy guards used on value transfers? |
| SC06 | Unchecked External Calls | Are return values from token transfers and external calls checked? |
| SC07 | Flash Loan Attacks | Can any price, balance or vote be changed and used within one transaction? |
| SC08 | Integer Overflow and Underflow | Compiler version and any unchecked arithmetic blocks. |
| SC09 | Insecure Randomness | Does anything depend on block values for randomness? |
| SC10 | Denial of Service (DoS) Attacks | Can unbounded loops or a single failing call block withdrawals? |
- Audit hygiene: ethereum.org's smart contract security guidance warns that audits will not catch every bug and should be one layer alongside testing, static analysis, fuzzing, bug bounties and, for critical logic, formal verification. Confirm that the audited commit matches the verified source of the deployed contract, and list every change deployed since the last audit.
- Upgradeability: proxy patterns separate storage from logic so the logic address can be swapped. That is a feature for fixing bugs and a direct path to theft if the proxy admin key is compromised. Record who can upgrade, the multisig threshold (for example 3-of-5 or 4-of-7) and the timelock delay, and whether you would have time to exit after an upgrade is queued.
- Emergency controls: a pause or emergency stop limited to vulnerable functions is a positive sign if it is restricted and monitored; an unrestricted admin who can move user funds is a red flag.
- Track record: ethereum.org records that The DAO hack took 3.6 million ETH, and that a Parity wallet issue left over $300 million of ETH locked permanently. Old incidents still show which design patterns fail.
Oracle and price manipulation risk
Smart contracts cannot read off-chain data by themselves, so protocols rely on oracles. ethereum.org frames the oracle problem as three questions: is the data correct, is it available on time, and are providers rewarded for accuracy and penalised for errors. A single centralised oracle fails all three if its operator is hacked or goes offline.
- Spot price from a thin pool: the classic failure. An attacker borrows a large amount, trades to move the pool price, borrows against inflated collateral in the target protocol, then unwinds. ethereum.org recommends decentralised oracle networks and, for on-chain feeds, a time-weighted average price (TWAP) over longer windows because flash loans can only skew spot prices briefly.
- Stale or paused feeds: check heartbeat and deviation thresholds per asset and what the protocol does when an update is late.
- Self-referential collateral: a protocol that accepts its own governance token as collateral, priced from a market it dominates, can be drained by pushing that price.
- Depeg handling: decide whether a stablecoin is priced at a hard-coded 1.00 or at market. Hard-coded prices hide depegs; market prices can trigger liquidations on a temporary wick.
Liquidity, leverage and liquidation risk
DeFi lending is usually over-collateralised, but the BIS notes that borrowed funds can be reposted as collateral, building large exposures from small capital, and that forced selling amplifies price falls because DeFi has no shock absorbers comparable to banks.
- Liquidation mechanics: in Aave, a position becomes eligible for liquidation when its health factor falls below 1.0, and liquidators earn a bonus on seized collateral that rises as the health factor falls. Check whether liquidators can actually act in a crash: if gas spikes or the collateral market is illiquid, liquidations stall and the protocol takes bad debt.
- Impermanent loss: liquidity providers in a constant-product AMM end up with less value than simply holding when prices diverge. Uniswap's documentation gives the formula and examples: a 2x price change costs about 5.7% relative to holding, a 5x change about 25.5%, in either direction. Trading fees may or may not offset it. Concentrated liquidity adds out-of-range risk: positions stop earning fees and can end up holding only one asset.
- Exit capacity: measure slippage for your full position size, the share of liquidity held by the top ten providers, and withdrawal queues or cooldowns. A pool that is deep on average can be shallow after a large provider exits.
- Utilisation: in lending pools, depositors cannot withdraw what has been lent out. High utilisation is a liquidity warning even when the protocol is solvent.
Governance and admin key risk
Governance token holders vote on parameters, upgrades and treasury spending, much like shareholders. IOSCO's report describes DeFi governance as often opaque, unpredictable and easy to manipulate, and notes that attackers who compromise access control points can change parameters, interfere with governance or bypass multi-signature protections.
- Vote buying with flash loans: if voting power is measured at execution time, it can be borrowed for one block. ethereum.org recommends measuring voting power at a past block or weighting votes by lock time, plus a timelock between approval and execution.
- Concentration: calculate how many addresses are needed to reach quorum and to pass a proposal. If the team and early investors can pass anything, governance is centralised in practice.
- Signer independence: a 4-of-7 multisig where all signers work at the same company, use the same signing interface, or keep keys on everyday laptops is weaker than it looks. See the Multisig Treasury Operations Guide for Protocols and Companies.
- Legal exposure: in September 2022 the CFTC charged bZeroX and its founders over the bZx protocol and filed a complaint against the Ooki DAO, finding the DAO to be an unincorporated association whose active participating members were liable. IOSCO Recommendation 2 likewise lists founders, developers, governance token holders and holders of administrative rights as possible responsible persons. Institutions voting tokens should take legal advice on what that participation implies.
Running DeFi due diligence
A repeatable process makes assessments defensible to an investment committee or a regulator. Treat a protocol like any critical supplier: NIST CSF 2.0 GV.SC-06 calls for due diligence before entering a relationship and GV.SC-07 for ongoing monitoring of supplier risk.
- Scope the exposure: record the chain, contracts, tokens, position size and how long funds will be committed. Size of position drives depth of review.
- Map control points: list every privileged role, its holder, the multisig threshold and the timelock. Verify on-chain rather than from documentation.
- Review code assurance: audits matched to deployed code, open findings, bug bounty size, changes since last audit.
- Assess oracles and dependencies: oracle per collateral asset, bridged assets, stablecoins and other protocols relied on.
- Stress the economics: model a 30-50% collateral price drop, a stablecoin depeg and a top provider exit; estimate bad debt and your exit slippage.
- Check operations: incident response contacts, monitoring, front-end hosting and how signers verify transactions.
- Legal and compliance: sanctions exposure, responsible persons, and your own regulatory treatment (in the EU, see the MiCA and DORA for Crypto-Asset Service Providers Guide).
- Decide and set limits: approve with a maximum exposure, exit triggers and a review date; start with a small pilot allocation.
- Monitor continuously: alert on queued upgrades, role changes, large withdrawals, oracle deviations and governance proposals. See the Blockchain Analytics and On-Chain Monitoring Guide.
Decision guidance
| Situation | Reasonable approach |
|---|---|
| Treasury parking stablecoins for yield | Prefer long-running lending markets with timelocked upgrades and decentralised oracles; cap exposure per protocol; avoid layered yield strategies. |
| Fund taking directional or LP exposure | Full taxonomy review, impermanent loss and exit modelling, daily monitoring, pre-agreed exit triggers. |
| Exchange or custodian listing a DeFi token | Focus on admin keys, mint functions, bridge backing and governance concentration. |
| Small team with limited security staff | Restrict to a short approved list, smaller positions and third-party risk ratings as an input, not a substitute. |
Metrics to track
- Exposure concentration: share of DeFi assets in any one protocol, chain or stablecoin.
- Control coverage: percentage of approved protocols with upgrade timelocks of at least your required exit time.
- Assurance freshness: days since last audit relative to last code change, per protocol.
- Exit slippage: modelled slippage to exit 100% of each position, reviewed weekly.
- Alert response: time from a queued upgrade or role change alert to a documented decision.
Insurance and risk transfer
On-chain cover products and protocol safety modules can pay out after an exploit, but they are themselves smart contracts with their own governance, and cover terms often exclude economic attacks or require a claims vote. Read the exact trigger wording and treat cover as a partial offset, never as a reason to raise exposure limits.
Framework mapping
| Activity | Framework reference |
|---|---|
| Pre-commitment due diligence | NIST CSF 2.0 GV.SC-06; NIST SP 800-53 SR-6 Supplier Assessments and Reviews |
| Ongoing protocol monitoring | NIST CSF 2.0 GV.SC-07, DE.CM-09 |
| Code assurance evidence | NIST SP 800-53 SA-11 Developer Testing and Evaluation; OWASP Smart Contract Top 10 |
| Upgrade governance | NIST SP 800-53 CM-3 Configuration Change Control |
| Responsible persons, conflicts, disclosure | IOSCO DeFi Recommendations 2, 4 and 6 |
| Operational and technology risk | IOSCO DeFi Recommendation 5 |
| Interconnection with wider markets | IOSCO DeFi Recommendation 9; FSB DeFi report |
Common failure patterns
- Trusting the audit badge: the audited version differs from what is deployed, or the audit scope excluded the oracle and governance modules.
- Pricing collateral from spot: a single thin pool sets the price for a large lending market, inviting flash loan manipulation.
- Upgrade faster than exit: a 24-hour timelock is meaningless for a position that needs a week to unwind without heavy slippage.
- Ignoring dependencies: the protocol is sound but its main collateral is a bridged asset or stablecoin whose backing fails. See the Cross-chain bridge security guide.
- Governance as theatre: a handful of insider wallets can reach quorum, and voting power is measured at execution time.
- Blind signing: multisig signers approve what the interface shows without independently checking the transaction data.
Lessons from incidents
The Bybit hack of February 2025 involved a centralised exchange rather than a DeFi protocol, but it shows the operational layer that DeFi due diligence often skips. Attackers compromised a Safe{Wallet} developer's laptop, used active AWS session tokens to alter the web interface's JavaScript, and served a malicious transaction only to Bybit's addresses. The signers' signatures were genuine; the interface lied about what they were signing, and about $1.5 billion was taken. For any protocol or treasury, ask how signers verify transaction data independently of the front end, and who can change the code served to them. The incident also shows why the Lazarus Group Threat Actor Profile belongs in a DeFi threat model.
Practitioner checklist
- Use one risk taxonomy and scoring sheet for every protocol assessment.
- Verify every privileged role, multisig threshold and timelock on-chain.
- Match audit reports to deployed bytecode and list changes since the last audit.
- Identify the oracle for each collateral asset and test the impact of a manipulated or stale price.
- Model liquidation cascades, stablecoin depegs and exit slippage at full position size.
- Calculate governance concentration and check that voting uses past-block snapshots.
- Confirm signers verify transactions independently of any single web interface.
- Take legal advice before voting tokens or acting in governance.
- Set exposure limits, exit triggers and a review date for every approved protocol.
- Monitor upgrades, role changes, oracle deviations and large withdrawals continuously.
Standards and references
- IOSCO: Final Report with Policy Recommendations for Decentralized Finance (DeFi)
- Financial Stability Board: The Financial Stability Risks of Decentralised Finance
- Bank for International Settlements: DeFi Risks and the Decentralisation Illusion
- OWASP: Smart Contract Top 10
- ethereum.org: Smart Contract Security
- ethereum.org: Oracles
- Uniswap: Understanding Returns
- CFTC: Action Against bZeroX, Its Founders and Ooki DAO
Related NHI Mgmt Group resources: Web3 and Crypto Security Guide · Multisig Treasury Operations Guide for Protocols and Companies · Cross-chain bridge security · Crypto Scam and Drainer Guide