A Practical DeFi Lending Risk Monitoring Checklist

This is a working checklist for teams who already know they need monitoring and want to stop arguing about the shape of it.

It is written for protocol operators, security engineers, and DAO risk contributors on Ethereum lending markets. It is not a generic "secure your crypto" list. If you want the category framing first, read exploit-risk intelligence.

Why This Matters

Monitoring programs fail in quiet ways: the wrong contract is watched, topic0 hashes are guessed, thresholds are copied from another protocol, Slack is the only owner, and nobody rehearses what happens after a high alert.

A checklist will not make those problems disappear. It makes them visible before an incident does.

Protocol Configuration

Confirm, in writing:

• Chain is Ethereum mainnet for the first deployment.
• Pool / market contracts are the live addresses, not docs examples.
• Configurator or guard targets are listed only if you actually want proposals against them.
• Event signatures come from ABI (Borrow, Repay, LiquidationCall, or your equivalents), not from a blog post.
• Topic0 values are computed, then checked against a recent log.
• Markets in scope are named (asset list), including which ones are out of scope.
• A human owner exists for this config, not "the security channel".

If an address still says placeholder, it is not in production. BlockSentinel's own onboarding list is in docs.

Event Monitoring

• Ingest uses eth_getLogs with a bounded block range.
• Confirmations are required before a block is treated as final enough to score.
• Failed RPC calls retry, then record an error instead of silently skipping forever.
• Raw logs land in durable storage (for example S3) before feature code mutates them.
• Duplicate batches are ignored.
• Last processed block is visible to operators.
• You can answer "how stale is the data?" in one lookup.

If you cannot point to last_run_ts and logs_count, you do not have monitoring. You have a hope.

Risk Thresholds

Write numbers down. Defaults without owners become folklore.

Setting	Example starting point	Owner must confirm
Risk 7d alert	70	Yes
Risk 7d guard consider	80	Yes
Confidence floor	0.6	Yes
Persistence	2 consecutive windows	Yes
Dedupe window	30 minutes	Yes
Max block range per ingest	2000	Yes

Do not copy another protocol's numbers because TVL looks similar. Utilization, liquidation mechanics, and user mix differ.

How those numbers get explained is in evidence-backed risk scores.

Alert Channels

• Slack and/or email exist for at least two humans.
• Severity is in the message (not only in a dashboard).
• Top factors are in the message.
• A link to the protocol's risk view exists, even if it is an API for now.
• Duplicate identical alerts in the same window are suppressed.
• A "this is not legal or financial advice" line is fine; a fear headline is not.

If the only output is a CloudWatch log, it is not an operations channel.

Escalation

Write a one-page matrix:

Condition	Who is paged	Who is not
Medium, confidence below floor	Risk channel, no signers	Tokenholders
High, fresh data, persistence met	On-call security + risk	Marketing
Ingest down > 15 minutes	Whoever owns RPC	Signers
Guard proposal created	Designated reviewers	Everyone in Discord

Practice it once with a tabletop. An unread runbook is decoration.

A fuller version is the incident response runbook.

Guard Review

• Guard mode is explicit: off, notify only, JSON only, or Safe draft.
• JSON only is the default until a rehearsal has happened.
• Allowlisted actions name real contracts and signatures.
• Pause-the-world is off until you have practiced it.
• Expiry and cooldown exist.
• Rejections are stored, not deleted because "nothing happened".

Details: from alert noise to guard proposals and the security model.

Post-Incident Learning

After any high window, even if you took no chain action:

• Export the evidence bundle (score, factors, counts, freshness).
• Note what the team believed vs what they later learned.
• Adjust thresholds only with a written reason.
• Check whether ingest gaps caused the scare.
• Decide if a market should be added or removed from scope.

Learning is part of monitoring. Otherwise you will relitigate the same spike every month.

Example: First 30 Days

Week 1: config and topic0 verification against a known Aave-style pool, no alerts to humans. Week 2: Slack on medium+, JSON_ONLY proposals generated but not sent to signers. Week 3: tabletop with a fake liquidation cluster. Week 4: confidence floor tuned after two noisy weekends.

That is slower than "turn it all on". It is also how you avoid training the team to ignore you.

How BlockSentinel Approaches This

BlockSentinel's Phase 1 engine is built to make this checklist concrete: protocol packs, ingest state, evidence-bearing scores, deduped alerts, and advisory guard JSON. It does not replace your owners. It gives them artifacts.

See the product surface, then request early access if you want that loop on an Ethereum lending market you actually run.