PVERSE
Token

Changelog

Forward-only record of PVERSE token policy, parameters, operational controls, and documentation-level clarifications. Each entry states what changed, why, user impact, and how to verify.

Published: February 11, 2026
Updated: March 24, 2026
Section: Token
Forward-only policy
This page is a changelog, not a marketing surface and not a promise of returns. Entries are append-only. Prior records are not silently rewritten. If a correction is required, a new entry is added.

Overview

The Token changelog exists to preserve an auditable history of policy and operational meaning across the PVERSE token layer. It records material changes to trading controls, fee policy, liquidity rules, treasury boundaries, vesting interpretation, network scope, and security-connected controls.

The purpose is not narrative polish. The purpose is record integrity. A system becomes easier to trust when readers can see what changed, why it changed, whether it had an on-chain artifact, and how to verify the effective state without guessing.

Scope

This changelog tracks effective changes to token policy surfaces and documentation changes that clarify operational meaning.

  • Market and trading controls, including activation and route restrictions.
  • Taxes and fees, including effective rates and classification boundaries.
  • Liquidity policy, treasury/reserve rules, and PCR-revenue-to-liquidity clarification.
  • Allocation, vesting, networks, security controls, and documentation-only clarifications.

Entry Rules

Every meaningful entry should explain what changed, why it changed, user impact, verification method, and rollback posture. If the change has no on-chain artifact, it must be treated as documentation-only rather than implied as an on-chain state update.

  • Major: affects market structure, user rights, or core token parameters.
  • Minor: clarifies behavior or adds non-breaking detail.
  • Patch: typo, format, structure, or link fixes without meaning change.
  • Timestamp standard: record in UTC, and include block number and transaction hash when available.

Current Effective Configuration

The snapshot below summarizes the currently effective configuration at a high level. If this summary ever conflicts with the live operational surface, the Status page is the operational source of truth.

Snapshot
Domain Effective setting Notes
Primary network BSC PVR is deployed and operated on BSC unless explicitly expanded later.
Trading Controlled enablement Trading activates through explicit controls. See Status Controls.
Taxes & fees Buy 0% · Sell 0% · Transfer 0% See Taxes & Fees for routing and boundaries.
Liquidity policy Policy-defined seeding + guardrails See Liquidity Policy.
PCR revenue routing PCR revenue contributes to token liquidity Subscriptions are purchased with in-game PCR funded through separate crypto top-ups, not with PVR.
Treasury & reserves Bounded operational custody See Treasury & Reserves.

Last reviewed: March 24, 2026 (UTC)

Categories

Jump to a category:

Timeline (Newest First)

Where a change is on-chain, entries should eventually include transaction hash and block number. Where a change is operational or documentary, verification should point to the canonical status or documentation surface.

Market & Trading

2026-02-11 (UTC) — Trading controls documented — Minor

Changed: Documented the operational sequence for controlled trading activation, including status gates and guardrails.

Reason: Reduce ambiguity and align public docs with the intended safety model.

Impact: No parameter change; clarity improvement for users, auditors, and integrators.

Verification: See Status Controls and Status.

Rollback: Not applicable. Documentation-only clarification.

Related docs: Status Controls, Security Model.

Taxes & Fees

2026-03-24 (UTC) — Zero-tax and zero-transfer-fee policy pinned — Major

Changed: Confirmed and pinned the effective fee parameters: Buy 0%, Sell 0%, Transfer 0%.

Reason: Establish a simple and fully transparent token-side fee model with no buy tax, no sell tax, and no wallet transfer fee.

Impact: No token-side deduction is applied on taxable market paths or wallet transfer paths under the current documented policy.

Verification: See Taxes & Fees. Add concrete transaction hash and contract parameter references once finalized on-chain.

Rollback: Only through a new changelog entry and a new effective update, if applicable.

Related docs: Taxes & Fees, Liquidity Policy.

Liquidity Policy

2026-02-11 (UTC) — Economic routing clarified (PCR → liquidity) — Major

Changed: Clarified that subscriptions are purchased with in-game PCR funded through separate crypto top-ups, and that PCR revenue contributes to token liquidity under policy-defined liquidity operations.

Reason: Separate in-game consumption from token spending and define the economic bridge between game revenue and token liquidity operations.

Impact: Users do not need PVR to purchase subscriptions; liquidity operations may be supported by PCR revenue flows under policy.

Verification: See Economic Cycle and Liquidity Policy.

Rollback: Any policy revision requires a new Major entry. No retroactive rewrite.

Related docs: Economic Cycle, Subscriptions.

Treasury & Reserves

2026-02-11 (UTC) — Treasury boundaries restated — Minor

Changed: Restated treasury and reserve boundaries, custody expectations, and verification posture.

Reason: Improve clarity and reduce misinterpretation of operational reserves behavior.

Impact: No economic parameter change; documentation clarity improvement.

Verification: See Treasury & Reserves.

Rollback: Not applicable. Documentation-only clarification.

Related docs: Treasury & Reserves, Security Model.

Supply / Allocation / Vesting

2026-02-11 (UTC) — Vesting / unlocks forward-only rule reaffirmed — Minor

Changed: Reaffirmed the forward-only record principle for allocation, vesting, and unlock administration.

Reason: Preserve consistent expectations for participants and administrators.

Impact: No schedule change by itself; strengthens guarantees around record integrity.

Verification: See Vesting & Unlocks and Allocation.

Rollback: Not applicable. Policy principle.

Related docs: Vesting & Unlocks, Allocation.

Bridges & Networks

2026-02-11 (UTC) — Network scope documented — Minor

Changed: Documented supported network scope assumptions and user guidance for bridges where applicable.

Reason: Reduce bridge-related user error and clarify what is supported versus unsupported.

Impact: No token parameter change; improves operational safety and documentation clarity.

Verification: See Bridges & Networks.

Rollback: Not applicable. Documentation-only clarification.

Related docs: Bridges & Networks.

Security Model & Controls

2026-02-11 (UTC) — Security model linked to controls — Minor

Changed: Linked the security model narrative to operational status controls, clarifying who can change what and under which constraints.

Reason: Provide a single readable audit trail for security assumptions and control surfaces.

Impact: No on-chain change by itself; improves understanding of safeguards.

Verification: See Security Model and Status Controls.

Rollback: Not applicable. Documentation-only clarification.

Related docs: Security Model, Status Controls.

Documentation-only

2026-02-11 (UTC) — Changelog structure established — Patch

Changed: Established a standard changelog format using Changed, Reason, Impact, Verification, and Rollback.

Reason: Improve consistency, readability, and auditability across future entries.

Impact: No policy change.

Verification: This page and its canonical URL.

Rollback: Not applicable.

Related docs: Token Overview.

Verification Guidance

Verification depends on the type of change. On-chain changes should eventually include transaction hash and optionally block number. Operational state changes should be confirmed through the canonical Status page. Documentation-only changes are verified through canonical documentation history and the published route itself.

  • On-chain: contract events, transaction hash, block number, and relevant parameter state.
  • Status: /status reflects operational toggles and live posture.
  • Docs: canonical routes under /docs/ define documentation-only changes.

Constraints

  • No price commentary, ROI claims, or forward-looking guarantees.
  • No implication that third-party UI changes alter token policy unless the canonical docs say so.
  • No publication of exploit-sensitive private operational details.
  • No retroactive rewrite of prior entries; corrections are appended as new records.

Integrity Considerations

A changelog only matters if it preserves traceability. That means readers should be able to distinguish between live on-chain state, operational state, and documentation-only clarification without flattening them into the same kind of claim.

  • Append-only discipline: corrections appear as new entries instead of silent edits to prior meaning.
  • Verification discipline: every entry should point to the best available proof surface.
  • Authority discipline: major changes belong to bounded control surfaces and should be logged here clearly.

Future Expansion

As more live operational events occur, this page should expand with concrete transaction hashes, block numbers, effective dates, and deprecation markers where needed. The structure should remain forward-only and should preserve a clear separation between executed state changes and documentation clarifications.

Summary

  • The Token changelog is an append-only record of policy, operational, and documentation-relevant changes.
  • The current effective snapshot summarizes live meaning, while the Status page remains the operational source of truth.
  • The current documented fee model is zero-tax and zero-transfer-fee: Buy 0%, Sell 0%, Transfer 0%.
  • PC revenue contributing to token liquidity is a documented economic policy bridge, not a hidden assumption.
  • Future updates should add concrete verification artifacts without breaking the forward-only record model.
Implementation note
Replace placeholder verification text with concrete transaction hashes and block numbers once relevant on-chain actions are executed. Keep this page append-only.