Mining

Overview

Mining is the execution layer that turns eligible gameplay state into recorded outcomes. It explains how mining actions are evaluated, how results become claimable or commit-ready, and how those results are preserved as forward-only history under authoritative server rules.

This page is descriptive rather than balance-final. It defines the meaning of mining, its two-track structure, timing authority, replay protection, and record integrity while leaving exact numeric yields, cooldown values, caps, and distribution tables to future SSOT-controlled configuration.

Scope

Mining defines gameplay outcome production and recording inside the Game Systems layer.

• two-track mining behavior: mineral discovery mining and fixed PVR mining
• server-time window resolution, cadence interpretation, and claim timing
• anti-replay, anti-duplication, and append-only outcome recording
• cooldown, cap, and eligibility boundaries that constrain mining throughput

Core Model

The core model is that mining consumes an eligible state and produces an auditable outcome. Discovery determines what may appear, mining resolves what is actually produced or claimed, and code commits that result as durable history without retroactive rewriting.

• mining outcomes are resolved server-side rather than by client presentation
• mineral mining and PVR mining are separate tracks with different resolution logic
• window identity and replay protection are part of mining truth, not optional UX features
• parameter changes affect future windows only and do not rewrite past recorded outcomes

Operational Behavior

Mineral mining consumes the eligible resource space produced by Discovery and resolves a gameplay outcome under current runtime rules, tool context, and policy boundaries. PVR mining follows a different path: it is a fixed-yield claim track that becomes eligible once per authoritative 8-hour interval.

Both tracks follow the same high-level enforcement pattern. The system resolves eligibility, maps the request to an authoritative server window, prevents duplicates or replayed claims, computes the appropriate outcome for the active track, and then commits a forward-only record. UI may render the result, but UI does not establish truth.

Constraints

• this page does not hard-code final yield amounts, distribution tables, cooldown seconds, cap values, or grace tolerances
• mining does not define protocol-level invariants, token allocation rules, or participation administration
• client clocks, countdowns, and retries do not override server-time window authority
• future tuning changes apply forward-only and do not silently mutate historical mining records

Integrity Considerations

Mining integrity depends on separating meaning, configuration, and enforcement. Docs define what mining is, SSOT owns mutable numeric parameters, and code enforces windows, caps, cooldowns, idempotency, and append-only commits. This keeps disputes clear and preserves a trustworthy historical record even as tuning evolves.

• duplicate clicks, retries, or repeated requests must resolve idempotently or fail without double-commit
• authoritative mining truth is the committed server record rather than the client display state
• historical mining outcomes remain auditable across future balance and policy updates

Future Expansion

As PVERSE expands, mining may connect to richer tool influence, deeper window logic, stronger live-ops event layers, and more explicit separation between descriptive mining rules and balance references. The conceptual model should remain stable: mining resolves eligible gameplay state into committed forward-only history.

Summary

• Mining defines how gameplay outcomes are produced and recorded in PVERSE.
• It includes two tracks: mineral discovery mining and fixed PVR yield every 8 hours.
• Server-time authority, replay protection, and append-only commits are core to mining integrity.
• All mining updates and tuning changes follow forward-only interpretation.