Magic Vault 5×3 — Max-Win Evidence, draft-v0.1
DEV ONLY · NOT FOR PRODUCTION · NOT FOR CERTIFICATION.
Commands
Method boundary — read this before quoting the number
This is a reachability witness plus a containment argument, not an exhaustive proof.
mathengine's exact max-win calculator (ValidateMaxWin → ExactCalculate) cannot cover
this game: hold_and_win is a stateful stochastic machine and the engine correctly refuses to
enumerate it. So there is no exhaustive enumeration of every reachable round outcome, and none
is claimed. What is proved is:
- Reachability — a deterministic, reproducible path that returns exactly 500×.
- Containment — that no path can return more, by construction of the two settlement branches plus the exact base bound, corroborated by 3,000,000 executed outcomes.
A theoretical upper bound is never described here as a reachable result, and the reachable result is never described as an exhaustive bound.
1. Reachability — 500× is attained
1a. Deterministic full-grid settlement
mathengine.SettleHoldAndWin applied to a constructed 15-of-15 locked grid returns exactly
500, and does so at three different per-cell prize values:
Three values, deliberately spread either side of 500, so an implementation that added the
Grand to the coin sum instead of replacing it could not agree by coincidence. In all three
cases settled.FullGrid() == true and AwardMultiplier == GrandMultiplier == 500.
Test: TestMaxWinIsReachableAtExactly500x.
1b. End-to-end round witness
A complete paid round, reproducible from the seed alone:
Pinned as golden vector trigger_full_grid_grand and re-checked in
TestMaxWinIsReachableAtExactly500x. Determinism across repeated execution is asserted by
TestGoldenVectorsAreDeterministic.
2. Containment — nothing exceeds 500×
2a. The base game cannot reach the ceiling — EXACT
Full enumeration of all 3,200,000 reachable base grids:
Because the base maximum is 64× against a 500× ceiling, the round cap can never bind on a base win. This matters beyond the max-win claim: it is what keeps the base and feature contributions additive, and therefore keeps the RTP decomposition valid.
Test: TestExactBaseMaxWinIsContained.
2b. Both feature settlement branches are bounded by construction
hold_and_win/v1 has exactly two settlement branches, and both are bounded at 500×:
The clamp is witnessed rather than assumed: a constructed state of 14 locked cells at the Major (1,400× accumulated, one cell short of a full grid, zero respins remaining) settles at exactly 500.0000×. That state is far above anything these reels produce and exists precisely to make the clamp fire.
Test: TestOrdinarySettlementIsCappedAt500x.
TestSettlementRefusesAPlayableFeature covers the opposite error: settling a feature that is
still playable is refused, so the bound cannot be reached by paying out early.
2c. Round-level ceiling
Paytable.MaxWinMultiplier = 500.0 is applied once to the whole round after all features. Base
(≤ 64×) plus feature (≤ 500×) can in principle sum above the ceiling; the round cap clamps that
to 500×. The maximum round award is therefore 500× on every path.
2d. Corroboration by execution
3,000,000 executed outcomes, nothing above 500×, and the ceiling attained in both. Every golden vector additionally asserts its own round total against the ceiling.
3. Frequency of the maximum
At the exact trigger rate of 1 in 79.0555, the feature-conditioned figure puts the maximum win at roughly 1 in 1,064,000 paid rounds. That is an estimate derived from a sampled rate, not an exact frequency, and it carries the sampling error of the 743 events behind it.
4. Declared value
MaxWinMultiplier: 500.0 in the canonical config is reachable and exact, not an
advertised ceiling above anything a player can hit. It equals the mechanic's own cap and its
Grand, so one number bounds the round and max-win evidence is a single claim.
5. Unresolved
- No exhaustive enumeration of the whole round exists or can exist while the feature is stochastic. The claim above is a witness plus a construction argument, corroborated by 3,000,000 outcomes.
- The frequency in §3 is estimated, not exact.