| name | risk-assessment |
| description | Protocol and DeFi risk evaluation covering hack history, oracle dependencies, treasury health, TVL concentration, and yield sustainability. Use when the user asks "is X safe", "how risky is", protocol security, risk analysis, or wants to evaluate risk before investing or depositing funds.
|
Risk 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_events for 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.
