Market Layer

Overview

The Market Layer defines when PVERSE becomes tradable and what market access means. It exists to isolate market mechanics from protocol guarantees: allocation and vesting define entitlement, while the Market Layer defines exposure. Tradability is never implied; it is an explicitly enabled state. :contentReference[oaicite:2]{index=2}

This layer is intentionally separate from issuance, Founders, Genesis, and claim mechanics. Its purpose is to make “market live” an auditable on-chain condition rather than a soft marketing label or UI assumption. :contentReference[oaicite:3]{index=3}

Scope

This page specifies market-layer behavior only: listing configuration semantics, liquidity provisioning policy, swap availability, and the explicit activation event that defines the tradable state.

• Authority and truth boundaries for market exposure.
• Listing, liquidity, and swaps as separate controlled surfaces.
• Market activation anchor T₀ and its relation to vesting schedules.
• USD valuation evidence and audit-state-machine guarantees.

Core Model

The Market Layer is modeled as a controlled transition into tradability. It does not create entitlement; it defines the conditions under which market exposure exists and how that exposure is audited.

• Activation-bound: market exposure begins only through an explicit activation event.
• Configuration-separated: listing configuration is distinct from open trading.
• Liquidity-controlled: liquidity provisioning is a governed action, not an automatic consequence of issuance.
• Audit-bound: canonical market status is derived from finalized chain evidence and append-only records.

Operational Behavior

In normal operation, listing configuration may be recorded before the market is actually live. Pairs may exist, routes may be configured, and metadata may be visible while trading remains gated. Market activation occurs only when the protocol executes and finalizes the trading enable event on-chain, defining the canonical anchor T₀. :contentReference[oaicite:4]{index=4}

After T₀, swap availability and liquidity exposure may still remain policy-controlled. The market can therefore exist in layered stages: configured, activated, swaps enabled, liquidity enabled, or live under constraints. None of those stages rewrite prior entitlement history, and none may be inferred merely from UI appearance. :contentReference[oaicite:5]{index=5}

Constraints

• Listing configuration does not imply a tradable market.
• Pair existence does not imply unrestricted swaps.
• Liquidity exposure must not retroactively change allocation, vesting, or recorded outcomes.
• If USD valuation is used in operational decisions, it must be reconstructable from recorded oracle evidence; silent fallback is disallowed.

Integrity Considerations

A weak market model lets frontends, pairs, or community assumptions define reality. A strong market model binds tradability to explicit, finalized events and keeps exposure separate from entitlement. PVERSE uses the second model so later market activation can anchor schedules without rewriting earlier allocation truth. :contentReference[oaicite:6]{index=6}

• Truth clarity: chain evidence and controlled transitions are authoritative; UI is informational.
• Boundary clarity: listing, liquidity, and swaps are related but non-identical surfaces.
• History clarity: market exposure is additive and forward-only; it does not rewrite past records.

Future Expansion

As the market layer expands, route logic, liquidity policies, and constrained-market modes may evolve, but they should remain subordinate to the same activation anchor, truth hierarchy, replay safety, and append-only audit guarantees defined here.

Summary

• The Market Layer defines trading exposure, not entitlement.
• Market activation T₀ is the finalized on-chain trading enable event.
• Listing, liquidity, and swap availability are separate controlled states.
• Canonical market truth comes from verifiable logs and controlled state transitions, not UI or third-party interfaces.

Authority & Truth Boundaries

The Market Layer is governed by strict authority separation: the UI may display prices and availability, but it does not define truth. Canonical outcomes are produced only by controlled transitions executed against verifiable evidence. :contentReference[oaicite:7]{index=7}

• Authoritative: finalized on-chain events, receipts, block anchors, and append-only protocol records.
• Non-authoritative: DEX UI, cached views, third-party indexers, client session state, and estimates.

Definition

Market exposure is defined as a controlled transition into a tradable state. The activation anchor is T₀: the finalized on-chain execution of the trading enable event, such as enableTrading(). The Market Layer may additionally gate swaps and liquidity provisioning as explicit enablement states. :contentReference[oaicite:8]{index=8}

Market Activation Model

Market activation is not “a listing” and not “a pair exists.” It is the moment the protocol transitions into a tradable state. This anchor is used elsewhere, such as vesting schedules, without rewriting entitlement history. :contentReference[oaicite:9]{index=9}

Market Surfaces

DEX Listing (Configuration)

Listing describes configuration required for market access, such as pair creation, routing surfaces, and metadata, but configuration alone does not imply a tradable market. :contentReference[oaicite:10]{index=10}

• Listing ≠ Activation: configuration is not tradability.
• Pair existence ≠ Open market: a pair may exist while swaps remain gated.
• Policy-driven: listing is executed under explicit system policy and timing.

Liquidity Provisioning (LP Policy)

Liquidity provisioning defines the depth and availability of the swap surface. Liquidity is treated as a controlled action, executed under explicit policy to avoid weakening protocol invariants such as entitlement integrity, vesting guarantees, and auditability. :contentReference[oaicite:11]{index=11}

• Controlled provisioning: LP actions can be gated and executed intentionally.
• Locking policy: liquidity may be locked to reduce unilateral withdrawal risk.
• Ownership separation: LP ownership and control are treated as a distinct surface.

Swap Surface (Operational Exposure)

Swap availability is the operational expression of market exposure. Router interaction, swap routes, and trading constraints may be gated as part of market policy. Swaps are enabled only through explicit system transitions. :contentReference[oaicite:12]{index=12}

• Router gating: swap routes may be enabled or restricted.
• Explicit enablement: swap availability is an enabled state.
• Constraints: trading constraints may exist to preserve system integrity.

Claim vs Market

Claiming and vesting define entitlement and unlock state. Market access defines tradability and liquidity exposure. These are intentionally separated to prevent false equivalence between received tokens and open market availability. :contentReference[oaicite:13]{index=13}

• Claim ≠ Market enable: receiving tokens does not imply swaps are available.
• Unlock ≠ Liquidity: vesting unlocks do not imply market depth or readiness.
• Allocation ≠ Tradable supply: allocation records define entitlement, not exposure.

USD Valuation Evidence Clause

Certain market-layer surfaces may require USD-denominated thresholds, for example tiering, gating, reporting, policy-defined limits, compliance, or dispute resolution. If USD valuation is used, it must be derived from ruleset-defined oracle sources and preserved with sufficient evidence to allow independent reconstruction. The system shall store the oracle inputs used at computation time, not merely the computed result. :contentReference[oaicite:14]{index=14}

Required Evidence Fields (Minimum)

• oracle_kind such as Chainlink AggregatorV3Interface or system oracle adapter
• oracle_contract and feed_id
• round_id and answered_in_round where applicable
• answer and decimals
• oracle_updated_at and oracle_block_number where applicable
• valuation_timestamp based on the chain-derived timestamp being priced
• valuation_method and params_version as the active ruleset binding
• evidence_refs such as tx hash, receipt id, or block hash for the anchor being valued

Selection & Determinism Rules

• Deterministic selection: same anchor evidence and same ruleset version must select the same oracle round.
• Time anchoring: valuation is computed for the chain-derived timestamp, not UI time.
• Replay safety: reprocessing must yield the same USD value and must not create additional credit.
• Failure mode: if oracle evidence is unavailable under the ruleset, the operation must be rejected or deferred; silent fallback is disallowed.

State Machine Formalism (Audit View)

For auditing and dispute resolution, the Market Layer is specified as an explicit transition system rather than a UI-driven process. This formal view anchors the narrative above to verification primitives. :contentReference[oaicite:15]{index=15}

Formal Model

The Market Layer is defined as a transition system M = (S, E, V, δ, I) where S are states, E are events, V are validation predicates, δ is the controlled transition function, and I are invariants that must always hold. :contentReference[oaicite:16]{index=16}

S — States

• S₀: PRE_MARKET — allocation and vesting may exist, but market exposure is not enabled by default.
• S₁: LISTED_CONFIGURED — DEX configuration exists, but swaps may still be gated.
• S₂: ACTIVATED (T₀) — trading enable event finalized on-chain; activation anchor defined.
• S₃: SWAPS_ENABLED — swap surface explicitly enabled.
• S₄: LIQUIDITY_ENABLED — liquidity provisioning explicitly enabled.
• S₅: CONSTRAINED_MARKET — market is live but operating under explicit constraints.

E — Events

• E₁: LISTING_CONFIG_RECORDED
• E₂: PAIR_CREATED_OBSERVED
• E₃: LIQUIDITY_PROVISIONED
• E₄: MARKET_ACTIVATION_OBSERVED — defines T₀
• E₅: SWAP_STATE_CHANGED
• E₆: LIQUIDITY_STATE_CHANGED
• E₇: CONSTRAINTS_SET
• E₈: USD_VALUATION_RECORDED
• E₉: CORRECTION_EVENT

V — Validation Predicates

• V₁: Chain finality — evidence must be from finalized blocks.
• V₂: Ruleset binding — each event must bind to an effective params_version.
• V₃: Configuration admissibility — listing config must satisfy policy allowlists and expected surfaces.
• V₄: Activation integrity — T₀ must be derived from finalized on-chain execution evidence.
• V₅: Swap gating — swaps may occur only if enabled under current market policy state.
• V₆: Liquidity gating — LP actions may occur only if enabled under current market policy state.
• V₇: Oracle admissibility — if USD valuation is used, oracle and feed must match the allowlist.
• V₈: Oracle round validity — round identifiers and timestamps must satisfy selection windows.
• V₉: Replay protection — duplicate evidence must not create duplicate state transitions.

δ — Transition Function (Controlled Execution)

The transition function δ is executed by controlled infrastructure such as watchers, settlement logic, policy enforcers, and idempotent writers. It converts evidence and validated intent into durable, auditable records. :contentReference[oaicite:17]{index=17}

δ(S, E, evidence, params_version) -> (S', records_written)

Examples:
- δ(S₀, E₁, listing_policy_payload, vX.Y) -> (S₁, LISTING_CONFIG_RECORDED)
- δ(S₁, E₂, pair_created_receipt, vX.Y) -> (S₁, PAIR_CREATED_OBSERVED)
- δ(S₀, E₄, enableTrading_tx_finalized, vX.Y) -> (S₂, MARKET_ACTIVATION_OBSERVED(T₀))
- δ(S₂, E₅, swaps_enabled, vX.Y) -> (S₃, SWAP_STATE_CHANGED)
- δ(S₂, E₆, liquidity_enabled, vX.Y) -> (S₄, LIQUIDITY_STATE_CHANGED)
- δ(S₂, E₇, constraint_set_payload, vX.Y) -> (S₅, CONSTRAINTS_SET)
- δ(S₂, E₈, oracle_round_evidence, vX.Y) -> (S₂, USD_VALUATION_RECORDED)

I — Invariants

• I₁: Activation is explicit — the system becomes tradable only via the market activation event.
• I₂: Listing is not tradability — configuration does not imply open market behavior.
• I₃: Liquidity is controlled — LP actions are executed only under explicit policy.
• I₄: Allocation is independent — entitlement history is not defined by market conditions.
• I₅: Forward-only — market operations do not rewrite past records; corrections are new events.
• I₆: Deterministic outcomes — same evidence and same params_version yield identical outcomes.
• I₇: Idempotency — reprocessing must not create duplicate state transitions.
• I₈: Truth hierarchy — verifiable logs and controlled transitions are authoritative; UI is informational.
• I₉: Evidence reconstructability — if USD valuation is used, results must be reproducible from recorded oracle evidence.

Audit Anchors & Evidence

Market-layer truth is derived from authoritative anchors. These anchors are what auditors verify when resolving disputes. :contentReference[oaicite:18]{index=18}

• Activation anchor: finalized execution of the trading enable event defining T₀.
• Listing anchors: pair creation evidence, configuration records, and params_version.
• Liquidity anchors: LP transactions, receipts, and lock evidence where applicable.
• Swap policy anchors: swap enablement events and routing allowlists or constraints.
• USD valuation anchors: oracle, feed, and round evidence recorded per the valuation clause.
• Correction handling: corrective adjustments recorded as new events, never rewrites.

Protocol-Level Block Diagram

Client / UI (informational)
  |  - DEX UI, dashboards, cached views
  |  - user intent (non-binding)
  v
API Boundary (request normalization)
  |  - schema checks / rate limits
  v
Protocol Ruleset (Market Layer)
  |  - listing semantics (configuration ≠ tradability)
  |  - liquidity policy (controlled provisioning)
  |  - swap surface (explicit enablement)
  |  - activation anchor T₀ (on-chain execution)
  |  - USD valuation evidence requirements (if used)
  |  - S/E/V/δ/I: auditable transition system
  v
δ Controlled Execution (Infrastructure)
  |  - watchers/indexers (evidence ingestion)
  |  - settlement/finality logic (T₀ anchoring)
  |  - policy enforcers (swap/liquidity gating)
  |  - idempotent writers (append-only events)
  |        |
  |        +--> Chain Logs (verifiable truth)
  |        |      - finalized blocks, receipts, events
  |        |
  |        +--> System Records (audit trail)
  |               - MARKET_ACTIVATION_OBSERVED (T₀)
  |               - LISTING_CONFIG_RECORDED / PAIR_CREATED_OBSERVED
  |               - LIQUIDITY_PROVISIONED / LIQUIDITY_STATE_CHANGED
  |               - SWAP_STATE_CHANGED / CONSTRAINTS_SET
  |               - USD_VALUATION_RECORDED (if used)
  v
Read Models (informational)
  - search index, projections, UI caches