Market Overview

Overview

This page is the entry point to the PVERSE market documentation set. It defines the boundary of the market layer, explains how to navigate the market documents, and establishes the core mental model for live trading, activation, liquidity, and execution.

The market layer is documented as an operational system rather than a marketing story. That means architecture, liquidity, trading state, activation, controls, order flow, market making, and risk boundaries each live on their own canonical pages so the live market remains legible and forward-only over time.

Scope

This page explains what the market documentation lane covers, what it excludes, and how readers should interpret live market posture.

• Market architecture, venue assumptions, and execution flow.
• Trading states, activation sequencing, and control surfaces.
• Liquidity posture, DEX integration, and route behavior.
• Risk boundaries, user safety, and market-level SSOT references.

Core Model

PVERSE markets are state-based, deliberately activated, and control-aware. The presence of a token or pool does not automatically imply an open market. Architecture, liquidity, routing, activation, and live status are treated as separate but connected layers.

• State-based trading: market posture changes through explicit states rather than assumption.
• Deliberate activation: trading opens intentionally after readiness conditions are met.
• Control-aware execution: restrictions and safeguards may apply during activation or protection windows.
• Forward-only records: market changes are documented through status and changelog surfaces, not silent rewrites.

Operational Behavior

In practice, the market layer starts from infrastructure readiness: pool preparation, route validation, liquidity posture, and control configuration. From there, trading transitions through explicit states until the market is considered openly tradable. Once active, execution quality depends on liquidity depth, routing, slippage settings, block ordering, and live chain conditions.

The market lane also defines how PC-linked revenue relates to on-chain liquidity. Subscriptions are purchased with in-game PC, not directly with PVR. PC is funded through separate crypto top-ups, and under Market Policy, PC revenue may be routed into PVR liquidity provisioning or reinforcement. This is a policy capability, not an unconditional guarantee.

Constraints

• No guarantee of price performance, returns, or permanent liquidity depth.
• No assumption that a visible pool means public trading is already open.
• No inclusion of gameplay economy, drop tables, or mining/refining logic in this lane.
• No silent rewriting of market rules; updates remain forward-only and status-linked.

Integrity Considerations

The Market lane is only useful if it keeps structure, state, and risk easy to read. This hub exists to reduce ambiguity, not to collapse every concept into one page.

• Separation of meaning: architecture, liquidity, activation, and risk live on dedicated pages.
• State clarity: live market posture should be verified through explicit state surfaces.
• Policy discipline: market operations remain bound by documented controls rather than implied promises.

Future Expansion

As the ecosystem matures, this hub can expand with richer cross-links, live market snapshots, and deeper status integration. Any expansion should preserve the same core discipline: this page remains a map and posture statement, while effective rules continue to live on their dedicated canonical pages.

Summary

• The Market Overview page is the hub for the PVERSE market documentation set.
• The market is state-based, deliberately activated, and controlled through explicit policies.
• PC revenue may support PVR liquidity under documented policy, while PC remains distinct from PVR.
• Readers should use this page to understand boundaries first, then move into the dedicated market documents.

Scope & Boundary

This section defines how PVR trading is activated and operated on public venues, primarily DEX. The goal is operational clarity: states, controls, liquidity policy, and known constraints.

Includes

• Market architecture and component responsibilities
• DEX integration, pairs, routers, and routing paths
• Liquidity definitions and provisioning policy
• Trading states and state-based controls
• Listings, activation procedures, and launch posture
• Risks, constraints, and user safety guidance

Excludes

• Any guarantee of price performance, returns, or liquidity depth
• Gameplay economy such as drop tables, mining, refining, and forging outputs
• Token SSOT definitions such as supply, allocation, vesting, and tax — see Token

Market in 60 seconds

• PVR price is formed on DEX pools via supply, demand, and liquidity conditions.
• Execution quality is affected by slippage, pool depth, MEV, and network conditions.
• Trading is state-based and may be restricted during activation or protection windows.
• Liquidity is managed by seeding and policy-based routing, not by promises.
• All material changes remain forward-only and are surfaced through status or changelog records.

Architecture Map

Use this page as the navigation hub for the Market lane.

Trading State Snapshot

Trading is operated using a state model. The current live state is published on Status and documented in Trading State.

PC Revenue and Liquidity

PVERSE subscriptions are purchased using PC, the in-game premium credit, not PVR. PC is acquired via separate crypto top-ups and used inside the web game.

Subject to Market Policy, PC revenue may be routed into PVR liquidity provisioning, such as seeding or reinforcing liquidity, under explicit controls and risk constraints.

Control Philosophy

• Safety-first activation: staged opening beats chaotic launch conditions.
• Transparent constraints: restrictions are documented and justified.
• Minimum necessary power: controls exist to reduce harm, not to manufacture outcomes.

User Safety Checklist

• Verify the official contract address and canonical links.
• Watch for fake pools, fake tokens, and phishing links.
• Avoid extreme slippage settings unless you understand the impact.
• Expect volatility and MEV effects near activation windows.
• Ignore unsolicited messages offering “support” or “special access.”

Recommended Reading Order

1. Market Architecture
2. Liquidity
3. Trading State
4. Trading Controls
5. Listings & Activation
6. Risks & Constraints
7. DEX Integration
8. Order Flow
9. Market Making
10. Market Policy
11. Glossary

Where the Truth Lives (SSOT)

• Token-level SSOT: supply, allocation, vesting, tax → Token
• Market-level SSOT: states, controls, activation, venue policy → Market
• Live operational status: current flags and live state → Status