System Operations

Operational States

The system operates in one of five global states. The state determines which actions are available across the entire platform. This is distinct from per-market states (Section 3.3) which apply to individual contracts; the system state acts as an envelope that further constrains all markets uniformly.

State	Description	Trading	Deposits	Withdrawals	Liquidations
`NORMAL`	Full operations.	All order types	Yes	Yes	Yes
`DEGRADED`	Reduced capacity (oracle issues, partial infrastructure failure, elevated latency). New order placement may be rate-limited; some markets in `POST_ONLY` or `REDUCE_ONLY`.	Limited	Yes	Yes	Yes
`MAINTENANCE`	Planned maintenance window, announced in advance. New orders disabled or `REDUCE_ONLY` only across all markets.	Reduce-only or disabled	Yes	Yes	Paused
`HALTED`	Emergency stop. No order activity. Existing positions continue marking but are not liquidated.	No	No	Yes (free collateral)	No
`EMERGENCY_EXIT`	Operator unresponsive past threshold. The on-chain emergency exit path is the only way to retrieve free collateral. Off-chain operations fully unavailable.	No	No	Yes (on-chain only)	No

Normal

All markets operate per their per-market state. All API endpoints available at standard rate limits. This is the steady-state operating mode.

Degraded

The system is operating but some component is impaired. Common triggers and their effects:

Trigger	Effect
Oracle feed stale on a single market	That market enters per-market `HALTED`. System remains `NORMAL` if other markets are healthy; transitions to `DEGRADED` if multiple markets affected.
Settlement Submitter latency elevated	New fills continue but batch cadence slows. Withdrawals delayed but processed in order.
API Gateway under load	Rate limits tightened. WebSocket subscriptions may be capped per connection.

In DEGRADED, traders should expect reduced throughput and increased latency variance. Funds remain fully accessible. Liquidations continue normally.

Maintenance

Maintenance is planned and announced at minimum 24 hours in advance. During the maintenance window:

Existing open orders may be cancelled (announced per maintenance event).
New orders may be disabled or restricted to reduce-only.
Liquidations are typically paused (and announced if so).
Deposits and withdrawals continue normally.

Maintenance windows typically last under 30 minutes. Longer windows are scheduled and announced individually.

Halted

The system is stopped due to an emergency (oracle failure cascade, smart contract incident, regulatory action). In HALTED:

No new orders accepted; no fills produced.
Existing positions continue to mark against the last valid mark price.
Liquidations are paused. No position can be force-closed.
Deposits are paused.
Withdrawals of free collateral remain available via the standard withdrawal path.
Funding accrual is paused for the duration of the halt.

When the system recovers, mark prices resume from current oracle data. Any margin breaches that occurred during the halt are evaluated against post-halt mark prices, with a brief grace period (default 5 minutes) for users to top up margin before liquidations resume.

Emergency Exit

If the operator is unresponsive past the configured threshold (default 24 hours from HALTED declaration with no state change), the system auto-transitions to EMERGENCY_EXIT. In this state:

All off-chain components are presumed unavailable.
Users withdraw free collateral directly via the on-chain emergency exit path on the Margin Vault. This requires only the user's own signing key and Arc gas.
Open positions are not closeable through the off-chain matching engine. Users must accept their position state as of the last on-chain settlement. The Margin Vault permits withdrawal of free collateral, defined as the on-chain balance minus the initial margin required for last-settled positions.

This mechanism guarantees that no user is custodially trapped by an off-chain operator failure.

Recovery from EMERGENCY_EXIT requires explicit governance action. The system does not auto-recover even if the operator comes back online, because intervening account states may be stale.

State Transitions

Allowed Transitions

                            ┌───────────────────────────┐
                            │                           │
                            ▼                           │
              ┌─────────► NORMAL ◄────────┐             │
              │              ▲            │             │
              │              │            │             │
              │              ▼            ▼             │
              │          DEGRADED ──► MAINTENANCE       │
              │              │            │             │
              │              ▼            ▼             │
              │           HALTED ◄────────┘             │
              │              │                          │
              │              ▼                          │
              │       EMERGENCY_EXIT (one-way)          │
              └─────────────────────────────────────────┘
                  recovery from EMERGENCY_EXIT requires
                  governance action

From	To	Trigger
`NORMAL`	`DEGRADED`	Auto-trigger: oracle feeds stale across N markets, infrastructure latency exceeds threshold, or operator declaration.
`DEGRADED`	`NORMAL`	Auto-trigger: clearing condition resolves and remains stable for hold-down period (default 5 minutes).
`NORMAL` or `DEGRADED`	`MAINTENANCE`	Operator declaration with announced effective time.
`MAINTENANCE`	`NORMAL`	Operator declaration when maintenance complete.
Any	`HALTED`	Operator declaration in response to incident, or auto-trigger on systemic risk condition (e.g., oracle failure cascade plus insurance fund depletion).
`HALTED`	`NORMAL`	Operator declaration after incident resolution.
`HALTED`	`EMERGENCY_EXIT`	Auto-trigger if `HALTED` state persists past threshold (default 24 hours) without operator action.
`EMERGENCY_EXIT`	`NORMAL`	Governance action only, after confirming operator-side recovery.

Notification

State transitions are:

Logged on-chain in the Asset Registry.
Announced via WebSocket on the system-state channel.
Published on the public status page.

Routine transitions (NORMAL ↔ DEGRADED, scheduled MAINTENANCE) carry advance notice. Emergency transitions (HALTED, EMERGENCY_EXIT) are immediate but always announced as soon as they occur.

Worked Example: Cascade Response

A simulated incident illustrates the state machine end-to-end:

T+0           Pyth feed for ETH-USD becomes stale.
T+5s          ETH-PERP transitions to per-market HALTED.
              System remains NORMAL.

T+30s         BTC-PERP and SOL-PERP also flagged stale (broader Pyth issue).
T+35s         System transitions to DEGRADED. Order placement rate-limited
              platform-wide; affected markets in per-market HALTED.

T+2m          Pyth issue resolves; all feeds healthy.

T+7m          Hold-down period (5 minutes stable) clears.
              System transitions back to NORMAL.
              ETH/BTC/SOL markets resume LIVE; 5-minute liquidation grace period begins.

T+12m         Liquidation grace period ends. Normal operations resume.

If instead the incident had escalated (Pyth issue persists, insurance fund concurrently depleted), an operator would declare HALTED. If the operator subsequently became unresponsive for 24 hours, the system would auto-transition to EMERGENCY_EXIT and users could withdraw their free collateral on Arc directly.

Fees

Fee Model

Origin uses a maker-taker fee model with volume-based tiers calculated on a 14-day rolling notional traded. Makers add liquidity to the book; takers remove it. Maker fees are zero or rebate-zone at higher tiers.

Fee Schedule

14D Volume	Maker Fee	Taker Fee
<$250K	0.010%	0.060%
$250K to $1M	0.0075%	0.055%
$1M to $5M	0.0050%	0.050%
$5M to $15M	0.0025%	0.045%
$15M to $50M	0.0010%	0.040%
$50M to $150M	0.000%	0.0375%
$150M to $500M	0.000%	0.0350%
$500M+	0.000%	0.0325%

Volume Calculation

Volume is measured as the notional value of all fills (maker plus taker) over a rolling 14-day window. Tier reassessment is continuous: a user crossing into a higher tier sees the new rate apply immediately to subsequent fills. Tier downgrades use the same continuous evaluation.

Deposits, Withdrawals, and Gas

Origin charges no platform fees for deposits or withdrawals. Users pay only the underlying Arc transaction fee, denominated in USDC. Because Arc uses USDC as native gas, all on-chain operations (settlement, liquidations, ADL, deposits, withdrawals) incur predictable USD-denominated transaction fees. For routine trading, gas is amortized across batched settlement and is negligible per fill.

Parameter Change Process

Risk parameters, fee tiers, and listed markets evolve over time. Parameter changes follow a published flow:

Proposal. Change is published with rationale, target value, effective date, and notice period.
Notice period. Default minimum 48 hours for non-emergency changes.
Activation. Parameter change is committed on-chain through the Asset Registry contract.
Notification. Change is announced via API, status page, and WebSocket parameter-change channel.

Emergency parameter changes (oracle failure, market dislocation) can bypass the notice period but are logged with explicit emergency justification.

Origin publishes a public status page covering the matching engine, settlement service, oracle ingestion, and API gateway. Material incidents are published with timestamps, scope, and post-incident reports. This document is versioned; material changes to mechanics described here are accompanied by a version increment and a changelog entry.

APIs

Origin's API surface is documented in detail in a separate API reference. This section provides only an architectural overview; for endpoint specifications, request/response schemas, authentication details, rate limits, and SDKs, see the API documentation.

Surface	Use
REST	Stateful actions (place, modify, cancel orders), batch queries, account state, market metadata, historical data.
WebSocket (public)	Real-time market data: order book, trades, mark and index prices, funding rates, market and system state changes.
WebSocket (private)	Authenticated account streams: order updates, fills, positions, balances, ADL queue rank, liquidations.

Authenticated requests use API key plus signed-request authentication. Each request includes a timestamp, a nonce, and an HMAC signature derived from the request body and the API key's secret. API keys are scoped (Section 4.2) and can be restricted by IP allowlist. WebSocket streams carry per-stream sequence numbers (Section 9.2.3); the fill trust model is specified in Section 9.2. Official SDKs are planned for TypeScript, Python, and Rust.