Liquidity Policy

Purpose

The objective of this policy is to define how liquidity and market activation are handled in a way that is predictable, auditable, and resilient during early operation. The initial market for any newly activated system can be thin and volatile. PVERSE therefore treats market activation as a separate control plane from allocation, vesting, and claims.

Core principles

• Safety-first activation: markets are activated deliberately, not by default.
• Separation of concerns: allocation, vesting, and claimability are distinct from tradability and transferability.
• Manual launch control: enableTrading is executed manually under an operational checklist.
• Minimum viable liquidity: liquidity is provisioned for function and stability, not marketing optics.
• Forward-only operations: adjustments are recorded and applied going forward without rewriting prior state.

Definitions

• Liquidity (LP): assets supplied to an AMM pool to enable swaps.
• Pool: an automated market maker pair where trades execute against reserves.
• Market activation: the operational event that transitions market controls from OFF to ON.
• enableTrading: a controlled action that enables trading; policy requirement: manual execution.
• Transferability: the ability to transfer tokens; not synonymous with “market open.”
• Constraints: guardrails such as maxTx, maxWallet, cooldowns, and allowed pairs.
• Emergency guard: a protective mode that tightens controls when abnormal conditions occur.

Policy model

State A — Pre-Activation (Market OFF)

Trading is not active. Operational readiness, monitoring, and incident handling are established before any activation. Allocation and vesting logic may continue independently under their own policy rules.

State B — Soft Activation (Guarded ON)

Trading is enabled under a guarded window. Constraints may remain strict to reduce automated abuse and sudden system stress. This phase prioritizes stability and observability over openness.

State C — Normal Operation (Open)

Constraints may be relaxed over time according to predefined criteria and observed operational stability. Relaxation is never implied and is always policy-driven.

State D — Emergency Guard

Under abnormal conditions such as malfunctions, exploit attempts, unexpected automated activity, or broader operational risk, controls may be tightened or trading may be paused. The purpose is system protection, not market management.

Liquidity sources and use

Liquidity provisioning exists to make the market functional and to support a stable operational launch. It is not a commitment to defend price, provide returns, or ensure any specific market result.

• For: enabling swaps, improving usability, and reducing fragility during activation.
• Not for: price support, guaranteed outcomes, or implied returns.

Launch procedure

Step 0 — Preconditions

• Contract addresses are verified and published in canonical documentation.
• Token parameters are verified, including symbol, decimals, and supply configuration.
• DEX router and pair configuration are reviewed.
• Monitoring and incident response procedures are ready.
• Emergency guard controls are tested in a controlled environment.

Step 1 — Provision liquidity

• Initial liquidity is seeded under documented parameters.
• Liquidity operations are recorded with timestamps and transaction references.
• If liquidity locks are used, lock actions are documented and referenced.

Step 2 — Enable trading (manual)

Market activation is performed via manual execution of enableTrading. The activation event is recorded and can be referenced from the canonical Status page.

Step 3 — Guard window

After activation, constraints are typically kept strict for an observation window to validate stability and detect abnormal behavior.

Step 4 — Gradual relaxation

Constraint changes may be applied in stages. Changes follow forward-only policy: announce when appropriate, apply, then record.

Constraints and controls

During guarded periods, PVERSE may apply one or more constraints. Exact values may be parameterized and adjusted forward-only.

• Max transaction size (maxTx): limits per-transaction exposure.
• Max wallet holdings (maxWallet): reduces early concentration risk.
• Cooldown or rate limiting: reduces repeated rapid actions that stress the system.
• Allowed pairs or restricted routes: limits activation scope to known and monitored pools.
• Guard tiers: constraints may operate in staged tiers such as tight, moderate, and open.

Liquidity lock and adjustment policy

Liquidity operations are subject to operational risk controls. Where liquidity locking is used, the lock mechanism and evidence are recorded. Liquidity may still be migrated or adjusted forward-only under specific permitted conditions.

Permitted operational reasons

• DEX migration: moving liquidity to a new pool or router configuration.
• Security incident response: reducing exposure while investigating or remediating an issue.
• Protocol upgrade: controlled transitions required by contract or infrastructure upgrades.

Process requirements

• Actions should be announced where feasible and operationally safe.
• All actions should be recorded with timestamps and transaction references.
• Status updates should be reflected in the canonical Status page.

Transparency and auditability

PVERSE is designed to be operationally auditable. Market activation and liquidity events should be traceable through documented references. A canonical Status page may include:

• Market state: OFF, Guarded ON, Open, or Emergency Guard
• Activation reference: enableTrading transaction hash
• Current guard tier: tight, moderate, or open
• Liquidity events: seed, lock, migrate, or adjustment

Risk disclosures

• Markets can be volatile, especially when early liquidity is thin.
• Activation may be delayed or performed in stages.
• Constraints may be tightened, extended, or reintroduced to protect system operation.
• No representation is made regarding price, liquidity depth, execution quality, or returns.
• This documentation is informational only and does not constitute investment advice.

FAQ

Why is trading not enabled immediately?

Because early market activation is an operational risk event. PVERSE separates allocation and vesting from trading so the system can be stabilized and monitored before opening markets.

Does vesting continue if the market is OFF?

Vesting schedules are defined by their own policy and records. Market activation controls do not inherently change vesting; they govern trading and transfer conditions.

Can constraints change after launch?

Yes. Constraints may be adjusted forward-only based on operational stability, monitoring signals, and documented policy decisions.

Is liquidity locked?

If a lock mechanism is used, it will be documented and referenced. Liquidity may still be migrated or adjusted for permitted reasons such as migration, incident response, or upgrade, with records.

Will PVERSE support the price?

No. Liquidity operations exist to enable market function and reduce operational risk. No promise is made regarding price behavior or returns.

Where is official activation status published?

Refer to the canonical Status page for the current market state and recorded activation events.