# Incident Response & Business Continuity

{% hint style="info" %}
Operator and jurisdiction: BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC (LEI: [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64)).
{% endhint %}

{% hint style="warning" %}
Accounting convention: Portfolio values may be displayed in USDT as an internal accounting and display unit only. USDT is not depositable or withdrawable on BASIS. Supported native asset flows are BTC, ETH, SOL, and PAXG. BTC deposits use a unique BASIS-assigned address for each account. ETH, SOL, and PAXG deposits use a connected Web3 wallet. See [Risk Disclosure](https://docs.basis.pro/risk-safety-and-asset-protection/risk-disclosure).
{% endhint %}

This page explains how BASIS detects incidents, constrains risk, preserves asset integrity, and restores normal operation. It also describes what users see across Stake, Assets, Support, and Account during an event.

## Incident classification

| Severity     | Definition                                                              | Example                                | Response initiation                                 |
| ------------ | ----------------------------------------------------------------------- | -------------------------------------- | --------------------------------------------------- |
| P1, Critical | Asset integrity at immediate risk or core platform inoperable           | Venue insolvency, BHLE cluster failure | < 5 minutes automated, < 15 minutes operator review |
| P2, High     | Material degradation, structural alpha capture paused on affected flows | API failure cascade, BSCB trigger      | < 15 minutes automated                              |
| P3, Medium   | Partial degradation with isolated impact                                | Single venue maintenance window        | < 1 hour automated                                  |
| P4, Low      | Non-critical alert with no direct asset risk                            | Elevated latency, minor fee anomaly    | < 4 hours                                           |

## Response state model

{% hint style="warning" %}
**Operating State Cycle**

NORMAL → BSCB\_ACTIVE → DMM\_ACTIVE → RECOVERY → NORMAL
{% endhint %}

* NORMAL: All supported operations run within standard constraints.
* BSCB\_ACTIVE: Risk-increasing actions are restricted while the system validates market and ledger conditions.
* DMM\_ACTIVE: Defensive reduction logic can be applied to limit risk and control market impact.
* RECOVERY: Reconciliation completes, queued actions drain, and normal routing resumes.

## Venue failure response

{% stepper %}
{% step %}
**1. Detection**

BHLE continuously measures venue health. If 3 consecutive calls fail, the venue is marked degraded. Detection target is under 1 second.
{% endstep %}

{% step %}
**2. BSCB activation**

The BASIS Safety Circuit Breaker blocks new risk-increasing actions on the affected venue. Existing positions are not force-closed automatically unless a higher-priority risk rule requires reduction.
{% endstep %}

{% step %}
**3. Constrained reallocation**

Capital can be reallocated to healthy venues only if execution precision remains within model limits for depth, slippage, and state transition safety.
{% endstep %}

{% step %}
**4. Revalidation**

BHLE continues polling the degraded venue. After 3 consecutive successful responses and clean ledger checks, the venue can return to the active pool.
{% endstep %}

{% step %}
**5. Reconciliation and audit**

Fill records, balances, funding entries, and internal state transitions are reconciled against BHLE logs. Any mismatch is escalated.
{% endstep %}
{% endstepper %}

## BSCB trigger conditions

The BSCB activates automatically when any threshold below is breached.

| Trigger                   | Threshold                                           |
| ------------------------- | --------------------------------------------------- |
| API failure               | More than 3 consecutive failed calls to any venue   |
| Execution anomaly         | More than 3x predicted slippage at execution        |
| Margin ratio              | Below 150% on any open position                     |
| Settlement unit deviation | More than 1.5% deviation from reference             |
| Reconciliation failure    | Any mismatch between BHLE records and venue balance |
| Volatility spike          | More than 4x the 1-hour average volatility          |

When BSCB activates:

* New position openings are paused on affected routes
* Same-token 1:1 swaps into affected pools can be temporarily restricted
* Reward accumulation can pause for affected pools
* Existing positions are held or reduced only by rule set
* The system enters continuous monitoring mode
* Operator review begins for P1 and P2 paths

If conditions persist or worsen, the system escalates to DMM.

## DMM, Defensive Market Mode

DMM is a controlled risk state, not a panic shutdown.

In DMM:

* Positions may be reduced gradually to limit risk
* Execution remains constrained by deterministic sizing and market impact limits
* User withdrawals may queue until asset and ledger checks clear
* Matured unstake requests may be delayed while reconciliation completes
* Fixed pools remain locked until the lock-up period ends, with no early exit option

## What users experience during an incident

{% tabs %}
{% tab title="Normal" %}

* Funding Wallet supports native asset deposits and withdrawals for BTC, ETH, SOL, and PAXG
* BTC deposits use the BASIS-assigned address for the account
* ETH, SOL, and PAXG deposits use a connected Web3 wallet
* Same-token swaps are 1:1 only, BTC→stBTC, ETH→stETH, SOL→stSOL, PAXG→stPAXG
* Rewards accumulate in real time as the same stToken in the Staking Wallet
* Unstake is always full-position only, with auto-MAX behavior
* Upon unstake, the matured position and accumulated rewards are auto-credited to the Staking Wallet as stToken
* Fixed pools can be unstaked only after the lock-up period ends
* Standard withdrawal timing is 10 to 60 minutes for BTC and 1 to 10 minutes for ETH, SOL, and PAXG
  {% endtab %}

{% tab title="BSCB Active" %}

* Existing positions remain protected by circuit breaker logic
* New staking or same-token swaps into affected pools may be paused
* Reward accumulation may pause for affected pools
* Funding Wallet withdrawals can move into a review queue
* Dashboard status banners appear in Stake, Assets, Support, and Account
* Native asset balances remain visible, with USDT shown only as a display unit
  {% endtab %}

{% tab title="DMM Active" %}

* Controlled position reduction may be in progress
* Matured unstake requests may remain queued until risk checks complete
* Fixed pools remain locked until maturity, with no early exit
* Withdrawal times may exceed normal targets
* Support updates continue through the dashboard incident banner and official notices
  {% endtab %}

{% tab title="Recovery" %}

* Normal routing resumes after venue, ledger, and state checks pass
* Reward accumulation restarts for recovered pools
* Queued withdrawals and matured unstake requests are processed
* Dashboard status changes to recovered, with an incident reference where applicable
  {% endtab %}
  {% endtabs %}

{% hint style="info" %}
Operational constants during normal service remain unchanged by incident policy: deposit fee 0%, withdrawal fee 0.05%, swap fee 0.01%. USDT remains a display unit only.
{% endhint %}

## BHLE hardware failure and N+1 failover

BHLE runs on N+1 bare-metal capacity. For every N active nodes, at least one standby node is reserved for failover.

Failover flow:

1. Heartbeat monitoring detects a non-responsive node in under 1 second
2. A standby node assumes the active role using the last committed deterministic state snapshot
3. In-flight orders reconcile against venue fill records
4. Any ledger mismatch escalates immediately to P1 review
5. Target end-to-end failover time is under 30 seconds

Asset movement authority does not expand during failover. Transfer permissions remain constrained by the same authorization state machine, withdrawal policy, and ledger consistency checks.

## Recovery targets

| Metric                              | Target          |
| ----------------------------------- | --------------- |
| BSCB trigger to automated response  | < 15 minutes    |
| P1 incident to user notification    | < 15 minutes    |
| P1 incident to full recovery        | < 4 hours       |
| Post-incident reconciliation report | Within 48 hours |
| Public incident disclosure          | Within 72 hours |

## Post-incident reporting

After any P1 or P2 incident, BASIS publishes:

1. Timeline, including detection, containment, and recovery checkpoints
2. Root cause, including system, venue, or market failure source
3. Impact, including affected users, asset exposure, and realized loss if any
4. Remediation, including rule changes, infrastructure changes, or control hardening
5. Audit trail excerpts, redacted where required for security, showing position and balance reconciliation

Reports are published in the platform dashboard and linked from [Audits & Responsible Disclosure](/technical-architecture/audits-and-disclosure.md).

## See also

* [BSCB Circuit Breaker](https://docs.basis.pro/technical-architecture/bscb-circuit-breaker)
* [Security Architecture](/technical-architecture/security-architecture.md)
* [Audits & Responsible Disclosure](/technical-architecture/audits-and-disclosure.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.basis.pro/technical-architecture/incident-response.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.