Fire Chain (Fire Lotto blockchain)

May 4, 2018 · 3 min read

Currently scaling and transaction speed are the main trends in blockchain development. The main idea is to replace proof of work by proof of stake approach to reduce the cost per transaction and to increase the speed.

Bitcoin Lightning, Ethereum Raiden, Neo Trinity — all these projects allow conducting instant transactions with very low gas cost. Some of them already have working versions and used in blockchain.

This approach is very applicable for blockchain for gambling where most games can’t exist without instant and cheap transactions.

We, at FireLotto, would like to introduce our own implementation of instant micro transactions outside of blockchain with transparent and decentralized blockchain implementation by using Ethereum smart contracts. Please meet FireChain!

Fire chain

The Game flow:

Once player makes a deposit in Etnereum smart contract, the gaming sessions begins.

When this server connection is established, the server generates a secret key.

When player makes each step in the game, she sends the selected bid and the random generated number. This number is generated on the client side and sent out automatically, but the player can see the number and have an option to change it.

Next we have a public generated hash that is consisted from the secret server key, the game bid and the keys generated on the client side:

PublicResultHash[i] = Hash(ServerSecretHash[i-1], ClientBet[i], ClientRandomSeed[i])

This hash is sent to the client and we use it as the random generated number for the current gaming step.

Since this hash can’t be predicted and it has a very long length, we have equal chances of getting random numbers. The server secret key for the next gaming step is created as the hash from the previous secret step and public hash result:

ServerSecretHash[i] = Hash(ServerSecretHash[i-1], PublicResultHash[i])

By using this approach we generate a number of blocks (sequence of blocks) where each secret hash has a dependency from the previous step’s secret hash, random client numbers, bids and results. We also have a rule when the initial server secret, the sequence of random numbers and bids define the gaming results.

Once the game is over it writes the results in the Ethereum smart contract. Next it’s been verified and the player gets results.


The server has influence only on the result how the secret key is created when the game starts.

The server can’t predict what random numbers the client provides. As a result the server can’t manipulate or change the future game results.

In this case we have the smart contract that checks all transactions and it has open source code as a guarantee to have all calculations made by the game rules.

Once the game session is audited by the smart contract all server secret keys become available in the smart contract that is written on blockchain.

The public can always make sure in the transparency of game and its results.

On another end the player can never predict the results of the game since she doesn’t know the secret server hashes and receives only result hashes.

It’s impossible to find out the initial data by using results from these hashes.


This system allows conducting quick gambling games without overloading Ethereum notes by gaming transactions, without delays and gas payments for each step in the game.

By using this approach we still have advantage of the classic blockchain — the decentralized transparency of transactions and results.

Such approach is very well suited for classic slot machines, roulettes, wheels of fortune and other lotteries.

This system allows conducting the decentralized audit of initial random combinations in complex games and audit of initial steps such as distribution of cards in poker.

By using this approach we have full transparency of blockchain in our lottery.

Join us: