DeFi Protocol Monitor
Monitor TVL, oracle deviation, and protocol-level health so your team can spot real degradation before users do.
Why teams use this monitor
For DeFi teams, uptime alone is not enough. A protocol can be technically online and still be in trouble because liquidity, TVL, or oracle quality changed quickly.
- DeFi teams with one protocol or one key market to protect
- Ops teams that already know the protocol slug they care about
- Teams that need a product-level signal beyond RPC health
Quick start in 5 minutes
- Start with the protocol slug you already use operationally in DefiLlama or internal runbooks.
- Use DefiLlama as the first TVL source unless you have a stronger internal subgraph or custom oracle feed.
- Pick one meaningful TVL drop threshold and one oracle deviation threshold before expanding the monitor.
Configuration notes
| Field | What to know |
|---|---|
| protocolSlug | This should match the DefiLlama slug you expect to monitor. It is the most common setup issue. |
| tvlSource | Use defillama first. Move to subgraph only if you need protocol-specific data or already operate that dependency. |
| tvlDropThresholdPercent | Treat this as “when should someone investigate,” not “when did something catastrophic happen.” |
| oracleDeviationThresholdPercent | Keep this tight only if oracle freshness is part of your production risk model. |
Recommended thresholds and defaults
- 10-15% TVL drop in 24h is a reasonable starting point for established protocols.
- Keep oracle deviation thresholds tighter than TVL thresholds if liquidations depend on them.
- If you do not have an operational use for subgraphUrls yet, leave them out and keep the first monitor simple.
Ready-made examples
Aave market TVL drop
Use a conservative market-health baseline for a major protocol.
Best for
Teams monitoring established lending markets
- Protocol slug aave
- TVL drop at 12%
- Oracle deviation at 3%
{
"protocolName": "Aave",
"protocolSlug": "aave",
"chainId": 1,
"tvlSource": "defillama",
"tvlDropThresholdPercent": 12,
"oracleDeviationThresholdPercent": 3,
"checkIntervalSeconds": 300
}Uniswap pool health
Keep an eye on TVL erosion and rate movements for a major liquidity venue.
Best for
DEX teams and LP operations
- Protocol slug uniswap
- TVL floor at $50M
- 5 min checks
{
"protocolName": "Uniswap",
"protocolSlug": "uniswap",
"chainId": 1,
"tvlSource": "defillama",
"tvlDropThresholdPercent": 15,
"tvlMinimumUsd": 50000000,
"oracleDeviationThresholdPercent": 5,
"checkIntervalSeconds": 300
}Yield floor monitor
Start with a smaller protocol where TVL changes quickly.
Best for
Growth teams tracking volatile pools or newer DeFi markets
- Protocol slug pendle
- TVL drop at 8%
- 2 min checks
{
"protocolName": "Pendle",
"protocolSlug": "pendle",
"chainId": 42161,
"tvlSource": "defillama",
"tvlDropThresholdPercent": 8,
"oracleDeviationThresholdPercent": 4,
"checkIntervalSeconds": 120
}Alert example
Protocol health degradation
DeFi alert: TVL dropped beyond your configured threshold. Protocol: Aave 24h TVL change: -18.4% Suggested action: review withdrawals, market volatility, and correlated contract activity before escalating.
Troubleshooting
The monitor creates but data stays empty.
Check the protocolSlug first. Most empty DeFi monitors are a source-identifier mismatch, not a UI bug.
Too many TVL alerts during volatile markets.
Increase tvlDropThresholdPercent before lowering the check interval.
The team cannot act on oracle deviation alerts.
Either connect an incident runbook to them or remove that signal until it is operationally owned.