Join our Newsletter — 33% off our NHI Course
Home› Guides› DeFi Risk Guide: A Due Diligence Framework for…
Guide Fraud Prevention

DeFi Risk Guide: A Due Diligence Framework for Protocol Risk

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 8 November 2026 15 min read
On this page

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 categoryWhat failsDue diligence evidenceTypical mitigations
Smart contractLogic error, access control flaw, reentrancy, unsafe external callAudit reports matched to deployed bytecode, bug bounty, test coverage, verified sourceMultiple audits, formal verification of core invariants, bug bounty sized to value at risk
Upgrade and adminOwner or proxy admin key replaces logic or drains fundsList of privileged roles, multisig threshold and signers, timelock durationTimelock on upgrades, multisig with independent signers, renounced or limited roles
OraclePrice feed manipulated, stale or unavailableOracle source per asset, update thresholds, fallback logic, liquidity of reference marketsDecentralised oracle network, TWAP over long windows, circuit breakers on deviation
Liquidity and marketUsers cannot exit, collateral cannot be liquidated, impermanent lossPool depth, concentration of liquidity providers, slippage at your position sizePosition limits, exit modelling, conservative collateral factors
Leverage and liquidationCascading liquidations and bad debtCollateral factors, liquidation incentives, historical bad debt, reserve fundCaps per collateral asset, isolation modes, insurance or safety module
GovernanceVote captured, malicious proposal executedToken distribution, quorum, voting snapshot method, proposal delayPast-block snapshots, timelocks, guardian veto with limited scope
Dependency and bridgeWrapped or bridged asset loses its backing; stablecoin depegsEvery external token, bridge and stablecoin the protocol relies onLimits on bridged collateral, depeg circuit breakers
Operational and front endWebsite, DNS, deployer key or signing interface compromisedKey custody of deployers and signers, front-end hosting controls, incident planHardware keys, independent transaction verification, monitored deployments
Legal and regulatoryEnforcement, sanctions exposure, unclear liabilityResponsible persons, jurisdiction, AML controls of front endsLegal 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 IDRiskWhat to ask the protocol
SC01Access Control VulnerabilitiesWhich functions are privileged, who holds each role, and is every role behind a multisig or timelock?
SC02Price Oracle ManipulationWhich oracle prices each collateral asset, and what happens if it reports a 50% move in one block?
SC03Logic ErrorsWhich invariants (total supply, solvency) are tested or formally verified?
SC04Lack of Input ValidationAre user-supplied addresses, amounts and calldata validated on every external function?
SC05Reentrancy AttacksIs checks-effects-interactions followed and are reentrancy guards used on value transfers?
SC06Unchecked External CallsAre return values from token transfers and external calls checked?
SC07Flash Loan AttacksCan any price, balance or vote be changed and used within one transaction?
SC08Integer Overflow and UnderflowCompiler version and any unchecked arithmetic blocks.
SC09Insecure RandomnessDoes anything depend on block values for randomness?
SC10Denial of Service (DoS) AttacksCan 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.

  1. Scope the exposure: record the chain, contracts, tokens, position size and how long funds will be committed. Size of position drives depth of review.
  2. Map control points: list every privileged role, its holder, the multisig threshold and the timelock. Verify on-chain rather than from documentation.
  3. Review code assurance: audits matched to deployed code, open findings, bug bounty size, changes since last audit.
  4. Assess oracles and dependencies: oracle per collateral asset, bridged assets, stablecoins and other protocols relied on.
  5. 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.
  6. Check operations: incident response contacts, monitoring, front-end hosting and how signers verify transactions.
  7. 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).
  8. Decide and set limits: approve with a maximum exposure, exit triggers and a review date; start with a small pilot allocation.
  9. 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

SituationReasonable approach
Treasury parking stablecoins for yieldPrefer long-running lending markets with timelocked upgrades and decentralised oracles; cap exposure per protocol; avoid layered yield strategies.
Fund taking directional or LP exposureFull taxonomy review, impermanent loss and exit modelling, daily monitoring, pre-agreed exit triggers.
Exchange or custodian listing a DeFi tokenFocus on admin keys, mint functions, bridge backing and governance concentration.
Small team with limited security staffRestrict 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

ActivityFramework reference
Pre-commitment due diligenceNIST CSF 2.0 GV.SC-06; NIST SP 800-53 SR-6 Supplier Assessments and Reviews
Ongoing protocol monitoringNIST CSF 2.0 GV.SC-07, DE.CM-09
Code assurance evidenceNIST SP 800-53 SA-11 Developer Testing and Evaluation; OWASP Smart Contract Top 10
Upgrade governanceNIST SP 800-53 CM-3 Configuration Change Control
Responsible persons, conflicts, disclosureIOSCO DeFi Recommendations 2, 4 and 6
Operational and technology riskIOSCO DeFi Recommendation 5
Interconnection with wider marketsIOSCO 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

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

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org