{"id":15561945,"url":"https://github.com/ebyrds/lottery-dapp","last_synced_at":"2025-03-29T04:43:21.023Z","repository":{"id":158103736,"uuid":"633825477","full_name":"EByrdS/lottery-dapp","owner":"EByrdS","description":"Simple lottery application to practice Solidity and Blockchain concepts.","archived":false,"fork":false,"pushed_at":"2023-04-28T11:17:57.000Z","size":1584,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-02-03T14:32:49.963Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Solidity","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/EByrdS.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-04-28T11:16:21.000Z","updated_at":"2023-04-28T11:16:45.000Z","dependencies_parsed_at":null,"dependency_job_id":"8011458f-affd-4187-a326-917f93ae1772","html_url":"https://github.com/EByrdS/lottery-dapp","commit_stats":{"total_commits":2,"total_committers":1,"mean_commits":2.0,"dds":0.0,"last_synced_commit":"783ec789841fda41a1efb609977a55eeba0e5003"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/EByrdS%2Flottery-dapp","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/EByrdS%2Flottery-dapp/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/EByrdS%2Flottery-dapp/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/EByrdS%2Flottery-dapp/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/EByrdS","download_url":"https://codeload.github.com/EByrdS/lottery-dapp/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246140541,"owners_count":20729797,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-02T16:10:46.539Z","updated_at":"2025-03-29T04:43:20.994Z","avatar_url":"https://github.com/EByrdS.png","language":"Solidity","funding_links":[],"categories":[],"sub_categories":[],"readme":"# A project that involves building a simple decentralized lottery application\n\nRun tests with\n\n```\nforge test\n```\n\nThis Solidity project is a simple Lottery application.\n\nThe general idea is:\n\n- The `Admin` contract stores the administrator of the lottery.\n- The `Token` contract has the tokens that will be awarded for the winners,\n  1 token per player in each round.\n- The `Players` contract keeps track of the players who pay `1 ether` per ticket.\n- The `Lottery` contract ensures the round is started and ended appropriately,\n  and sends tokens to the winner. It doesn't send Ether, but Tokens. In\n  order to reward the winner, it has to be funded appropriately.\n- Tickets are sold in `ETH`, but the prize is awarded in `Token`s.\n\nThe intended steps for a run are:\n\n1. A user deploys the `Admin` contract, becoming the owner. (Ownership is transferable).\n1. The same user deploys the `Token` contract, specifying\n   the total supply.\n1. A `Lottery` contract is deployed, with references to the\n   `Admin` and `Token` contracts. (To the `Admin` contract, not to the user's address!)\n1. The `Lottery` contract will deploy its own `Players`.\n1. The administrator starts the lottery.\n1. The administrator opens the `Players` contract to start receiving players.\n1. Each player calls `players.play` and sends `1 ether` to\n   play in the lottery.\n1. The administrator closes the `Players`.\n1. The administrator funds the `Lottery` with enough `Token`s.\n1. The administrator finishes the `Lottery`, triggering\n   transfering of the funds to the winner.\n1. The administrator resets the `Players` contract.\n1. (At any moment) The administrator `withdraw`s all ETH fees from the `Players` contract.\n\nThis setup allows the same `Admin` to have control\nover multiple `Lottery`s, and they can all refer the same `Token`. It is also not possible for the same `Players`\ngroup to be playing in more than one `Lottery`, avoiding\nawarding multiple prices to the same pool, who payed only once.\n\nFor a complete example, take a look at the `test/Lottery.t.sol` tests.\n\n### Suboptimal processes\n\nFor the sake of **learning**, some processes are left suboptimal:\n\n- Many utilities, like `transferOwnership` and `noReentrancy` are available\n  in `Openzeppelin` libraries, which are not used here other than `ERC20`.\n- Testing the `Token` contract, which only inherits from `ERC20` is more a\n  visualization and practice exercise than actually testing it.\n- Further improvements, like a dynamic fee price, a dynamic minimum number of players, or multiple tickets per address, were left out for simplicity, as it seems they would add little value as a learning exercise.\n- The mapping of `Players.members` is erased manually. It would be much more gas efficient to just have a `mapping(uint256 =\u003e mapping(uint256 =\u003e Player))`, and increase the counter of the first dimension, effectively using a new and clean record of players. (Other variables would need to be in synchrony too). This would limit the number of lotteries to `type(uint256).max + 1` to avoid overflow.\n- Since all ETH funds are transfered in the `withdraw` function, and they are all sent to the administrator, there doesn't seem to be an actual need to avoid reentrancy in there.\n- The winner is calculated using the last block hash as a source of randomness. It is well known that this strategy is potentially dangerous, as miners have some inherence over it. (They can choose to discard blocks that may not benefit them)\n- The `Admin` contract is just storing an address that can be rewritten to transfer ownership. It may not be of a lot of use, since the same could be coded in the `Lottery` itself.\n- Finally, since the `Lottery` contract creates its own `Players`, all logic\n  of the players could very well be coded in the `Lottery`.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Febyrds%2Flottery-dapp","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Febyrds%2Flottery-dapp","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Febyrds%2Flottery-dapp/lists"}