Last updated
Last updated
The contract we will write is a simple flip game. A player will make a bet, in EGLD, and he will have a fifty-fifty chance to double.
As the contract creator we want to take fees from bets. They will be taken on players winning bets as a percentage of gains.
We assume here players bet with EGLD, but the contract we will write will be able to accept bets from any .
EGLD gains for winning bets are not magics, we will need to provision our contract with some EGLD.
Assume we give 5 EGLD to our contract and a player make 5 winnings bets of 1 EGLD each in a row. Our contract has run out of liquidity and cannot accept new bets, game over for us. What are the odds of 5 winning bets in a row happen ? 3.13% (binomial distribution)
The one million question : how much EGLD should we provide to the contract initially ?
This is more a matter of the maximum bet a player can do than the absolute EGLD balance of our contract. Why ? Simply because odds of running out of EGLD are the same if our contracts has 5 EGLD and a player make 5 bets of 1 EGLD or if our contract has 50 EGLD and a player make 5 bets of 10 EGLD.
So we need to limit the maximum bet a player can do, allowing us to take advantage of the law of large numbers. In this tutorial we will set the limit to the following : the maximum between 10% of the contract balance and 1 EGLD. This means that if our contract has a balance of 5 EGLD, the maximum bet allowed is 0.5 EGLD, if it has a balance of 10 EGLD or above the maximum is 1 EGLD.
This limit allow our contract to stand in the worst case 10 winning bets before running out of EGLD. The odd of having 10 winning bets in a row is 0.1 % which is acceptable for this tutorial. Note that thanks to fees we take on winning bets, the contract's balance should increase over the long term.
Instead of Ethereum, MultiversX allows developers to use native random numbers, but there is a major limitation : they can be predicted before sending a transaction. Indeed, random numbers depends of a block based random seed which is generated by validators, and if we know this seed we can predict numbers.
Good news : even if the seed is publicly known for the current block, we cannot predict the random seed of futures blocks.
What does it mean for our contract ? Simple, we should generate flips results in a separate transaction and in a different block, than the bet transaction.
Hence, there will be two transaction : first the transaction where the player makes the bet and second a transaction (in a separate block) where anyone else generates random numbers to make flips.
However no one is willing to pay gas for just generating random numbers, hence we need to create an incentive.
A natural incentive is to give a percentage of the bet to the one who makes the second transaction, we will next called this second transaction "the bounty".
An oracle or some async calls are also a way to have real random numbers but these solutions are out of this tutorial scope.
To make things more convenients, a single bounty generate randoms for every waiting bets in a row.
To summarise the flip contract :
Fifty-fifty chances to double the bet
Contract creator fees taken from winning bets gains
Flips are made in two transaction : the bet by the player and the bounty (which generate the random result) by anyone
We now have a better idea of what the contract will do and how. No more talk, let's code 💻
Last and important step before writing code