Hello edoka, you have a great submission. I have gone through your contract and here is my feedback.

Updates

Below are the updates and the bug fixed I made to your project:

• Fixed a bug that sends funds before changing state variables. This kind of bug can lead to reentrancy attack of smart contract.
• Added more comments to document contract.
• Added checks to first confirm if contract has enough ethers before owner can withdraw all ethers from the contract.
• Added checks to first confirm if the amount owner want's to withdraw is exceeds the contract balance when user want's to withdraw part of ethers from contract
• Created a new function to create new course before users can purchase the course.
• Optimised contract to used built in solidity variable instead of hardcoded values that might lead of errors.

Thanks

You've got a great submission here @motiv8. I went through your project and here is my feedback.

• The project was not well documented so I added more comments to make it more readable
• I found some typos in the project which might lead to unexpected behaviors which I fixed.

My advice for you concerning this project is that you should try as much as possible to make your project as clear and understandable as possible. When your contract grows too large, you can split it into different files to increase readability. I saw that you used a lot of computations in your contract without clear explanations of what they actually do. For cases like this, you can also add inline comments to explains what a complex computation in your code does. Thanks.

Great submission here Nartey, I have gone through your contract, and tested it as well, and I discovered it is well written and documented as well, except for some issues I discovered, fixed and added in my pull request. Below is a summary of the issues I found in your contract:

• Found an bug in the "withdrawChargedFees()" function of your contract that prevented admins from withdrawing charged funds stored in the contract. I discovered that you set the "chargedFees" value to 0 on every withdrawal, which allows the admins to withdraw 0 ethers anytime the function is called. I fixed this by first storing the value in another variable before setting the "chargedFees" to 0, and then allowing the admin to withdraw the amount stored in the new variable.
• Another issue I found in your contract is that your "startAuction" function does not add the current time to the "endTime" parameter entered by the user. Since most users will find it hard to know the current EPOCH time, I fixed this problem by adding the time (in seconds) entered by the user to the current block timestamp in order to improve the user experience.

That's my take on your project. Thanks

You have a great submission here. I have gone through your contract and here is my feedback and updates I made to the project.

• In the price variable, you used a decimal number to get the price of ether users are to pay for minting. I just want to inform you that solidity don't fully supports floating point numbers and you might run into unexpected results when you use it like that next time. I updated it to use division instead which is prone to errors.
• Added check to first confirm if there is enough funds in contract before withdrawing from the contract.
• Added more comments to contract.
• Added new function to first check if there is any ether in contract before withdrawing from the contract.
• Added a Counters library for more secured token ids when minting to avoid underflow or overflow.
• Added new events to contract.

Thanks

Nice submission here Georgesimon. I was able to go through your contract and I learnt somethings from it as well. I also observed somethings about the contract which I mentioned below:

• The contract was not well documented so I added more comments to it.
• I also optimized the contract and removed redundant codes.
• I noted a bug where you were trying to transfer the NFT from one user to another. Please note that this can't be possible unless the account transferring the NFT sign the transaction. To overcome this, I added an "approve()" function to allow the smart contract transfer the NFT from one user to another.
• Another thing about your contract is that you have some functions whole functionalities are not clear/distinct. For example "buyItem()" and "buyListedItem()" functions. I would recommend you try to make your functions as distinct and descriptive as possible. Thanks

Wow. Really great submission here. I went through your contract and I loved what you built here. I tested it and I couldn't find any problems with it, just except some optimizations. In case you are looking for a teammate to bring this project to live, please ping me up and I will be willing to contribute to bring this project to live.

Changes made

• Formatted code to make it more readable
• Fixed typos in code
• Added require statements to first confirm the length of each characters before using them in constructor

Recommendations

• Player and boss HP should be more randomized instead of user inputting them at deployment. You can utilize Chainlink to get more secured randomized numbers.

Observation

• Comments are too long. May consume more gas during deployment.

Hi @Kishore, thanks for a great submission you have here. I went through your code base and I couldn't find any bugs in your contract (though the Test Minter site you added in the README was not working on my Chrome browser on Windows 10 PC, I will still try out other browsers though. I had to use my own deployed NFT contract to test your project).

Below are improvements I made to the contract:

• I used the Counters library for increasing the loanId to further optimize your contract.
• I replaced the hardcode time in your contract to the native solidity time variable (changed 60 to 1 minutes).
• I formatted the code with Juan Blanco solidity extension in vscode to make more developers understand the codebase better.

Below are my recommendations for this project:

• You can use a feature like Chainlink keeper to trigger the process of transferring the nft back to the owner from the contract in functions like ceaseNFT and closeBorrowRequest, as opposed to the user coming to manually withdraw the nft from the contract.
• Users should be able to pay for the loan partly to gain more time incase they don't have the full amount to pay at once. Thanks for the awesome project. I really enjoyed and learnt from reviewing your project.

You have a great submission here JoeEdoh. I went through your contract, reviewed it, and tested all of it's functionalities. It was well written and the functionalities was well working as expected, except for some minor issues I fixed and added in my pull request. Below is a summary of the issues I found in the contract:

Updates

• Fixed a bug that prevented operator from paying out lottery winners. I discovered it was because you didn't changed the state of the lottery from ACTIVE to PAYOUT after getting the lottery winner.
• Fixed another issue that allows people to still buy lottery ticket even after the lottery time has ended. I fixed this by first checking the current state of the lottery before every purchase.
• Another issue I found is that ticket ID does not match with token ID, i.e, when token ID is at 1, ticket ID will be at 0. I fixed this by incrementing the token ID at construction time to match with ticket ID.
• Added a new function that let's users first check for the price per ticket to know if they have enough funds before proceeding to purchase the ticket.
• Added more functionalities to allow the operator check the total left funds in contract, and also withdraw the funds to their wallet address.
• Added more comments to contract and optimized the contract as well by removing redundant variables.

That is all the issues I found in your contract. Otherwise, your contract is great!

Hello Samueladams, great submission here. I really learnt a lot from studying your contract alone. I tested your contract as well and it was working perfectly except with a very subtle error which I highlighted in my pull request. Otherwise, you have a great contract here.

Here are the few updates I made:

• Added a modifier that first checks if an auction exists before querying to that auction. Without this modifier, when a user enters an auction id that does not exist, the contract might behave unexpectedly. I then added the modifier to all the functions querying for "auctions" array. This is the subtle error I mentioned earlier in my feedback.
• Added more comments to the contract
• Fixed typos in contract

My recommendation for the contract is that you make it more easier for users to enter an auction values when creating an auction, because not everyone will be able to properly enter a tuple from the remix IDE. Thanks

You have a very wonderful contract here Lilian. I just reviewed your contract I can see a lot is happening in the contract. I tested the contract and it was working fine without problems. Here is my feedback about your contract:

Updates

• Added a modifier to first confirm if a token exists before using it's id to pick random word from array.
• Updated contract names to follow solidity style guide. You can check out the solidity documentation at docs.soliditylang.org for more on style guide.
• Added more comments to make code more readable
• Added more log statements title to allow user properly understand the log output

Recommendations

• Comments should be short and more descriptive.
• It takes a lot of time to deploy and mint a new token, and also consume a lot of gas in the process. I suggest you optimize your code to make it more faster consuming less gas.
• Your code was not properly formatted. I didn't help you format it because I want my changes to be clear. But you can use the linter extension in vscode to properly format your code to increase readability.

Thanks