Security & due diligence

A DeFi Risk Checklist: Contracts, Controls, and Exits

Build an evidence-based review of protocol identity, upgrades, audits, dependencies, reward sources, and withdrawal mechanics.

Reviewed · Educational guide

Cyan Verify Before You Trust typography card with an orange shield and check mark.

A useful DeFi review does not end with “audited,” “popular,” or “high yield.” Those words describe pieces of a story, not the whole system. Due diligence means gathering evidence about what a product does, which components it depends on, and what remains unknown when a decision is made.

This checklist is a framework for organizing that work. It is not a certification system, a numerical safety score, or a recommendation to invest. Completing every question cannot guarantee a favorable outcome. It can, however, make unsupported assumptions more visible and help explain why a decision should be paused.

Start with a one-sentence product description

Write what the product does without promotional language. Identify the deposited asset, the operation performed, the thing received, and the intended exit. If the description depends on several layers, name each one. A product that cannot be described clearly is not ready for a simple percentage-based comparison.

For example, a hypothetical description might say that an application accepts asset A, supplies it to lending market B, and issues a receipt redeemable under specified conditions. That sentence immediately creates useful questions about A, B, the receipt, and redemption. “Optimized passive yield” does not identify any of those dependencies.

Establish identity before evaluating claims

Verify the intended website, network, and contract addresses through independently checked official information. Record the deployment and version. A review of an earlier contract or another network does not automatically apply to the one you are about to use.

Keep a research log with the source, observation date, and exact point it supports. Distinguish evidence from inference. “The documentation lists this address” is different from “this contract has no risk.” Clear wording prevents a narrow verification result from expanding into a broad assurance that the evidence does not justify.

Ask who can change the system

Identify upgrade permissions, administrative roles, parameter changes, emergency pauses, and governance processes. Then consider how those controls interact. A public vote, a multisignature account, and a timelock serve different functions and should not be treated as interchangeable signs of decentralization.

Ask what can change without your individual consent and how much notice may exist. Also ask whether you could realistically exit during that notice period. A timelock is less useful to a holder whose assets are inaccessible until after it expires. Control analysis should be connected to withdrawal mechanics rather than kept in a separate box.

Read security reviews for scope and limits

An audit report can provide valuable evidence about the code and issues examined. It is not a guarantee that every bug, economic weakness, dependency, or future change has been addressed. Identify the reviewed version, date, scope, unresolved findings, and any relevant changes after the review.

Use a simple matching exercise: compare the system you intend to use with the system described in the report. Note differences. If you cannot establish that the deployed code corresponds to the reviewed code, write that uncertainty explicitly. Do not count a logo on a website as a substitute for reading the underlying report or understanding its boundaries.

Map external information and dependencies

A protocol may rely on price data, other contracts, token issuers, bridges, validators, or operational services. Identify what happens if one component is unavailable, delayed, manipulated, or simply behaves differently from the model. The more important the dependency, the less appropriate it is to hide it behind a general brand name.

For a lending example, ask how collateral and debt are valued and what happens during unusual price conditions. For a vault, identify the actual underlying strategies. For a bridged asset, trace the representation to its backing mechanism. The lending guide and bridge guide illustrate why a single interface can contain several distinct risk layers.

Trace the source and destination of value

Identify what generates revenue or rewards and who ultimately pays. Then describe how those proceeds reach the holder. Include fees, conversion steps, and token-price assumptions. If rewards mainly come from a temporary distribution, assess the product with that distribution removed.

A useful stress question is whether the activity would still have a reason to exist without the advertised incentive. The answer does not automatically determine whether a product is worthwhile, but it clarifies the economic thesis. Avoid using “real yield” or another label as a shortcut; insist on an explanation of cash flows and obligations.

Inspect liquidity and the exact exit

Write the withdrawal sequence in asset units. Identify queues, available liquidity, possible fees, additional trades, and any debt that must be repaid first. Distinguish receiving a receipt token from receiving the desired underlying asset. A market sale may be available even when direct redemption differs, but that market price is another variable.

Now create a stressed version of the exit. Assume that many other participants want to leave, transaction costs are inconvenient, or the usual interface is unavailable. The purpose is not to predict a specific crisis. It is to identify whether your plan depends on favorable conditions that may be least available when needed.

Examine concentration across the whole portfolio

Several positions can share one important dependency. Different vaults might use the same lending market. Different assets might depend on the same bridge or issuer. A collection of names does not necessarily provide a collection of independent failure points.

Create a matrix with positions as rows and dependencies as columns. Mark overlaps without pretending that the matrix produces a precise probability of loss. It is a visibility tool. Any decision about allocation or acceptable exposure requires personal context that this website does not possess and may warrant advice from a qualified professional.

Decide what would change your conclusion

Write conditions that would trigger another review: a contract upgrade, a changed withdrawal process, a new underlying strategy, an unexplained permission request, or a material change in the assumptions used for the position. This is more useful than saying you will “keep an eye on it” without defining what matters.

Also specify what information you do not have. Missing details about controls, accounting, or redemption are findings in their own right. A review can end with “insufficient evidence to proceed.” That is a complete and useful outcome, not a failure to be decisive. The purpose of research is to support a decision, including a decision not to act.

Keep an incident response proportional to the problem

A delayed transaction, an incorrect token, an exposed approval, and a compromised recovery phrase call for different analysis. Begin by documenting what is known and avoiding further unverified authorizations. Do not let an urgent message from an unknown person define the recovery process.

Maintain a list of verified documentation and support routes before they are needed. Never provide recovery phrases or private keys to support. Be cautious about services promising guaranteed recovery of lost funds. A response plan should reduce uncertainty and authority granted to others, not create a new chain of rushed transactions that cannot be explained.

Common due-diligence questions

Does high total value locked prove a protocol is safe?

No. A large displayed value describes a measurement under a particular methodology and time, not a proof about future contract behavior or solvency. Ask what is counted and whether values are duplicated through layered positions. Popularity can be a research clue, but it is not a replacement for examining the actual system.

Can an overall risk score replace this review?

A score can summarize a defined methodology, but it can also conceal assumptions, missing data, and trade-offs. Read the inputs, weights, and limits before relying on it. DefiFortune.com does not assign universal safety grades because a single label would imply more certainty than this educational framework supports.

Conclusion: keep evidence and uncertainty together

A strong review contains a clear product description, verified identity, a control map, security-review context, economic reasoning, and a realistic exit. It also records what remains unknown. That combination is more useful than confidence based on a familiar logo or an attractive rate.

For the limits and practices of contract-level assurance, see Ethereum's smart contract security documentation. Use the security hub, wallet guide, and editorial policy to understand how this site separates source-supported facts from illustrative analysis. This checklist is educational, not individualized financial advice.

Something unclear or inaccurate?

Send an editorial correction ↗