Void & Error Correction Policy
This v0.1 defines the product and accounting principles for a LINBEI RICH production Wallet Round that cannot produce a defensible outcome under its effective rules. It is a policy framework and does not claim that Transaction Core currently provides automatic Void or refund functionality.
Version 0.1 · 2026-09-30
이 페이지의 일부 내용은 다른 언어로만 제공됩니다. 이 문서는 아직 정책 초안이며 실제 운영 지역에 맞는 법률 검토가 필요합니다.
1. Plain-language summary and scope
Void is not a way to erase a legitimate loss or let the platform rewrite history because an outcome is inconvenient. A production Round may enter Void review only when a Manifest Error, unrecoverable absence of an authoritative outcome, material ruleset/config defect, or another expressly published condition prevents defensible settlement. Frontend disconnects, animation mismatch, display delay or an unfavorable result do not create a Void where a valid authoritative server settlement exists.
2. Recover the original Round before Void
A network timeout, ambiguous response, client crash or retry should not create a second Round and should not automatically trigger Void. The platform should first recover or confirm the original Round through its idempotency key, round id, ruleset/config version, RNG evidence and authoritative server state. Void is considered only when the original Round cannot be reliably completed under its existing rules and the Void standard is otherwise met.
3. Baseline economics before payout
Define W = Σ |GAME_BET|, the sum of all authoritative GAME_BET debits linked to the Round. If the Round is validly treated as Void and no authoritative GAME_PAYOUT exists, the v0.1 baseline economic objective is an append-only REVERSAL credit of W so the Round's final economic net to the player returns to zero. Practice / 0 COIN Rounds have no authoritative Wallet debit and therefore create no financial refund.
4. Multi-action rounds and total wager
Blackjack, War and any game that can add exposure within the same Round must not refund only the opening bet. W is based on the actual authoritative GAME_BET debit total for that Round; where available and reconciled, total_wager_minor should agree with that total. Treatment of double, split, insurance, Go to War and other incremental wagers must remain aligned with each canonical game contract and Game Rulebook.
5. Correction math after payout
If authoritative GAME_PAYOUT rows already exist, define P = Σ GAME_PAYOUT and Correction C = W - P. The original accounting effect is -W + P; neutralizing a Void Round mathematically requires -W + P + C = 0. C > 0 means a positive REVERSAL credit is required; C = 0 requires no additional balance mutation; C < 0 implies a negative correction mathematically. A negative correction, automatic clawback, treatment of already-spent balance, notice, appeals and consumer-rights implications must not be automated merely because the formula exists and remain [LEGAL REVIEW REQUIRED] / [PRODUCT DECISION REQUIRED].
6. Ledger immutability and REVERSAL
Void and Correction must not delete, overwrite or fabricate original GAME_BET / GAME_PAYOUT Ledger rows. Corrections should be append-only, have a unique and idempotent correction / REVERSAL identity, reference the original round id, and record reason, system/operator actor, balance before/after and required evidence. REVERSAL is an accounting instrument, not a Game Payout, and the UI must not present it as an ordinary game win.
7. Club, missions, rewards and derived effects
As a baseline, a paid Round that is ultimately Void should not continue counting as valid wager toward Club lifetime wager, mission progress, promotion qualification or another benefit derived from genuine wagering. If a derived benefit was already issued, whether it is neutralized, preserved or handled case-by-case depends on program rules, cause of the error, good-faith user behavior and applicable law. [PRODUCT DECISION REQUIRED] [LEGAL REVIEW REQUIRED]
8. Evidence, review, finality and current implementation boundary
Void decisions should rely on authoritative Round and Ledger state, RNG / ruleset evidence, server logs and other reliable records, with an auditable reason. Temporary review is not itself a Void. A properly completed Round must not be reclassified merely because it later becomes economically unfavorable to the platform. The current casino_game_rounds schema is not represented as having a production VOIDED status. The Ledger taxonomy already includes REVERSAL, but this policy does not claim that automatic Void settlement, automatic refunds or automatic clawbacks are enabled in Production. Implementation requires separate migration, idempotency, reconciliation, health checks, user-notice design and legal review.