PVERSE
REFERENCE

Changelog Index

Forward-only change records. Find what changed, why it changed, impact, and evidence across SSOT, code, chain, and operational logs.

Published: March 23, 2026
Updated: March 23, 2026
Section: REFERENCE
Rule boundary
This is an index page. It does not contain the full historical record itself. It points to the correct changelog location and defines how records must be written.

Overview

This page is the directory for all PVERSE changelogs. It exists to make changes easy to find and easy to verify across documentation, policy, infrastructure, market activation, and gameplay systems.

Every change should be represented as a forward-only record: no silent rewrites, no retroactive edits, and no ambiguity about the source of truth. This page helps readers find the right history surface quickly and interpret it correctly.

Scope

Changelog Index is a reference directory and rules surface for historical change tracking across PVERSE.

  • pre-filtered views such as breaking changes, security advisories, policy changes, and ops or incident logs
  • the index map showing where each class of change should be filed
  • minimum entry format requirements and tagging standards
  • evidence policy and forward-only correction rules

Core Model

The model is simple: changelogs are distributed by ownership, but indexed centrally for discovery. This page does not duplicate history. It points to the correct history surface and defines the minimum discipline every changelog should follow.

  • forward-only records only
  • canonical sources remain SSOT, code, chain, and ops logs
  • every entry should state impact and evidence clearly
  • changes must be filed in the surface that owns the meaning of the change

Operational Behavior

When a change happens, the first question is not “how do we describe it,” but “where does it belong.” Token and market history should not be buried in docs changelogs. Infrastructure incidents should not be filed as gameplay balance notes. This index helps route changes into the correct record set.

When a correction is required, the system must preserve historical integrity by appending a new correction entry rather than modifying the earlier one. This applies across docs, policy, infrastructure, and gameplay changelogs.

Constraints

  • this page is an index and filing guide, not a full event ledger
  • screenshots are context only and should not be treated as primary proof
  • every meaningful record should link to stronger evidence when available
  • changes must remain discoverable by category, severity, and owning surface

Integrity Considerations

A changelog is only credible if the reader can tell what changed, why it changed, who was affected, and what evidence supports the claim. This page protects that credibility by forcing routing discipline, evidence discipline, and correction discipline.

  • history remains append-only and auditable
  • ownership boundaries reduce ambiguity and duplication
  • consistent tags and minimum fields improve searchability and trust

System rules

  1. Forward-only. Past entries are never edited. Corrections are new entries that reference the original.
  2. Canonical sources. SSOT defines rules and numbers. Code enforces. Chain and ops logs provide evidence.
  3. Time discipline. Use UTC timestamps for records; you may add KST as a convenience.
  4. Link discipline. Every entry should link to evidence: SSOT diff, commit hash, tx hash, dashboard or log keys.
  5. Audience clarity. Each entry must state impact: who is affected and what action is required.

Pre-filtered views

These are recommended views. Implement them as separate pages later, or keep them as anchors that point to relevant changelog sections.

  • Breaking changes — compatibility breaks, new constraints, removed behavior, migrations required.
  • Security advisories — key handling changes, incident learnings, patches, and mitigations.
  • Policy changes — participation rules, vesting, trading activation, DEX and LP policy.
  • Ops & incidents — outages, degraded modes, root cause summaries, and postmortem actions.
Severity tags
Use consistent tags for scanning and search: BREAKING, SECURITY, POLICY, OPS, FIX, PERF, DOCS. If you use a label system elsewhere, mirror it here.

Index map

Below is the recommended directory map. If you already have a changelog page, link it here. If not, keep the placeholder and create it when the first entry exists.

Protocol / Token / Market

  • Protocol changelog — supply, allocations, vesting rules, token identity, chain policy.
  • Market activation log — enableTrading events, restriction toggles, launch boundaries.
  • DEX plan / liquidity log — pools, LP policy, routing constraints, fee policy, staging plan.

Participation (GENESIS / FOUNDERS)

  • Genesis admin changelog — entry rules, locked pricing snapshots, lockups, bonuses, caps.
  • Founders admin changelog — founders bonus policy, vesting cadence, distribution rules.
  • Entry UX changelog — deposit flow UI, strings, status definitions, and user-facing changes.

Infrastructure / Ops

  • Deposit engine changelog — watcher, settler, and commit behavior changes, confirmation policy, idempotency rules.
  • Observability changelog — metrics, logs, alerts, dashboards, incident signals.
  • Operations runbooks changelog — runbook additions or updates, escalation and playbook changes.
  • Reliability limits log — rate limits, backoff rules, queue limits, timeouts, finality windows.
  • Security model changelog — auth, key management, account recovery, and access control changes.

Game systems

  • SSOT economy changelog — prices, distributions, success rates, fees, EXP tables.
  • Assets / art pipeline changelog — style locks, template changes, asset naming policies.

Docs & reference

  • Docs structural changelog — navigation, routing, templates, and docs system changes.
  • Glossary & definitions log — new terms, updated definitions, deprecated terms.

Entry format (minimum required fields)

Every entry must contain enough information to force clarity and verification. If the entry is missing any required field, it is incomplete.

  • Date (UTC) and optional local time
  • Version (or release id) if applicable
  • Category (one of the index map sections)
  • Severity (BREAKING / SECURITY / POLICY / OPS / FIX / PERF / DOCS)
  • What changed (one line)
  • Why (one line)
  • Impact (who is affected and what action is required)
  • Evidence (SSOT diff / commit hash / tx hash / log keys)
  • Rollback / mitigation (if rollback is not possible, state mitigation)
No screenshots as proof
Screenshots can help with context, but evidence must be linkable and durable: SSOT diff, commit hash, on-chain tx hash, or logs and dashboard keys with time ranges.

Filing rules (where to record a change)

Use this mapping so changes land in the correct place and stay searchable.

  • SSOT numeric changes → SSOT economy changelog + SSOT diff evidence
  • Deposit watcher / settler / commit behavior → Deposit engine changelog
  • Runbook or escalation procedures → Operations runbooks changelog
  • Key handling / auth / recovery → Security model changelog
  • Participation policy (bonus / lockup / entry) → Genesis or Founders changelog + POLICY tag
  • Market activation (trading enable, restrictions) → Market activation log + tx evidence
  • Docs structure / definitions → Docs structural changelog or definitions log

Evidence policy

Evidence is what makes a changelog credible. Use the strongest available artifact.

  • SSOT diff — required when rules or numbers change
  • Commit hash — required for code behavior changes
  • On-chain tx hash — required for on-chain policy toggles or upgrades
  • Ops logs / dashboards — required for incidents and mitigations, including time window and key

Corrections (forward-only)

If a past entry is wrong or incomplete, do not edit it. Publish a new correction entry and link both ways.

  • Title format: CORRECTION: <original entry title>
  • Must include: what was wrong, corrected statement, and updated evidence
  • Optional: add a correction link line on the original entry if your process allows small annotation-only links

Appendix: recommended tags

Keep tags short and stable. Prefer one primary tag plus one or two secondary tags.

  • BREAKING — migrations required, backward-incompatible behavior
  • SECURITY — auth, keys, recovery, permissions, incident response
  • POLICY — participation and market policy
  • OPS — operations, runbooks, reliability limits, incident learnings
  • FIX — bug fixes
  • PERF — performance-only changes
  • DOCS — documentation-only changes
Implementation tip
Later, you can auto-render latest entries by loading a single JSON file with forward-only append behavior and displaying the newest N items here. Until then, keep this page as a strict index plus rules reference.

Future Expansion

This page may expand over time with richer pre-filtered views, generated latest-entry panels, and direct lane-level changelog discovery links. Even as it grows, it should remain an index and filing standard rather than a duplicate global history ledger.

Summary

  • Changelog Index is the central discovery hub for forward-only change history across PVERSE.
  • It defines where changes belong, how entries should be written, and what evidence is required.
  • It preserves ownership boundaries so each change is logged in the correct surface.
  • It strengthens trust by enforcing append-only correction rules and durable evidence discipline.