Trading State

Overview

Trading State defines the single canonical vocabulary for how the PVERSE market is operated over time. It answers one practical question with precision: what is allowed right now for swaps, transfers, and liquidity actions?

This page does not try to predict price, promise liquidity, or erase market risk. It defines what the protocol intends to allow, how that allowance changes over time, and how those changes should be communicated publicly.

Scope

This page describes the public state model for market availability and market safety posture.

• Canonical state labels for trading, transfers, and liquidity.
• Permission meaning attached to each state.
• Forward-only normal transitions and emergency exceptions.
• Public signaling through Status and changelog surfaces.

Core Model

The market operates as a finite state model. Each state defines what actions are generally permitted, what safeguards may apply, and what public interpretation users should attach to the current posture.

• State-based operation: market posture is explicit rather than implied from deployment or pool visibility.
• Manual activation: trading becomes available only through deliberate operator action.
• Permission separation: swaps, transfers, and liquidity actions may differ by state.
• Safety exceptions: RESTRICTED and HALTED exist to reduce harm during instability or critical incidents.

DEPLOYED
  ↓
GENESIS_ACTIVE
  ↓
LIQUIDITY_BOOTSTRAP
  ↓
TRADING_ENABLED
  ↓
OPEN_MARKET
  ↘
   RESTRICTED
     ↘
      HALTED

Operational Behavior

In normal operation, the market begins from contract existence and infrastructure preparation, not from immediate public tradability. Liquidity is prepared, routes are validated, and monitoring is established before manual activation opens trading. Once enabled, the market may still pass through monitored launch conditions before it is treated as a normal open market.

Under abnormal conditions, the state model allows temporary defensive posture. RESTRICTED narrows permissions while preserving partial operation where safe. HALTED is the emergency state used to stop propagation during severe failure or exploit risk. Recovery should move through public, documented state changes rather than hidden discretionary behavior.

Constraints

• Pool existence alone does not imply open public trading.
• State labels describe intended posture, but live execution still depends on on-chain rules and deployed controls.
• Conditional permissions may include allowlists, launch limits, cooldowns, or other declared safeguards.
• This page does not guarantee price stability, liquidity depth, or successful execution.

Integrity Considerations

The state model only works if it is observable and auditable. Users should be able to distinguish a prepared market from an open market, and a defensive posture from a normal posture, without relying on rumor or guesswork.

• Public signaling: /status is the authoritative public display of current trading, transfers, and liquidity posture.
• Forward-only records: market-affecting changes should be logged through changelog surfaces with date and, where applicable, on-chain references.
• Recovery discipline: emergency exits from HALTED should progress through explicit, documented state recovery rather than silent reopening.

Future Expansion

As the market matures, the state model can gain richer public signals, clearer sub-state disclosures, and tighter linkage between Status, controls, and changelog records. Any expansion should preserve the same core discipline: deliberate activation, readable permissions, bounded safety exceptions, and forward-only public state transitions.

Summary

• Trading State is the canonical vocabulary for what the market allows right now.
• The normal path is forward-only: deploy, bootstrap, enable, then open.
• Trading, transfers, and liquidity permissions are related but not identical.
• RESTRICTED and HALTED exist to reduce harm during unstable or critical conditions.