× 
Monitoring & incident response
Monitoring and incident response determine how fast a protocol notices trouble and how well it responds. The controls pair machine-speed detection and automated circuit breakers with a human process rehearsed before it is needed.
Many exploits leave on-chain evidence before the final drain, such as funding transactions, probe calls, or an authority change. Real-time monitoring of program state, multisig proposals, and value flows turns that evidence into response time.
Real-time tracking covers critical program state changes, irregular multisig proposals (including durable nonce creation), large value transfers, upgrade authority changes on dependency programs, transfer-hook program upgrades on held tokens, and anomalous transaction patterns.
Frontend and API availability are monitored.
TVL deviations, liquidity shifts, and governance actions trigger alerts.
Monitoring covers all deployed environments, not just mainnet.
An exploit can finish before the first human reads the first alert. Circuit breakers respond at chain speed, pausing the affected markets automatically while responders catch up.
On-chain safeguards trigger automatically when invariants are violated or thresholds are breached.
Circuit breakers are granular where possible, pausing affected markets rather than the entire protocol.
Trigger conditions and reset procedures are documented.
The playbook settles in advance who acts, who communicates, and what happens first, so that during an incident the team executes a procedure instead of improvising one.
A documented incident response playbook assigns roles and defines escalation paths and communication templates.
The playbook covers common scenarios such as upgrade authority compromise, exploit in progress, oracle failure, frontend compromise, and key compromise.
A post-mortem process is defined, covering root cause analysis and a public disclosure timeline.
A pause authority with documented activation procedures is in place for emergency use.
On-call infrastructure routes every alert to a person who is on duty, reachable, and obliged to act, with escalation when that person does not answer.
A 24/7 on-call rotation operates with defined response time SLAs.
Alerts route to PagerDuty or equivalent, with escalation if unacknowledged.
Alert fatigue is managed through tuning and severity tiers.
Contact information is current and tested.
Coordinated response depends on relationships that cannot be built mid-incident. Security firms, external researchers, and neighboring protocols each need an established channel before the event that requires one.
Relationships with security firms and ecosystem security contacts are established before an incident occurs.
The responsible disclosure process is published.
The protocol provides a public point of contact for external security researchers.
Cross-protocol communication channels are in place for coordinated response to systemic events.
Contact lists, escalation procedures, and engagement protocols for external security partners are documented, tested, and available to on-call personnel during an incident.