#Vault Breakers: Super Score — Max-Win Evidence, draft-v0.2

Supersedes draft-v0.1.md, which is retained unchanged.

DEV ONLY · NOT FOR PRODUCTION · NOT FOR CERTIFICATION.

#Command

cd /Users/admin/kiro/backend
go test -tags vbdraft -count=1 -v -run TestDraftMaxWinWitness \
    ./libs/mathengine/games/vault_breakers_super_score

#Method

mathengine.ValidateMaxWin cannot be used here. It routes through ExactCalculate, which refuses a tumble layout (ReasonTumbleLayout) because the cascade's outcome depends on symbols drawn after the initial grid. That refusal is respected rather than worked around.

The claim is therefore made the way this repository already makes it for a non-enumerable game: a reachability witness plus a containment argument.

#Reachability — WITNESSED

The witness is constructed, not searched, and deliberately so. The top prize band needs four SUPER_SCATTER on one snapshot. At weight 16 out of 50,000 that is

P(4+ SUPER_SCATTER on one snapshot)
    = sum over k>=4 of Binomial(30, 0.00044)
    ~ 1.0e-9         (about 1 in 1.0 billion snapshots)

which is far outside any seed scan. So a grid holding exactly that is evaluated through the engine's own pipeline — the same EvaluateWithGrid that backs the debug mock-spin route — and the result is asserted rather than hoped for.

The ceiling is reachable and it is paid. Not merely declared.

#A defect this witness found

Constructing it surfaced a real divergence: EvaluateWithGrid built its own RoundState without the cascade's scatter census or its collected charges, so the mock path reported a trigger and a 50,000× prize on the outcome while the executor that pays the prize saw an empty census and paid nothing. Found while building the v0.1 witness and fixed in backend commit f3b6309, covered by TestMockPath_PaysTheSuperScatterPrizeItReports.

That is the argument for constructing witnesses rather than only sampling: the debug path is the tool people use to decide whether the live path is right, and nothing else was exercising it against a maximum.

#Containment

Three independent bounds, each sufficient on its own:

1. Round clamp. runRoundOpts clamps the total to Paytable.MaxWinMultiplier whenever it is positive, and validation rejects a config where it is not (mathengine.go).
2. Generation stops. Reaching the ceiling ends free-spin generation rather than clamping the number afterwards, so no outcome is produced past the cap that a resumed or replayed sequence would then have to reproduce. Asserted by TestCapTermination_FreeSpinsStopGeneratingAtTheCap.
3. Cascade bound. One cascade is bounded at 1,000 steps (maxTumbleSteps), so no single spin can generate unbounded value even under a pathological refill.

#Frequency

The 50,000× band via four Super Scatters is about 1 in 1.0 billion snapshots — a lottery event, which is the correct order of magnitude for a game's declared maximum.

Other paths to the ceiling exist and are far more frequent: a long charge sequence whose values sum high against a large aggregate win, and a free-spin run doing the same across many spins. The maximum observed in the seeded confirmation run is recorded in ../simulation/draft-v0.2.md; it is a sample maximum, not a bound, and is reported as such.

#Unresolved

• The whole-game maximum is not exactly enumerable, and no exact max-win distribution is claimed. What is claimed is that the declared ceiling is reachable, that it is paid, and that it contains every path.
• The witness proves the top band. Intermediate bands (100×, 500×, 5,000×) are exercised by the seeded runs rather than by constructed witnesses.