Decentralized finance combines smart contracts, market incentives, collateral, liquidity, governance, and external data into financial services that can operate continuously. The same composability that makes DeFi useful also makes risk travel quickly. A lending protocol can depend on a stablecoin, an oracle, a bridge, a governance multisignature, several liquid markets, and a user interface controlled by a separate company.

DeFi diligence should therefore treat a protocol as a network of dependencies rather than a single contract. The goal is to identify where losses can originate, how they propagate, which actors can intervene, and whether the protocol has enough time, liquidity, and authority to contain the event.

Begin with a system and dependency map

List every component required for a normal user action. For a collateralized loan, that may include wallet software, the application interface, smart contracts, collateral token, debt asset, price oracle, liquidation bots, decentralized exchanges, a Layer 2 bridge, governance, and an emergency council.

Mark each dependency as replaceable, replaceable with delay, or not practically replaceable. An interface can often be replaced quickly. A canonical bridge, core oracle, or upgrade key may be much harder to replace during stress. Concentrated dependencies deserve more diligence than a count of integrations suggests.

Then identify feedback loops. Falling collateral prices may trigger liquidations, which create more selling, which worsens oracle prices and drains liquidity. A stablecoin depeg may reduce collateral value and increase debt value at the same time. The map should show these loops before numbers are added.

Smart contract risk is broader than code quality

Audits, formal verification, test coverage, bug bounties, and public code can reduce risk, but no control proves that a contract is safe. Review the exact deployed code, compiler settings, proxy pattern, libraries, privileged functions, and integration assumptions.

Check invariants and economic behavior

A contract can execute exactly as written and still produce an economic failure. Identify invariants that should always hold: liabilities should not exceed assets beyond defined limits, collateral factors should constrain borrowing, interest should accrue consistently, and shares should redeem for the expected claim.

Use historical incidents from comparable designs to create tests. The strongest review combines source-code analysis with adversarial economic scenarios.

Review upgradeability and emergency powers

Identify who can upgrade contracts, change risk parameters, pause markets, seize or recover assets, list collateral, modify oracles, or redirect fees. Record signer identities where disclosed, threshold, timelock, hardware and key practices, geographic or organizational independence, and the process for replacing a signer.

Emergency controls are not automatically a weakness. They can reduce losses when used carefully. The risk is unbounded or opaque authority.

Protocols often need prices that cannot be derived safely from one on-chain pool. Review data sources, aggregation, update frequency, deviation thresholds, heartbeat, chain congestion behavior, fallback logic, and manipulation resistance.

Ask what happens when the oracle stops updating. Does the protocol freeze borrowing, continue using a stale price, switch to a fallback, or allow governance to intervene? Each choice distributes losses differently.

Model price divergence across venues. During stress, centralized exchanges, decentralized pools, and oracle feeds can show different prices because of withdrawal limits, bridge delays, or fragmented liquidity.

Collateral quality determines the loss boundary

A collateral list is a portfolio. Review volatility, liquidity, concentration, correlation, custody, governance, redemption, and price-source quality for each asset.

Calculate liquidation value under stressed depth. Apply slippage, gas or execution costs, bridge delays, and oracle lag. Examine borrower concentration and wallet relationships; one large account may dominate system risk.

For liquid staking tokens, vault shares, and LP tokens, unpack the layers. Their price can depend on the underlying asset, smart contract, validator set, redemption queue, and secondary-market liquidity. A haircut should reflect the weakest link, not only historical volatility.

Liquidation design can stabilize or accelerate a crisis

Document the trigger, bonus, close factor, auction design, bad-debt treatment, and eligible liquidators. High bonuses attract liquidators but increase borrower losses and selling pressure. Low bonuses may fail to compensate execution risk.

Test network congestion and sequencer downtime. A protocol may appear overcollateralized while liquidators are unable to submit transactions.

Bad debt must go somewhere: reserves, an insurance fund, governance token holders, lenders, or socialized losses. Quantify the capacity and replenishment mechanism of each backstop.

Liquidity is a state, not a permanent property

Total value locked does not guarantee exit liquidity. Separate supplied assets, borrowed assets, protocol-owned liquidity, locked collateral, and rehypothecated positions. Measure executable depth by venue and size.

Liquidity can disappear when it is most needed. Market makers may reduce risk, LPs may withdraw, bridges may slow, and stablecoin issuers may restrict redemption. Stress tests should assume several channels weaken together.

Also review liquidity concentration. A protocol that relies on one pool, one market maker, or one exchange route can fail even when aggregate ecosystem liquidity looks large.

Composability creates hidden leverage

A DeFi position may be deposited, borrowed against, wrapped, bridged, placed in a vault, and used again as collateral. Each layer can report value, making gross metrics appear larger than the independent capital supporting them. Trace assets to their original source and identify recursive loops.

Leverage can be explicit through borrowing or implicit through derivative tokens and liquidity positions. Model how a shock affects collateral value, debt, funding costs, and redemption simultaneously.

Dependency risk should be monitored by exposure, not logo count. A protocol integrated with twenty applications may still derive most economic activity from one leveraged strategy.

Governance risk changes the protocol after investment

Map voting power, delegation, quorum, proposal thresholds, timelocks, and veto or guardian authority. Determine whether token borrowing can influence votes and whether large delegates have conflicts with service providers, investors, or competing protocols.

Review actual governance behavior. How quickly are proposals discussed? Are risk changes supported by analysis? Do voters approve treasury grants without milestones? Has governance acted during incidents? A formal system can be decentralized while practical participation is narrow.

Treasury governance deserves separate attention. Native-token treasuries can look large at market prices but may have limited purchasing power without causing price impact. Review diversification, stable reserves, recurring expenses, and obligations to incentive programs.

Stablecoins and bridges deserve their own risk modules

Stablecoins often serve as debt assets, collateral, liquidity pairs, and accounting units. Evaluate reserve or collateral design, redemption, governance, concentration, and the protocol’s response to a depeg.

Bridges introduce message verification, validator, liquidity, and upgrade risk. Determine whether the protocol recognizes bridged representations as collateral and what happens if the bridge pauses or an asset is disputed. Native issuance and canonical bridging can have different recovery paths.

Use the stablecoin diligence framework for deeper analysis of reserve and redemption risks.

Users may depend on a hosted interface, domain name, API, cloud provider, analytics service, and wallet integration. The contracts may remain live when these services fail, but many users will not have a practical route to manage positions. Determine whether alternative interfaces and documented contract interactions exist.

Operational teams manage releases, monitor risk, coordinate incident response, and communicate with users. Evaluate staffing, on-call coverage, runbooks, disclosure quality, and prior incident handling. “Decentralized” does not eliminate operational work.

Legal and regulatory developments can affect interfaces, service providers, governance participants, stablecoin access, and eligible users. Map which parts of the system require identifiable organizations and which can continue independently.

Run multi-factor stress scenarios

Single-variable shocks understate DeFi risk. Build scenarios that combine price moves, congestion, oracle delay, liquidity withdrawal, and governance or operational constraints. For example: collateral falls forty percent, the main Layer 2 sequencer pauses, a stablecoin trades below par, and liquidators face high execution costs. Estimate bad debt, reserve use, user behavior, and recovery time.

A second scenario might involve a smart-contract exploit in a major dependency, causing its receipt token to depeg while a bridge pauses. A third might test a governance attack during low participation. The numbers can be ranges; the purpose is to discover nonlinear loss paths.

Document which controls work automatically and which require human action. Time-to-detection and time-to-decision can be as important as nominal capital buffers.

Maintain a live risk dashboard

Track collateral concentration, borrower concentration, utilization, liquidations, bad debt, oracle freshness, market depth, stablecoin deviations, bridge balances, admin actions, governance proposals, contract upgrades, reserve funds, incentive spending, and dependency incidents. Set thresholds that trigger review rather than relying on informal attention.

Connect protocol risk to portfolio exposure. Several positions may depend on the same stablecoin, bridge, oracle, Layer 2, custodian, or governance group. Aggregate those dependencies in the broader investment framework.

Conclusion: map how failure travels

DeFi analysis is strongest when it explains propagation. A code bug can create bad debt; bad debt can trigger governance action; governance action can dilute a token; dilution can weaken incentives; weaker incentives can reduce liquidity. The visible protocol may be only the first link.

A system map, control map, liquidity model, and multi-factor stress test make risk concrete. They do not remove uncertainty, but they show where capital is exposed and which evidence would justify a larger or smaller position. In composable markets, the investor’s edge is often not predicting the first failure. It is understanding what the failure reaches next.

Primary reference: The Financial Stability Board’s report on the financial-stability risks of decentralized finance describes vulnerabilities, transmission channels, and links between DeFi and traditional finance.