From Alert Noise to Guard Proposals

Most DeFi security stacks are good at detecting something. Fewer are good at saying what a human should do next without creating either panic or fatigue.

The gap is not missing dashboards. The gap is the missing work product: a bounded, reversible, allowlisted proposal that a multisig can review, reject, or execute.

This article is for protocol operators and security leads who are tired of alerts that end in a group chat argument.

Why This Matters

Alert fatigue is not a personality problem. It is a workflow problem.

If every liquidation cluster pages the same channel, people mute the channel. If the only "response" is a founder drafting a transaction from memory, the organization is one tired signer away from a mistake. If the product offers autonomous parameter changes, it introduces a new class of failure: the monitor becoming an attacker-shaped control plane.

Lending protocols need a middle path: detection that produces a reviewable packet, not a button that moves the protocol by itself.

The Alert Fatigue Problem

Typical failure modes we see in early monitoring setups:

• Duplicate alerts for the same window and severity
• No owner, so everyone assumes someone else looked
• No evidence, so the on-call person has to rebuild context
• No allowed action list, so debate starts from a blank page
• No expiry, so a stale idea gets signed hours later

None of those are solved by a louder webhook.

The Gap Between Detection and Action

A useful response path has three artifacts:

1. Alert — what changed, with severity and evidence.
2. Decision record — watch, escalate, or propose.
3. Guard proposal — if proposing, a JSON package with target, calldata intent, expiry, and cooldown.

Skip artifact 2 and you get either freeze-the-world energy or no action. Skip artifact 3 and signers invent transactions under time pressure.

The security model is explicit: BlockSentinel does not custody funds and does not execute. That is the point of the third artifact being a proposal.

Human-in-the-Loop Guard Proposals

A Phase 1 guard proposal should be boring on purpose.

It should name:

• Protocol and chain
• Triggering risk window and score
• Allowlisted action type (for example freeze a specific reserve)
• Target contract that is already approved by the team
• Function signature the team already accepted
• Expiry
• Cooldown before another proposal of the same type
• A safety note that this is advisory

It should not:

• Pick "the first asset we saw" as a fallback
• Invent a target that still says REPLACE_ME
• Post to a Safe transaction service unless the team explicitly enabled that mode
• Claim the proposal will stop an exploit

JSON-only mode is the default we recommend until a team has rehearsed review. Safe draft posting is a later, explicit switch. See docs for the schema preview.

Safe, Bounded, Reversible Response

"Do something" is not a policy. Policy looks like this:

Action	Allowed in a careful Phase 1?	Why
Notify Slack / email	Yes	Low blast radius
Freeze a named reserve	Only if allowlisted	Bounded, often reversible
Pause the whole protocol	Usually no until rehearsed	High blast radius
Change interest model live	No by default	Easy to get wrong
Autonomous execution	No	New control-plane risk

Reversible matters. A freeze that a multisig can undo is a different conversation from a one-way parameter rewrite drafted in a hurry.

Why Autonomous Action Is Risky in Phase 1

Automated response sounds attractive when a team is small. It is also how you couple a monitoring bug to protocol state.

Phase 1 monitoring is event-log based, Ethereum-first, and incomplete by design (oracles and reserve health are not fully implemented). Driving live protocol changes from that surface is not "being aggressive about security". It is expanding the trusted computing base to include every ingest and scoring bug.

Advisory proposals keep the monitor useful while the scoring model is still earning trust. That matches how we describe the product on the product page.

Hypothetical workflow

18:12 UTC — high alert, risk 7d 84, confidence 0.72, liquidations clustered on USDC. 18:14 — on-call confirms freshness is 3 minutes. 18:18 — policy says FREEZE_ASSET is allowlisted for that reserve; PAUSE_PROTOCOL is not. 18:20 — JSON proposal generated with 120-minute expiry and 30-minute cooldown. 18:35 — two signers reject it after seeing liquidations were a known market move. The rejection is recorded. No chain action. The next similar alert in the same window is deduped.

That is a successful operation even though nothing was executed. The system created a decision, not a mess.

What Teams Should Watch

If you are designing this internally, watch:

• Time from alert to a written decision
• Percent of alerts that produce duplicate pages
• Percent of proposals that expire unused
• Whether rejected proposals are stored
• Whether anyone can name the allowlist from memory

A companion runbook is in incident response for lending protocols. Scoring quality is in evidence-backed risk scores.

How BlockSentinel Approaches This

BlockSentinel's guard path is OFF, NOTIFY_ONLY, JSON_ONLY, or SAFE_DRAFT. Default for early pilots is JSON_ONLY. Placeholder targets are rejected. There is no "first asset" fallback. Safe posting does not happen unless you turn that mode on after reviewing signer configuration.

Next Step

If your current "response" is a Discord thread, request early access. Bring your allowlist, not just your webhook URL.