As soon as we had our prototypes ready, we understood something is missing. Sure, the games are fun on their own, but we really wanted to add something to stand out – and that is how we decided to introduce Jackpots.

Jackpots are essentially side games that get played automatically and are designed to give big payouts – as in, bigger than your average payout within the game. Since our interface and design was more or less finalised, we were looking for Jackpots to be natively integrated into all games, but wanted to avoid severe complications, additional interface elements and so on.

Our games are also completely transparent and provably fair, and we wanted Jackpot games to work in a similar fashion. Normally, casinos implement Jackpots using some blackbox logic or a separate random number generator, but this would not work for us. Since all our games are already provably fair, we did not like the idea of keeping Jackpots somewhat separate and came up with a way to seamlessly integrate Jackpot rolls into the existing smart contract code.

Provably fair Jackpots

All our games are built upon a concept of Verifiable Random Function, a mathematical construct that allows smart contract to accept random numbers from a third-party and verify that they were produced using some agreed-upon initial (or seed) value. We have decided to implement a similar approach to Jackpots.

A high-level overview of how these work is:

1. We collect a fixed small Jackpot fee from the bets that take part in Jackpot For that matter we decided to simply enable all games over a certain threshold (0.1ETH, 1BNB) to automatically play for Jackpot.
2. We record the fact that the bet plays for Jackpot on blockchain to check that when the game is resolved (i.e. a random number is received) Every random number we get has a very decent amount of entropy, and we only use a part of it for the games themselves. Thus it seems logical to use a different portion of that random number to decide on Jackpot outcomes.
3. When we receive a random number for a game that plays for Jackpot, we use a portion of it as a number between 1 and 1000 and check if it matches some predefined value, 888 in our case. There is no particular reason why 888 was chosen – it just has to be between 1 and 1000, we could have gone with any other number without changing the scheme
4. If the number matches, we pay the user some amount as a Jackpot win. The random number has enough entropy left to randomise the Jackpot value too – after all, what’s fun in getting a predefined amount each time a Jackpot is won?

All in all, Jackpot logic is strikingly similar to that of our games, and this is intentional. This allows us to keep the smart contract simple, utilise our bullet-proof random numbers and provide a clear explanation with nothing happening behind the scenes.

Deciding on Jackpot amount

Let’s say a player wins a Jackpot, and we need to determine the amount to be paid to him. After a bit of rambling around, we came up with the following pay table:

With these chances, the player would get a payment of Tier 3 on average, but the amount would vary each time. Some lucky players might even strike a payout of 4× is stars align properly!

Now, we had to decide on what the base value would be. We did not want to have a fixed value there, but equally wanted Jackpots to follow our fairness claim. That is we decided that a base value would be set to Jackpot fee times Jackpot modulo so that the player would win as much as he is contributing to a Jackpot fund on average. The House can further adjust this value to increase the Jackpot amount for special events, for example.

In the interface

The website always displays current Jackpot fund value and notifies the user whether the bet plays (left) or does not play (right) for Jackpot:

Each history entry would also display whether the bet played for Jackpot (left) or did not take part in Jackpot (right):