SpinLottery: prize-lock/weight mismatch bricks higher-rarity spins

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: [[RipIt]]-security-review_2025-04-25. The historical source/toolchain is unavailable; this entry is documentation only and claims no executable Forge PoC.

Vulnerability classes: vuln/logic

Reproduction: a faithful minimal reproduction of the vulnerable finding — the vulnerable code is reproduced verbatim (marked @>) with faithful minimal doubles; local deploy, no fork.

Root cause#

Prize locking does not reserve a prize for every weighted rarity, so a spin whose VRF value maps to a higher rarity with no locked prize reverts in fulfillRandomness - the user's paid spinCost is permanently stuck (DoS).

SOLIDITY

        // Iterate through rarities to find where the random value lands
        for (uint8 i = 1; i <= maxRarityId; i++) {
            RarityConfig memory config = rarityConfigs[i];
            if (config.active) {
                cumulativeWeight += config.weight; // @> VULN (this line)

Why it's exploitable here#

Attack path#

flowchart TD S0["Step"] S1["Step"] S2["Step"] S3["Step"] S4["Vulnerable line"] H["Prize locking does not reserve a prize for every weighted ra"] S0 --> S1 S1 --> S2 S2 --> S3 S3 --> S4 S4 --> H

Marked-line walkthrough (Playground)#

The EVM Playground pins each step to the exact executed source line in 0x671d353a77…:

L67 — Step: Executes function setRarity(uint8 id, bool active, uint128 basePrice, uint256 weight) external {
L84 — Step: Executes for (uint8 i = 1; i <= maxRarityId; i++) {
L91 — Step: Executes if (totalRarityWeight == 0) revert InvalidWeightConfiguration();
L103 — Step: Executes for (uint8 i = 1; i <= maxRarityId; i++) {
L106 — Vulnerable line: Executes cumulativeWeight += config.weight;
L123 — Step: Executes lockedPrizes[i] += 1;
L134 — Step: Executes lockedPrizes[rarity] -= 1;

PoC#

Registry (Foundry, local deploy — verbatim vulnerable source + harm-asserting test):

BASH

cd 62540-h-03-prize-locking-mechanism-inconsistency-with-weight-propo_exp
forge test -vvv

The browser Playground replays the same synthetic opcode-for-opcode and measures the harm. Both gates are green (registry forge test PASS + Playground _verify-poc VERDICT: PASS).

Sources & further analysis#

Reproductions & code

No executable Forge reproduction is claimed; the historical source/toolchain was unavailable for this finding.
AuditVault finding: [[RipIt]]-security-review_2025-04-25.
Upstream DeFiHackLabs PoC directory: src/test.

Alerts & third-party analyses

DeFiHackLabs incident explorer: search "SpinLottery: prize-lock/weight mismatch bricks higher-rarity spins".
Web3Sec X hacked database: search.
Rekt leaderboard: search.
Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.

Source-level debugger — step opcodes and Solidity in sync