(GDFL) GDF Lotto - A failed attempt at a lotto smart contract

DO NOT USE

It seems that there are some flaws with the contract code !!! Huh

It worked on the test environment fine, but the tx-fees on the mainnet are something that needs to be considered Sad

I'm leaving this here, so if anyone wants to look at the code, and avoid the mistakes made in it

.... I will update more on the mistakes in the contract code as I figure them out

GDF Lotto (GDFL)

A failed attempt at a lotto smart contract!!

Contract address: 0xD29c0213314151807Cc11F3DC585a788040f74D6
Name: GDF Lotto
Symbol: GDFL
Decimals: 18
Supply: as big as the players put in the jackpot round Cool

GDF Lotto (GDFL) is a lottery contract that will award its winner 99% of the jackpot (1% goes to the contract address) on a daily basis.
Each player can buy as many tickets as they wish, each ticket is at 1 Finney (0.001 ETH).
A maximum of 100 tickets can be bought at one time, with no limit to how many times each player can participate.
Every 6500 ETH blocks (which is avg. 1 day), the contract will pick a random ticket number, and awards 99% of the jackpot.
After each draw, the tickets are reset, and a new jackpot is started
1% of the jackpot goes to the contract address

This is my first deployed contract, so as it happens, I forgot to add any events emitters!! Roll Eyes

but the code should fine to do the task it supposed to do.

This is not a Token like most of other Tokens out there, there is nothing to hold after each round. You just buy the tickets for each round, and at the end of each one, all tickets are deleted, and jackpot prize goes to the winning ticket.

There will be a website for the contract to help interacting with it, but for now, if you are familiar with Metamask and Remix, you can directly connect to the contract through Injected Web3 option and adding the contract address in At Address

The following are the public functions:

buyTicket: will allow you to buy lotto tickets, each ticket valued at 1 Finney (0.001 ETH)
jackpot: will show the current running jackpot size, in number of tickets sold, each at 1 Finney (returns: current round no. of tickets sold)
playerTickets: will show the player's current number of tickets bought (input: address, returns: no. of tickets)
raffleTickets: will show the addresses of player in the current round (input: index, returns: address)
raffles: will show each rounds winning info (input: index, returns: block no, jackpot size, winner address)
contractBalance: will show balance in the contract, when in round then will include jackpot, when jackpot just started then shows remaining balance in the contract from the 1%
raffleBlocks: will show set number of blocks for each round, currently set at 6500 blocks, and can be set by setRaffleBlocks

The following are admin functions (created to manage the contract):

setRaffleBlocks: admin function to set raffleBlocks variable (in case in future I want to change the duration of each round)
setWithdrawAddr: admin function to set withdrawal address (for the 1% in the contract address)
withdraw: admin function to withdraw to address set above (from the 1% in the contract address)
inject: admin function to add funds to the contract address (in case needed)

Notes:

Tickets are calculated as (net amount received) / 1000000000000000 = no. of tickets
The 1000000000000000 is equivalent to 1 Finney, or 0.001 ETH
So if net amount received is 0.0015 ETH, this will result in only 1 ticket, so try to make sure that not too much "dust" is sent to the contract!
raffleBlocks is set to 6500 blocks, which is a little bit above the daily average ethereum blocks, yet this variable can be changed by the admin (me) to make each round last longer, which should eventually result in a bigger jackpot. My original time was 10 days for each round, which is about 65000 blocks, but I though in the beginning its better to shorten the time span of each round just to make sure that things work alright
If 6500 blocks passed, and only 3 participants have bought tickets, then contract will wait until the 4th participant buys a ticket, so a minimum of 4 participants is required for each round

Well, this is all I can think of right now ... Let's see how this works

and I will keep updating here as more comes up