Some Projects Using Solidity
Thanks to Andrei and Crystal Mind Academy for providing this course: https://www.udemy.com/course/master-ethereum-and-solidity-programming-with-real-world-apps/
An externally owned account can deploy this contract and manage an on-chain lottery, where users can transfer ETH from their wallets directly to the contract, adding to a pool of money. A random number gets generated by hashing the block difficulty, the block timestamp, and the number of users in the lottery (nonce); then, when there are enough players, a winner is selected by taking the remainder of the random number divided by n, where n is the number of players. I don't use a secure random number generating algorithm since this is more of a learning project. The manager takes a 10% cut of the winnings.
This project required a lot more effort. A user who presumably wants to auction off one of their possessions can deploy this contract (a storage array tracks all auctions created by users using the AuctionCreator contract) and have others bid on the item. The auction ends when a given number of blocks have been mined since the start. Bidders have to bid in or in excess of a defined increment, where the highest bidder has to pay the binding bid, which is up to one incremental unit more than the second highest bid. If the auction is successful, the highest bidder gets the item for the binding bid price. The auction can either be canceled or finished after time runs out. In either case, users who didn't win the auction have to manually request that their funds be returned in order to prevent hacks, such as the DAO hack, where contracts run malicious receive() or fallback() functions.
Think of Kickstarter/IndieGoGo/GoFundMe etc. but better. A crowdfunding contract can be deployed by an admin, who sets the contribution goal and the deadline to meet it. We can keep track of all the contributors and how much was raised in total. Usually, contributors on crowdfunding sites have to trust that the person who created the fund will use the money for the intended purpose; however, it's hard to get them to be accountable for the spending. What this contract does differently is that it requires the admin to create a spending request that details who or what will receive the funds, how much money will be used, and whether or not the request was carried out. Spending requests need to be approved by the contributors in a majority vote, ensuring that the contributors' funds will be used in ways that align with the contributors' goals. Contributors can request a refund if the goal hasn't been met by the deadline.
In this project, I made an ERC20-compliant token named Cryptos (symbol CRPT). A founder can deploy the contract to create the token, with the entire supply of the tokens instantiated inside the founder's wallet. Mapping state variables keep track of every wallet's CRPT balance and who is allowed to transfer a given amount of CRPT from a given wallet address. My contract implements the ERC20Interface interface created by OpenZeppelin: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/9b3710465583284b8c4c5d2245749246bb2e0094/contracts/token/ERC20/IERC20.sol.
Building on top of the Cryptos contract defined in project #4, this contract lets an admin initiate an Initial Coin Offering (ICO) where the CRPT's founder's coins are offered up for sale at a rate of 0.001 ETH per CRPT. The ICO has 1-week deadline, which functions as a lockup period where sold tokens cannot be traded; a 300 ETH hard cap (limit) on total sales; a minimum investment of 0.1 ETH; a maximum investment of 5 ETH; and a deposit address to which the invested ETH will be transferred for security reasons. Investors can buy in by sending ETH directly to the ICO contract address or by passing an ETH value to the invest() function. The admin can halt and then resume the sale or change the deposit address if there is an issue. After the sale ends, any leftover tokens in the founder's wallet can be burned using the burn() function, setting the founder's balance to 0.