[Feature] Automated incident response & circuit-breaker for critical pool security alerts

[Sendi0011]

Summary

The security monitoring system (/api/admin/security/scan and the security-scan cron) already detects and persists critical alerts, but nothing acts on them automatically. Build an automated incident-response / circuit-breaker layer that escalates critical alerts into safe, reversible recovery actions.

Today the scan returns alerts (severity: "critical", etc.) and writes them to the alert table, but no code path ever invokes the contracts' existing pause/emergency_withdraw primitives or flips a pool to the paused status.

Requirements

1. Critical-alert → auto-pause — when a scan flags a configured threshold of critical alerts for a pool, automatically invoke the contract's pause function (rotational contract: fn pause) and persist the paused status + reason to Supabase.
2. Incident record — create an incidents table (pool, trigger, severity, created_by_scan, timestamps, resolution) so every automatic action is auditable via the existing admin audit log (/api/admin/audit-log).
3. Escalation & cooldown — add a cooldown to prevent pause-flap (e.g., no auto-pause more than N times per pool per window), and notify admins via the existing notification/push system.
4. Admin review & recovery — an admin endpoint to review a paused pool, mark the incident resolved, and (optionally) resume it; keep emergency_withdraw admin-only and manual, never automatic.
5. Dry-run mode — a config flag to run in dry-run (log-only) before enabling auto-action, with the scan result reporting whether action would have fired.

Notes / context

• Contract primitives already exist: rotational/src/lib.rs has pause, emergency_withdraw, migrate. Reuse them — do not change contract logic unless required.
• Follow /api/cron/security-scan/route.ts and /api/admin/security/scan/route.ts conventions for auth (server-side checks + CRON_SECRET) and rate limiting.
• Add unit tests for the cooldown/pause-flap logic and the dry-run path, mirroring existing route.test.ts patterns.

Acceptance criteria

• Critical alerts can automatically pause the affected pool (with dry-run toggle)
• Every auto-action produces an auditable incident record
• Cooldown prevents pause-flap; admins can review, resolve, and resume
• Unit tests cover cooldown, dry-run, and escalation logic
• Linting, format, and all CI checks pass

[Cyber-Mitch]

Hi, I'd like to apply for this issue.

This is a strong fit — I'm a security researcher, and building the automation layer that turns detection into action is exactly where a design mistake would be most costly: an auto-pause mechanism is itself a privileged, funds-affecting action, so it needs the same rigor as the contract primitives it invokes, not just plumbing between two existing systems.

A few things I'd treat as load-bearing:

Auto-pause is a new attack surface, not just an automation convenience — if the scan's alert criteria can be influenced or gamed (e.g. an attacker manufacturing conditions that look like critical alerts), auto-pause becomes a griefing vector against the pool's own users. I'd want to understand what the scan actually detects before wiring the trigger, and flag this explicitly if the alert source isn't itself hardened against manipulation.
Cooldown design is the core correctness question — "no auto-pause more than N times per pool per window" needs a clear definition of what happens between pauses: does the pool stay paused until manually resumed, or does it auto-resume and become re-pausable? I'd implement it as pause-until-manual-review by default (matching the issue's "admin review & recovery" framing), since auto-resuming a pool that triggered a critical alert seems like the wrong default.
emergency_withdraw staying strictly manual — I'd make sure there's no code path, including the incident-resolution flow, that could ever invoke it automatically; the issue is explicit about this and I'd treat it as a hard boundary worth a dedicated test (e.g. asserting no code path reaches emergency_withdraw without an explicit admin action in the call stack).
Dry-run as the actual rollout mechanism, not a toggle nobody uses — I'd build the scan result to always report "would this have fired" regardless of dry-run state, so the dry-run period produces real data on the alert-threshold's accuracy before anyone flips it live.
Incident table as the audit source of truth — every auto-action writes an incident row before (or atomically with) invoking pause, so a crash mid-action can't leave the contract paused with no corresponding record.

Implementation order: incident table + dry-run logging first (this alone proves the trigger logic is sound without touching the contract) → cooldown logic and its tests → actual pause invocation gated behind the dry-run flag → admin review/resolve/resume endpoint → notification wiring.

I'll complete the task within a day of assignment, and I'll open a draft PR early — once the incident table and dry-run detection path are working — so the trigger logic gets validated against real scan data before I wire in the actual contract-pausing action.

Happy to adjust based on your priorities.

[GiftedGiftB]

Hi Maintainer, i can get this work done in less than 30 minutes.

[diegoveme]

Hello JointSave team,

My background
My name is Diego, a developer with hands-on experience building smart contracts on Soroban/Stellar.

What I'd bring
I'm confident I have the right skill set for this one. I've worked directly with Soroban contract primitives and on-chain state transitions, so calling into existing pause/emergency_withdraw functions safely from an off-chain trigger, without touching contract logic, is exactly the kind of integration I'm comfortable owning end to end.

My approach would follow the requirements closely: the auto-pause path only fires once a configured critical-alert threshold is hit, writes the paused status and reason to Supabase, and creates a matching incidents record so the action is auditable through the existing admin audit log. I'd build the cooldown as a hard gate before the contract call is ever made (not just a log warning), so pause-flap is structurally prevented, not just observed. emergency_withdraw stays untouched by automation, admin-only and manual, as the issue specifies. And I'd wire dry-run as a real config flag from the start, since a feature that pauses live pools needs a safe way to validate behavior before it can act for real.

I'd follow the existing /api/cron/security-scan and /api/admin/security/scan conventions for auth (CRON_SECRET, server-side checks) and rate limiting, and mirror the existing route.test.ts patterns for unit tests covering cooldown, dry-run, and escalation.

Links
GitHub: https://github.com/diegoveme

Thank you for considering my application. Happy to answer any questions on the approach.

Best regards,
Diego

[devJaja]

Hello Maintainer

Can I take this issue please, ETA 5 hours

[grantfox-oss]

🦊 GrantFox — @diegoveme has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #254)
2. Your PR will be reviewed by the JointSave-org maintainers

Good luck! Track your progress on GrantFox.