Why DeFi Lending Protocols Need Evidence-Backed Risk Scores

Protocol teams do not distrust risk scores because they dislike numbers. They distrust them because an unexplained number cannot be reviewed, challenged, or acted on.

If an alert says "risk is high" and a signer asks "why?", the system has already failed. The on-call engineer will either ignore it or spend the next twenty minutes reconstructing logs. In a live lending market, that delay is the product.

This article is for founders, security engineers, and DAO risk contributors who have to decide whether a score is worth paging a human.

Why This Matters

Lending protocols already have dashboards. Many already have bots. What they often lack is a shared evidence standard: the minimum packet a reviewer should receive before they treat a score as operational.

Without that standard:

• Night-shift responders cannot reconstruct the claim.
• Day-shift researchers cannot compare incidents.
• Signers cannot tell a real threshold breach from a noisy spike.
• After the fact, nobody can audit what the system believed at the time.

Evidence-backed scoring is how a monitoring product earns the right to interrupt people.

What Evidence-Backed Means

A score is evidence-backed when a reviewer can see, in one place:

• The protocol and chain
• The time windows used (for example 30 minutes, 24 hours, 7 days)
• The factors that moved, with direction and magnitude
• The raw event counts behind those factors
• Freshness: when ingest last succeeded
• Confidence: whether coverage and sample size support action
• Explicit non-coverage: which factors are not implemented yet

If any of those are missing, the number is a hint, not a decision input.

The product page describes BlockSentinel's Phase 1 score as rule-based and explainable. That is a constraint, not a slogan: we would rather show three implemented factors clearly than hide ten behind a black box.

Good Factor Examples

Phase 1 lending factors that can be explained from event logs include:

Factor	Evidence a reviewer should see
Borrow pressure	Borrow count vs recent baseline for the same bucket
Liquidation stress	LiquidationCall count and clustering in the window
Same-transaction anomalies	Borrow/repay (or similar) pairs sharing a transaction hash
Freshness	Last successful eth_getLogs window and lag
Confidence	Coverage flags plus whether enough recent buckets exist

Oracle paths and full reserve-health models can appear later. Until they are implemented, they should be labeled implemented: false, not silently zeroed. Silent zeros teach teams the wrong lesson: that the system "looked at oracles" when it did not.

Confidence and Freshness

Two scores of 80 are not equal.

• Score A: 80, last ingest 3 minutes ago, three factors populated, 48 hours of history.
• Score B: 80, last ingest 47 minutes ago, one factor populated after an RPC gap.

A responsible packet prints that difference. Freshness is not a nice-to-have; it is how you know whether the score describes the chain or the outage.

Confidence should fall when:

• The lookback is too short.
• A factor is missing by design.
• Ingest skipped a range.
• Event volume is too low to support a z-score.

Teams can still look at a low-confidence score. They should not treat it like a high-confidence one.

How Scores Should Be Reviewed in Incident Response

A practical review order:

1. Confirm freshness. If ingest is stale, fix the pipe before arguing about the number.
2. Read top factors, not the headline score.
3. Open the evidence: counts, windows, example transaction hashes if available.
4. Compare to the protocol's own thresholds (risk 7d, confidence floor, persistence).
5. Decide: watch, escalate, or prepare a bounded proposal.
6. Write down the decision so the next reviewer is not starting from Slack memory.

That sequence is the difference between "we got an alert" and "we ran an operation". A checklist version lives in the monitoring checklist. Guard packaging is covered in alert noise to guard proposals.

Hypothetical review

Alert: RISK_ALERT#HIGH#2026-08-13T18:00. Risk 7d 81, confidence 0.64, freshness 6 minutes.

Top factors: borrow pressure +28, liquidations +22, same-tx +12. Oracle factor: not implemented.

Action: page the risk channel, not the whole signer set. Ask one engineer to inspect the three tx hashes in the packet. Do not freeze an asset from this score alone. If liquidations continue into the next 30-minute bucket and confidence rises, then assemble an advisory proposal.

What This Does Not Prove

A high score does not mean:

• An exploit is in progress
• A specific attacker is involved
• The protocol should change parameters
• BlockSentinel would have stopped a historical incident

It means: these event-derived features moved enough, recently enough, with enough coverage, that a human should look. That is a narrower claim, and a more useful one.

How BlockSentinel Approaches This

BlockSentinel stores latest and historical scores with coverage metadata so a reviewer can see what the engine actually computed. Alerts are deduped inside a window so the same 7d breach does not page every five minutes. Guard JSON is produced only from allowlisted actions, and only as a proposal.

If you want the integration shape, start with docs. If you want the category framing, read exploit-risk intelligence.

Next Step

If your team currently receives scores you cannot explain in a standup, request a pilot conversation. The first question we will ask is not "do you want more alerts". It is "what would a signer need to see".