> For the complete documentation index, see [llms.txt](https://candora.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://candora.gitbook.io/whitepaper/candora-pro/panic-button.md). # Panic Button ### Emergency position exit and asset protection The Panic Button is [Candora Pro](/whitepaper/candora-pro.md)'s emergency-account protection system designed for situations where normal trading workflows may no longer be sufficient. Financial markets occasionally experience periods of extreme instability. Liquidity can disappear, volatility can accelerate unexpectedly, execution conditions can deteriorate, and market behavior can become difficult to manage through conventional position-management techniques. During these conditions, traders often face a difficult problem: reducing exposure quickly while simultaneously securing assets before market conditions deteriorate further. The Panic Button exists to address this scenario. With a single activation, the system initiates a coordinated emergency workflow designed to reduce market exposure, halt active trading activity, secure account state, and prepare assets for settlement to a pre-verified destination wallet. The objective is not to improve trading performance. The objective is to provide a structured exit mechanism when preserving capital and operational control becomes the primary concern. ### Controlled exposure reduction When Panic Button is activated, the system immediately begins reducing active market exposure according to predefined emergency-management rules. Open orders may be cancelled, automated strategies may be paused, and active trading workflows may be suspended in order to prevent additional exposure from being created during a period of instability. For accounts with active leveraged positions, exposure reduction may occur through controlled de-risking workflows designed to reduce risk while minimizing unnecessary market disruption. The objective is to move the account toward a stable state before settlement begins. Exposure reduction remains subject to prevailing market conditions, available liquidity, and execution constraints. The Panic Button improves operational control during stressed conditions but cannot eliminate market risk. ### Emergency settlement workflow Once account exposure reaches a sufficiently stable state, the Panic Button transitions into the Emergency Settlement System. This system provides an alternative settlement pathway designed specifically for high-stress conditions where normal withdrawal workflows may become congested, delayed, or partially impaired. Assets remain fully recorded within [Vault](/whitepaper/candora-grid/vault.md) throughout the process. The system does not transfer custody to a separate environment. Instead, it initiates a specialized settlement workflow that prioritizes emergency withdrawal requests independently from standard withdrawal batching and optimization processes. This separation allows emergency withdrawal requests to continue progressing even when broader infrastructure conditions become less efficient. ### Pre-verified destination wallets All Panic Button settlements require a destination wallet that has been verified and configured before activation. Once the emergency workflow begins, destination routing becomes locked for the duration of the process. Wallet destinations cannot be modified, replaced, or redirected while Panic mode remains active. This restriction is designed to prevent accidental changes, operational errors, or malicious interference during periods of elevated stress. By requiring settlement destinations to be verified in advance, the system preserves deterministic execution while reducing operational uncertainty during emergency situations. ### Priority settlement processing The Panic Button includes a dedicated settlement-priority framework designed to improve execution continuity during periods of elevated demand. Emergency settlements may receive priority handling relative to standard withdrawal processing and may operate independently from non-critical batching and optimization systems. This allows the platform to continue processing emergency withdrawal requests even when normal operational queues experience elevated congestion. Importantly, this priority applies only to post-trade settlement handling. It does not affect order matching, market access, queue priority, execution quality, or participant treatment within [Candora Exchange](/whitepaper/candora-exchange.md). All market activity continues to follow the same deterministic execution rules that govern every participant. ### Emergency execution pathway The emergency-settlement pathway operates as a logically isolated execution layer within the Vault system architecture. ``` ┌─────────────────────────┐ │ Candora Vault │ │ (Single Source of Truth)│ │ │ │ - User balances │ │ - Margin / collateral │ │ - Position ledger │ └───────────┬─────────────┘ │ ┌──────────────────────┴──────────────────────┐ │ │ ▼ ▼ ┌──────────────────────────────┐ ┌──────────────────────────────┐ │ STANDARD EXECUTION LAYER │ │ PANIC BUTTON EXECUTION LAYER │ │ │ │ │ │ (Normal Conditions) │ │(Degraded / Stress Conditions)│ └──────────────┬───────────────┘ └──────────────┬───────────────┘ │ │ ▼ ▼ ┌──────────────────────────────┐ ┌──────────────────────────────┐ │ Order Engine │ │ Exposure Containment Engine │ │ │ │ │ │ - Limit/market orders │ │ - forced de-risk sequencing │ │ - Matching optimization │ │ - liquidation prevention │ └──────────────┬───────────────┘ └──────────────┬───────────────┘ │ │ ▼ ▼ ┌──────────────────────────────┐ ┌──────────────────────────────┐ │ Withdrawal Orchestration │ │ Emergency Settlement │ │ │ │ Subsystem │ │ - batching │ │ (Logically Isolated Rail) │ │ - scheduling queues │ │ │ │ - cost optimization │ │ - priority signing policy │ │ │ │ - no batching │ │ │ │ - deterministic routing │ └──────────────┬───────────────┘ └──────────────┬───────────────┘ │ │ └──────────────┬──────────────────────┘ │ ▼ ┌──────────────────────────────────┐ │ EMERGENCY SETTLEMENT ROUTER │ │ │ │ (Independent Execution Queue) │ │ │ │ - separate queue discipline │ │ - pre-reserved liquidity access │ │ - failure-isolated processing │ └──────────────┬───────────────────┘ │ ▼ ┌──────────────────────┐ │ BLOCKCHAIN SETTLEMENT│ │ │ │ (External finality) │ └──────────────────────┘ ``` It is separated from standard withdrawal processing in the following ways: * independent execution sequencing rules * priority-based settlement scheduling * reduced reliance on non-critical batching and optimization layers * isolated failure handling logic for high-stress conditions However, both standard withdrawals and emergency settlements remain anchored to the same underlying Vault custody and accounting system, ensuring a unified balance source of truth. The purpose of this separation is operational resilience, not custody duplication. ### Infrastructure resilience The Panic Button is designed to remain operational during a wide range of degraded market and infrastructure conditions. The emergency workflow utilizes dedicated processing logic intended to reduce dependence on non-essential systems while preserving settlement integrity. Emergency settlement execution still depends on the continued availability of core infrastructure components, including: * Vault account synchronization services * destination chain connectivity * transaction broadcast pathways * system-wide risk capacity allocation * verified wallet registry integrity If one or more dependencies are impaired, settlement may be: * delayed * rate-limited * partially queued for deferred execution * re-ordered based on network recovery conditions Even under stressed conditions, all balances remain anchored to the same Vault accounting system that governs the broader Candora platform. This ensures that emergency processing benefits from additional operational resilience without creating separate custody environments or duplicate balance records. In extreme system-wide failure scenarios, assets remain recorded within Vault custody and are recoverable through standard withdrawal pathways once infrastructure stabilizes. ### Settlement finality Emergency settlement remains subject to the underlying blockchain networks responsible for final transaction confirmation. While Panic Button can prioritize processing, coordinate settlement workflows, and preserve deterministic routing, it cannot alter: * blockchain consensus rules * validator behavior * network confirmation times * destination-chain congestion Once broadcast, transactions follow standard network settlement mechanics. The system guarantees execution integrity up to the point of broadcast. Network finality remains the responsibility of the underlying blockchain. ### Relationship to Candora Pro The Panic Button forms part of Candora Pro's advanced execution-protection framework. * [Liquidity Mirror](/whitepaper/candora-pro/liquidity-mirror.md) helps traders understand evolving liquidity conditions * [Anti-Spoof](/whitepaper/candora-pro/anti-spoof.md) evaluates the reliability of displayed market depth * [Order Shield](/whitepaper/candora-pro/order-shield.md) validates stop-loss triggers before execution * [Slippage Protection](/whitepaper/candora-pro/slippage-protection.md) helps reduce adverse execution drift The Panic Button operates at the emergency-management layer, providing coordinated exposure reduction and priority settlement workflows during abnormal market conditions. Together, these systems help traders manage risk across both normal and highly stressed market environments. ### Limitations The Panic Button is designed to improve operational resilience during periods of market stress. It does not guarantee: * immediate withdrawal completion * uninterrupted network availability * optimal execution pricing * full liquidity availability during extreme market stress * specific settlement timing * immunity from market losses Extreme market conditions, blockchain congestion, infrastructure disruptions, and systemic events may still affect execution efficiency and settlement timing. The system is intended to improve a participant's ability to exit and secure assets during adverse conditions. It is not a guarantee against market risk. Repeated or abnormal activation patterns may be subject to system-level rate controls to preserve overall infrastructure stability. ### Execution neutrality The Panic Button does not modify exchange matching behavior, alter participant priority, improve execution treatment, or provide privileged market access. All orders continue to enter the same deterministic execution environment as every other participant. The Panic Button affects only emergency exposure management and post-trade settlement workflows. It does not change how the market itself operates.