> For the complete documentation index, see [llms.txt](https://docs.valantis.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.valantis.xyz/stakedhype/monitoring-and-incident-response.md).

# Monitoring and Incident Response

Last updated: 2026-02-24

This page explains how stHYPE monitoring works in plain terms, what happens during incidents, and how safety controls are used.

## At a Glance

* stHYPE does not rely only on off-chain bots for core safety.
* Critical checks are enforced on-chain and can block unsafe actions automatically.
* Off-chain monitoring is used for detection, escalation, and incident coordination.
* Off-chain alerts do **not** auto-submit pause transactions.
* Pause actions are operator-confirmed, role-gated, and time-bounded on-chain.

## How stHYPE Monitoring Works

stHYPE uses two control layers:

1. **Automatic on-chain safety checks**

* Critical conditions are checked directly in contract execution.
* Unsafe state transitions are reverted without waiting for off-chain responders.

2. **Off-chain monitoring and response**

* Monitoring detects market, operational, and control-plane risk signals.
* On-call responders triage, escalate, and execute role-gated actions when needed.

## Key On-Chain Safety Guarantees

Without operator intervention or off-chain monitoring services:

* Pending-slash checks can block unsafe mint/redeem behavior.
* Rebase safety bounds can revert unsafe supply changes (`AprTooHigh`, `SupplyDecreaseTooHigh`).
* Queue/liability checks prevent unsafe redemption progression.

In the event of operator initiated pausing:

* Pause duration is bounded on-chain (`> 0` and `<= 14 days`).

## What We Monitor

Public monitoring coverage includes:

* role changes, pause/unpause operations, and upgrades,
* mint/burn/redeem queue health and solvency posture,
* rebase and slashing-accounting signals,
* staking-module allocation and withdrawal-status signals,
* critical address and control-plane activity,
* secondary market stress (for example depeg and liquidation pressure).

All data publicly accessible. Operators use internal services and alert systems. In the future, bi-weekly reports will be published and posted in documentation on size of queue health, mean/median time to withdraw, secondary market peg health, and other key metrics.

## Incident Severity and Escalation

We classify incidents into:

* `SEV-1`: critical user-impacting safety incident.
* `SEV-2`: major degradation or elevated risk requiring active intervention.
* `SEV-3`: non-critical degradation requiring planned remediation.

Operations coverage is timezone-distributed with designated primary/backup ownership and escalation paths.

Public response commitments are severity-based and qualitative:

* `SEV-1`: immediate triage and active incident coordination.
* `SEV-2`: rapid triage and active remediation.
* `SEV-3`: planned remediation with tracking.

## Incident Playbooks

Our incident runbooks are organized around the main risk classes:

* pending-slash or slashing-accounting incidents,
* queue/liquidity stress incidents,
* privileged-key/control-plane incidents,
* infrastructure dependency disruptions.

## Safety Control Matrix

| Trigger                                   | Detection Path                                 | Automatic Contract Behavior                                              | Operator-Confirmed Action                                         | Authority + Bounds                                                            |
| ----------------------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| Pending slash state                       | `pendingSlashExists` / `_pendingSlashExists()` | `mint` blocked; `redeem` non-redeemable; `maxRedeemable` can drop to `0` | Assess slash state and execute bounded pause if needed            | `DEFAULT_ADMIN_ROLE` + `REBASER_ROLE`; pause duration bounded by `<= 14 days` |
| Slash exceeds configured cap              | `_accountForSlashing()` during `rebase()`      | `rebase` reverts with `SupplyDecreaseTooHigh`                            | Keep burns/redemptions paused if needed; run incident process     | `DEFAULT_ADMIN_ROLE`; bounded pause controls                                  |
| Excessive positive APR/supply change      | `rebase()` APR check                           | `rebase` reverts with `AprTooHigh`                                       | Investigate state/config and run safe rebase workflow             | `REBASER_ROLE` (+ admin for config updates)                                   |
| Queue or solvency stress                  | Queue and liability checks                     | Unsafe redemptions remain blocked by on-chain checks                     | Execute queue/liquidity operations and incident communications    | Operations + role-gated module workflows                                      |
| Predicted slash not yet readable on-chain | Off-chain monitoring + governance intel        | No automatic off-chain pause execution                                   | Operator-confirmed `pauseRedemption`, `pauseBurns`, or both       | `DEFAULT_ADMIN_ROLE`; bounded by configured pause duration                    |
| Suspicious privileged-key activity        | Control-plane monitoring                       | No automatic off-chain pause by bot                                      | Immediate containment, rotation flow, and incident communications | Multisig-governed admin controls                                              |

## What Users and Integrators Should Expect

* Withdrawals are user-triggered on-chain (`burn`, `burnAndRedeemIfPossible`, `redeem`).
* During slash risk or incident conditions, burns/redemptions can be temporarily constrained by safety logic or bounded pause controls.
* Burn/redemption pauses are protocol-wide and time-bounded.
* Address-level transfer-disable toggles are transfer-path controls and are separate from withdrawal-queue accounting.

See [Integrate stHYPE](/stakedhype/integrate.md) and [Roles and Controls Registry](/stakedhype/roles-and-controls-registry.md) for implementation details.

## Disclosure Boundaries

For security reasons, this page does not publish:

* full provider/vendor topology,
* exact alert-channel internals,
* sensitive responder identity details.

Public dinsclosure is intentionally scoped to moitoring domains, severity process, control behavior, and authority boundaries.