About risk-assessment
risk-assessment is a skill for evaluating a DeFi protocol using its security history, oracle dependencies, treasury, fundamentals and yields. It guides users in assembling evidence and assigning risk levels to identified signals.
Key features
- 01Resolve protocol entities
- 02Review hack history
- 03Assess oracle dependencies
- 04Examine treasury and fundamentals
- 05Check yield sustainability
- 06Rate risk signals
Use cases
- 01Assess risks before using a protocol
- 02Review a protocol after a security incident
- 03Compare financial and yield risk signals
MCP support
The skill uses DeFiLlama MCP tools to retrieve protocol events, oracle metrics, treasury data, fundamentals and yield pools.
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ defillama/ defillama-skills --skill risk-assessmentAfter installing, type/risk-assessmentin Claude Code to confirm it loaded.
Details
From the project READMERisk Assessment
Evaluate the risk profile of a DeFi protocol by examining its security history, oracle dependencies, treasury, fundamentals, and yield levels.
Workflow
Step 1 - Resolve the protocol entity
defillama:resolve_entity
entity_type: "protocol"
name: "<user-provided name>"
Step 2 - Hack history
Check whether the protocol has been exploited before.
defillama:get_events
protocol: "<slug>"
event_type: "hacks"
Any past hacks are a significant risk signal. Note the date, amount lost, and whether funds were recovered.
Step 3 - Oracle dependencies
Identify which oracle the protocol relies on and how much value it secures.
defillama:get_oracle_metrics
Filter results for the protocol's oracle. Oracle metrics automatically
filter to tvl_component = 'base' and aggregate with SUM/GROUP BY to
exclude double-counted TVL. A protocol using a small or unproven oracle
has higher risk than one using Chainlink or Pyth.
Step 4 - Treasury health
Assess the protocol's financial reserves.
defillama:get_treasury
treasury: "<slug>"
A healthy treasury provides a safety net for bug bounties, insurance, and continued development.
Step 5 - Protocol fundamentals
Check TVL, revenue, and trends to evaluate sustainability.
defillama:get_protocol_metrics
protocol: "<slug>"
Key signals: Is TVL growing or declining? Is the protocol generating real revenue?
Step 6 - Yield analysis
Examine pool APYs for sustainability red flags.
defillama:get_yield_pools
protocol: "<slug>"
Risk Signals
Evaluate each factor and assign a risk level:
| Signal | Risk Level | Explanation |
|---|---|---|
| Recent hack (< 1 year) | HIGH | Protocol was recently exploited |
| Past hack (> 1 year), no recurrence | MODERATE | Was exploited but has since hardened |
| No hack history | LOW | No known exploits |
| No oracle or small oracle TVS | MODERATE | Oracle risk, potential manipulation |
| Uses Chainlink/Pyth with high TVS | LOW | Battle-tested oracle infrastructure |
| Treasury < $1M | HIGH | No meaningful safety net |
| Treasury > $10M | LOW | Strong financial reserves |
| APY > 100% from rewards only | HIGH | Likely unsustainable, token emissions |
| APY from real yield (fees) | LOW | Sustainable yield source |
| TVL declining > 20% in 30d | MODERATE | Users are leaving |
| Revenue declining with TVL | HIGH | Fundamentals deteriorating |
Output Format
Present the report with these sections:
- Risk Summary - Overall risk rating (LOW / MODERATE / HIGH) with a one-sentence justification.
- Security History - Hack incidents, amounts, and outcomes.
- Oracle Risk - Which oracle is used, TVS secured, reliability.
- Treasury Health - Total treasury value, composition, runway.
- Fundamental Health - TVL trend, revenue, user activity direction.
- Yield Sustainability - Are yields from real fees or emissions?
- Risk Factors - Bullet list of all identified risk signals with their severity level.
Tips
- No data from
get_eventsfor hacks is a positive signal, not missing data. - A protocol with high TVL but zero revenue may be subsidizing usage with token emissions - flag this.
- Compare treasury value to TVL: treasury < 1% of TVL means limited ability to cover losses.
- Multiple past hacks on the same protocol is a stronger negative signal than a single incident.