Incident Response & Business Continuity

Operator and jurisdiction: BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC (LEI: 254900IX2F2KCWNSSS64).

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.

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

Operating State Cycle

NORMAL → BSCB_ACTIVE → DMM_ACTIVE → RECOVERY → NORMAL

• 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

1

1. Detection

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

2

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.

3

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.

4

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.

5

5. Reconciliation and audit

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

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

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

BSCB Active

DMM Active

Recovery

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.

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.

See also

• BSCB Circuit Breaker

• Security Architecture

• Audits & Responsible Disclosure