Borrow Pressure, Liquidation Stress, and Same-Transaction Anomalies

Phase 1 BlockSentinel scoring is intentionally small. It does not pretend to see the mempool, full traces, or every oracle update. It watches Ethereum lending event logs and asks whether a few stress features moved together.

This article explains those features in operator language: borrow pressure, liquidation stress, same-transaction anomalies, plus confidence and freshness. It is for security and risk people who will be asked "what does 72 mean?"

Why This Matters

If a team cannot explain the factors, they will not defend the alert to a signer. They will also not know when the model is silent because a factor is unimplemented.

We would rather publish a narrow, honest model than a mysterious composite. The broader case for that is evidence-backed risk scores.

Borrow Pressure

What we count: borrow-related logs in a time bucket, compared with that protocol's recent history for the same bucket length.

Why it can matter: a sudden borrow wave can be leverage, migration, a rate-driven grab for liquidity, or setup for a strategy that needs inventory from the pool.

What it does not mean: "someone is attacking". Healthy markets borrow. Liquidations elsewhere can cause borrowing here. Airdrop or rate changes can move the same metric.

How to read it: look at the multiple vs the 7-day median, not the absolute count. A quiet market with 12 borrows can be more surprising than a busy market with 40.

Hypothetical

30-minute bucket, example-lending WETH market: 19 borrows vs a 7-day median of 4. Repays are 2. Utilization is unknown to this model because reserve-health is not implemented. Treat as "borrow pressure is elevated; inspect, do not freeze".

Liquidation Stress

What we count: liquidation-related logs (for Aave-style markets, LiquidationCall) in the window.

Why it can matter: clustered liquidations can indicate collateral stress, oracle movement, or a cascade starting. They are among the few event types that already mean someone lost a position.

What it does not mean: the protocol is insolvent, or that a freeze would have helped. Some liquidations are the system working.

How to read it: one liquidation after a quiet day is a note. Three in the same 30 minutes after none for a day is a conversation. Combine with borrow pressure; isolated liquidations with flat borrows are a different story than both rising together.

Same-Transaction Anomalies

What we count: lending actions that share a transaction hash, such as borrow and repay in the same transaction.

Why it can matter: atomic combinations are how many sophisticated strategies (and some attacks) express themselves. A user interface rarely needs borrow-then-repay in one transaction. Bundled flows deserve a look.

What it does not mean: every same-tx pattern is malicious. Aggregators, liquidators, and keepers do atomic work by design. This factor is a spotlight, not a verdict.

How to read it: pair it with volume. One atomic helper transaction is noise. A burst of same-tx borrows against one reserve while liquidation count also jumps is worth opening the explorer.

Confidence

Confidence is not a marketing adjective. In Phase 1 it should fall when coverage is thin.

Event-only weights we currently treat as implemented: borrow, liquidation, and same-transaction behavior. Oracle and reserve-health slots exist in the schema with implemented: false. A score that used only the implemented third should not be presented as if the missing two were "fine".

Low confidence means: look if you want, do not treat it like a high-confidence page.

Freshness

A score computed from logs that ended 40 minutes ago describes a previous market. Print last ingest time next to the number. If RPC failed, say so. Operators should escalate ingest failures differently from risk spikes. That split is in the monitoring checklist.

What These Signals Can and Cannot Prove

Claim	Supported by Phase 1 factors?
Event activity looks unusual vs recent baseline	Yes, within the windows we compute
An exploit is confirmed	No
Oracle manipulation occurred	Not with current implemented factors
A specific address is an attacker	No
A guard action should execute automatically	No
A human should review evidence	Yes, when thresholds and confidence say so

If you need a sentence for a board memo: these are stress indicators derived from public event logs, not an attribution product.

A Practical Framework

When an alert fires, read factors in this order:

1. Freshness
2. Liquidations
3. Borrow pressure
4. Same-transaction count
5. Confidence / coverage
6. Only then the headline 7d number

If 2–4 are mixed and 5 is low, you are in research mode, not signer mode. If 2–4 agree, data is fresh, and persistence is met, you are in the guard proposal conversation — still advisory.

How BlockSentinel Approaches This

The engine stores per-window counts, merges same-minute buckets, and keeps a latest score with coverage. Weights in the current rule set are event-only (borrow / liquidation / same-tx). We will not quietly fill oracle weights until that path exists.

Architecture notes are on docs. Product scope is on product.

Next Step

If you want to see these factors on a protocol you actually operate, request early access. Bring one market you care about, not a request for "all of DeFi".