#Magic Vault 5×3 — Math Specification

draft-v0.1 — DEV ONLY. NOT FOR PRODUCTION. NOT FOR CERTIFICATION. Not frozen. Internal tests and simulations are not external certification.

#1. Identity and provenance

The canonical config is not duplicated in this workspace. The SHA-256 above is computed from the exact bytes the binary embeds (magic_vault_5x3.RawYAML()), not from a separately read file.

#Relationship to hold_and_win_reference

hold_and_win_reference is a mechanic reference host, not a game. Magic Vault reuses its mechanic implementation, RNG draw order, replay contract and economic parameters, and inherits none of its base reels, base RTP, trigger frequency or whole-game RTP. The reference pack's final-v1.0 evidence is not evidence for this game.

#2. Bet and payout units

Mixing the two units is how a spec comes to quote an RTP ten times the real one. Pinned by TestLinePayoutsAreLineBetMultipliers.

#3. Locked rules (design-locked for Draft v0.1)

• Grid 5 reels × 3 rows; feature grid 5 columns × 3 rows, 15 cells.
• Canonical cell index column * 3 + row (column * Rows + row in the engine).
• 10 fixed paylines, left to right, beginning on reel 1, geometry as in the GDD §5.
• Symbol set WILD, COIN, H1–H4, L1–L4. No BONUS symbol exists.
• WILD substitutes for H1–H4 and L1–L4, never for COIN.
• COIN has no line payout at any count.
• Trigger: 6 or more visible COIN; triggering cells become the initial locked cells in place.
• hold_and_win/v1 economics: 3 initial respins, 43,000 PPM landing chance, regular coin values/weights 1:30, 2:25, 3:18, 5:15, 10:10, 20:2, prize weights regular:1000, mini:20@10×, minor:5@25×, major:1@100×, Grand 500× on a full grid replacing the sum, mechanic cap 500×.
• Whole-round cap 500×, applied once.

Pinned by TestApprovedPaylines, TestSymbolSet, TestCoinHasNoLinePayout, TestLockedHoldAndWinParameters.

#4. Mathematical model

#Reel model

The strips are weighted entries, not stops. One weighted draw per reel picks an entry index i; the visible column is entries i, i+1, i+2 of that strip, wrapping.

Two consequences that are easy to get wrong:

• Rows on a reel are not independent draws. Exactly 20 columns per reel are reachable, each a contiguous wrapping triplet. Any formula that multiplies per-row symbol probabilities assumes an independence this model does not have and will be wrong.
• The base state space is 20⁵ = 3,200,000 grids, not 1720⁵.

#COIN layout

Every strip carries a contiguous three-entry COIN run at indices 0–2. The number of visible COIN on a reel therefore depends only on how far the stop lands from that run:

This is the property that makes the trigger frequency exactly analysable rather than merely sampled. Scattering the run would leave every value test passing while this table became fiction. Pinned by TestCoinRunLayout and TestReelWindowCoinCounts.

#Reel strips and weights

All five reels have 20 entries and identical weight totals of 1720.

Interior contents are one 17-symbol ring — L1 H1 L2 L3 H2 L4 L1 WILD L2 H3 L3 L4 H4 L1 L2 L3 L4 (L1–L4 ×3 each, H1–H4 ×1 each, WILD ×1) — rotated by 0, 7, 14, 4, 11 on reels 1–5 so the reels are not identical. Entries 18–19 are the last two of the rotated ring.

The five COIN-adjacent stops carry the entire trigger and their weight is its only real lever. P(at least one visible COIN on a reel) = 5 × 44 / 1720 = 12.79%.

#5. Symbols and paytable

Line-bet multipliers. See GDD §6 for why WILD carries a 5-entry only.

#6. Evaluation order

1. Draw one weighted stop per reel; materialise the 5×3 grid.
2. Evaluate the 10 paylines; sum the line wins, each divided by 10.
3. Count visible COIN. If ≥ 6, run the Hold & Win and add its award (a total-bet multiplier, undivided).
4. Apply the 500× round cap once to the sum.

#7. Exact calculation

#What is exact, and what is not

mathengine.ExactCalculate refuses the whole config with NotEnumerableError{stochastic_feature} — correctly, because hold_and_win is a stochastic state machine, not a grid-determined feature. Pinned by TestPackIsNotEnumerable.

Exact results are therefore obtained for the two parts that are genuinely enumerable:

The conditional feature award is not exact and is never presented as such.

#Exact trigger probability

For each reel, the total integer weight of the stops showing each visible-COIN count is accumulated, then the five per-reel distributions are convolved. All arithmetic is int64: the denominator is 1720⁵ = 15,036,246,323,200,000, comfortably inside int64, so there is no floating-point rounding anywhere in the derivation. Probability mass is verified twice — by exact integer equality against the denominator, and as a float within 1e-12.

The same routine reproduces hold_and_win_reference's documented 1 in 155.4035 exactly, which is the check that the method matches the engine's reel model rather than a plausible model of it.

Result: P(trigger) = 0.0126493391, i.e. 1 in 79.0555 paid rounds.

#Exact distribution of initially locked cells

E[initial locked | trigger] = 6.4652.

#Exact base results

#8. RTP decomposition

Total RTP = exact base RTP + exact P(trigger) × E[Hold & Win award | trigger]
          = 0.559961      + 0.0126493391      × 31.6252
          = 0.559961      + 0.400038
          = 0.959998        (95.9998%)

Substituting sampled values for the two terms already known by enumeration would only add variance; the all-simulated cross-check is reported separately in ../evidence/simulation/draft-v0.1.md.

#Base balancing against the design target

The approved design targeted a 55.44% base RTP, derived from the reference harness's 32.4461× conditional mean. That mean is a property of the harness's distribution of initial locked cells (E = 6.7322), not of the mechanic alone. Magic Vault enters the identical mechanic with E = 6.4652 and measures 31.6252×.

Re-deriving the requirement:

required base RTP = 0.96 − 0.0126493391 × 31.6252 = 0.559962  (55.9962%)

The base paytable was retuned to that figure — four low-symbol entries moved (L1 ×4, L2 ×4, L3 ×4 and ×5). No Hold & Win parameter was changed. This is base balancing, not mechanic tuning. Recorded in ../changelog.md.

#9. Feature model

State machine, prize tables and settlement are hold_and_win/v1 exactly as accepted; see the GDD §8 for the player-facing statement and hold_and_win_reference's Final math for the mechanic derivation. Magic Vault changes only Columns: 5, Rows: 3.

Closed forms that carry over unchanged: E[regular coin] = 349/100 = 3.49×, E[prize] = 3915/1026 ≈ 3.815789×.

What does not carry over: the conditional mean, the full-grid rate and the feature RTP contribution, all of which depend on the entering distribution of locked cells.

#10. RNG and replay contract

• Round seed: <seed>:<roundIndex>.
• Feature seed: HoldAndWinFeatureSeed(roundSeed) = roundSeed + ":hold_and_win".
• Start sub-seed: featureSeed + ":hold_and_win:start".
• Step sub-seed: featureSeed + ":hold_and_win:step:<stepIndex>".
• Step identity: replayIdentity + ":step:<stepIndex>".
• A non-triggering round consumes no feature randomness.
• Start draws only for cells already showing COIN; a step draws only for empty cells, in cell index order. A locked cell is skipped before any draw, so the draw count equals the empty cell count exactly.
• Prize draw order is kind first, then value only if the kind is regular.

TestStepExecutionEqualsRunToCompletion rederives all of these by hand and proves that one-step-at-a-time execution and whole-feature execution produce byte-identical cells and awards on the 5×3 layout.

#11. Monte Carlo specification

Feature initial states are drawn from Magic Vault's own exact trigger distribution — the sampler draws per-reel stops from P(stops | total visible COIN ≥ 6) and its empirical distribution of initial locked cells is checked against the exact one at every count. Results in ../evidence/simulation/draft-v0.1.md.

#12. Max-win analysis

This is a reachable-value proof plus a containment argument, not an exhaustive proof: the engine's exact max-win calculator does not cover a stateful stochastic feature. Detail in ../evidence/max-win/draft-v0.1.md.

#13. Open, locked and tuned parameters

#14. Known limitations and risks

1. Not exactly enumerable end to end. The feature term is a Monte Carlo estimate with a standard error of 0.0202× on the conditional mean. The total RTP inherits that uncertainty.
2. The all-simulated total is a weak check at this sample size. At 2,000,000 rounds its standard error is 0.32 percentage points — wider than the ±0.30pp acceptance band. It is reported as a compatibility check, not as the acceptance measurement.
3. WILD 3- and 4-of-a-kind are unreachable under the shared LinesEvaluator (§5, GDD §6). If the product wants those rows to pay, the evaluator must change — a shared-engine decision, not a pack decision.
4. The full-grid rate is estimated from few events in the whole-game run (27 of 25,125). The feature-conditioned run's 0.0743% ± 0.0027% is the figure to rely on.
5. No runtime parity corpus. Magic Vault is not registered in libs/mathengine/parity; recording new vectors is out of Draft scope. Reference↔runtime parity for this game is therefore unproven and is a prerequisite for any Final.
6. Shared-evaluator exactness is internal. The exact base figures come from the same engine that executes the game; they are internally exact, not independent verification.
7. Not certified. No external laboratory has reviewed this math.

#15. Draft status

draft-v0.1. Not frozen, not published, not routed, no feature flag, no deployment. Tuning, runtime handoff, parity vectors and any Final version require separate explicit approval.