A lending market offers an attractive yield, two audit badges, and high total value locked, but one concentrated upgrade key can replace its code immediately. Deciding whether and how much to expose requires assembling incomplete evidence rather than trusting one indicator. Audits examine bounded code, bounties invite reports, and governance records reveal some administrative behavior; each contributes a different piece and carries different blind spots.
A rigorous review begins with loss scenarios rather than yield, reputation, or interface quality. Ask what assets can leave, which conditions authorize movement, what dependencies can supply false information, who can change the rules, and whether users can exit during stress. The result should be a documented risk position with uncertainty, not a permanent safe-or-unsafe label.
What you will learn
- Build a protocol map linking assets, contracts, privileged roles, and dependencies
- Weight audits, bounties, maturity, and incidents without turning any signal into proof
- Create scenario-based exposure limits and monitoring triggers
Define scope and asset flow
Write down the exact product, chain, contract addresses, deployment version, and intended action. A protocol name may cover several markets, vaults, front ends, and deployments with different controls. Depositing a stablecoin into one isolated pool is not equivalent to buying its governance token or using an automated vault that routes through several external applications.
Trace asset flow from the user wallet to its final custody and accounting location. Identify receipt tokens, withdrawal queues, conversion steps, and who can redirect funds. Note which blockchain transactions are essential and which front-end or offchain services merely help construct them. This map prevents a brand-level audit from being mistaken for evidence about every route.
Test evidence against the live system
For each audit, confirm code revision, scope, severity method, unresolved findings, and relation to deployed contracts. Read at least the executive summary and exclusions instead of counting logos. Review bounty coverage and maximum award relative to assets at risk, recognizing that a bounty attracts reports but neither forces disclosure nor proves researchers examined every component.
Operational maturity appears in monitoring, incident reports, post-mortems, paused-market records, recovery exercises, and communication quality. A protocol with no reported incident may be secure, lightly tested, or poor at disclosure. Treat absence of evidence carefully. Favor teams that identify root causes, quantify impact, distinguish confirmed facts from hypotheses, and document control changes after failure.
Map dependencies and economic limits
List price feeds, bridges, stablecoins, tokens, liquidity venues, keeper networks, rollups, cloud services, and governance dependencies. For each, record what failure reaches the protocol and whether exposure is capped. Correlated dependencies deserve attention: several assets may ultimately rely on one bridge, one issuer, or one liquidity source despite appearing diversified.
Model at least three scenarios: a contract defect, a privileged-key compromise, and a dependency failure during congestion. Estimate which assets could leave, how quickly, what controls intervene, and whether exits compete for limited liquidity. Exact probabilities are usually unavailable, so use scenarios to bound consequences and identify controls rather than manufacture a precise risk score.
Convert review into an operating decision
Set exposure according to maximum tolerable loss, not headline return. Define entry conditions, concentration limits, required liquidity, approval scope, and monitoring triggers such as an unreviewed upgrade, disabled oracle, abnormal reserve movement, or sustained withdrawal delay. Reassess after deployments and governance changes because security evidence decays when the system changes.
Document what remains unknown and what would change the conclusion. A useful review may end with no exposure because authority is opaque, a small capped exposure because controls are plausible but young, or a larger operational allocation with continuous monitoring. The framework supports disciplined decisions; it cannot eliminate unknown defects, dishonest insiders, or simultaneous failures.
Common misconceptions
“Higher total value locked proves a protocol is safer.”
TVL measures deposited value under particular definitions. It can attract testing, but also attackers, and says little about permissions, dependencies, or loss containment.
“Several audits are always better than one.”
Count is weak without scope, recency, depth, deployment match, and remediation. Several narrow reviews may leave the same critical component untouched.
“A due-diligence checklist produces an objective security score.”
Evidence quality and failure consequences require judgment. Numeric scores can conceal uncertainty and false precision unless their assumptions remain visible.
Risks and limitations
- Public documentation may omit informal controls, signer relationships, liabilities, or undisclosed dependencies.
- A review becomes stale after upgrades, listings, governance changes, or shifts in underlying liquidity.
- Scenario analysis can miss novel interactions and cannot assign reliable probabilities to unknown exploits.
- Onchain transparency shows transactions and code more readily than offchain coercion, legal risk, or compromised development environments.
Key takeaways
- Evaluate the exact deployment and action, not the protocol brand.
- Trace asset flow, ultimate authority, dependencies, and exit conditions.
- Match each audit to live code and read its exclusions.
- Use scenarios to bound losses without inventing precise probabilities.
- Turn findings into exposure limits, triggers, and reassessment dates.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.