The problem Degen Trail: Jackpot Junction solves

Context: An On-chain Wheel of Fortune Game

Degen Trail: Jackpot Junction is an on-chain wheel of fortune game with a live market component. It combines the fast-paced thrills of gambling with the complexities of market strategy, resulting in a casino-style game in which the market—and individual skill—play a strong role in determining each player’s expected value.

In Jackpot Junction, players pay to spin the wheel for a chance to win $DEGEN or items (wagon parts). They assemble the parts into wagons that buff their spins, improving their odds of winning. Players can focus on improving their own wagons or on collecting and crafting items to sell to other players. Both strategies give them a chance to make money, either by winning $DEGEN with their buffed spins or by understanding the item economy and making advantageous sales.

(Note: For the Buildathon, we’ve deployed the Jackpot Junction contract on the Base Sepolia testnet, and the pool is in ETH.)

The Problem: On-chain randomness

Jackpot Junction features a fully on-chain and permissionless wheel of fortune mechanic. It solves the problem of generating randomness on chain by securely using block hashes as a source of entropy. We do not use any oracles. Our entropy solution could be used by other games and apps that feature die rolls, loot drops, or any mechanic that requires RNG.

The Jackpot Junction github repo includes our research proving that the wheel spins are fair: https://github.com/moonstream-to/degen-trail/blob/main/design/jj-blockhashes-entropy.md

Challenges we ran into

Syncing Frontend Animations with On-chain Activity

When players spin the wheel, the possible outcomes are: (1) nothing, (2) a small amount of $DEGEN, (3) a larger amount of $DEGEN, (4) an item, or (5) the jackpot (half of the $DEGEN in the pool).

Players then have two choices: ACCEPT (submit a tx to accept the prize) or RESPIN (pay a reduced amount to spin again).
Players have only 20 blocks to make their choice. If they don’t act in that time, they have to pay full price to SPIN again.
The timeline of a spin:
The player clicks ‘SPIN’. —> The wheel starts spinning. —> The tx is submitted on chain. —> The game contract returns the outcome. —> The 20 block ACCEPT or RESPIN timer starts. —> The wheel stops. —> The player sees the outcome. —> The player makes a choice.
Constraints:

• The wheel should accelerate and decelerate like a physical wheel.
• The wheel spin animation has to be short, or it will cut into the 20 blocks the player has to make a decision.
  • Otherwise, a competing game client with a shorter (or no) animation could draw away users by giving them more time to decide.
  • The time the SPIN tx requires will fluctuate, so the spin animation can’t have a fixed length..
• When the wheel starts spinning, the outcome of the tx is unknown. We can’t choose the starting point or the length of the spin animation based on the outcome.
  Our solution:
• A short spin animation that runs until the contract returns an outcome. The wheel starts to spin and accelerates.
• A second spin animation that fires once the outcome is known. It decelerates and stops on the sector of the wheel showing the prize that corresponds to the on-chain outcome.
• The second animation is brief and only minimally affects the players’ decision time.