FINAL PROJECT REQUIREMENTS

Each student will participate in a team (of 3-4 students each) which will propose, and deliver, a smart contract-based Daap or DAO of their choice in the form of one or more cooperating smart contracts onto Ethereum (Testnet only).  It is intended for teams to have significant latitude in defining their Daap/DAO project.  This flexibility is evidenced in team self-selection and formation as well as in the use case selection for their Daap/DAO as well as in the specific requirements of the project as delineated by their chosen use case.  Use cases can come from a variety of verticals; for example (Note:  this list is only intended to be illustrative of breadth of problem space), a team may choose to focus on building a simple token exchange, or focus on provenance and authenticity, or they may focus on identity verification or ownership verification.  Other possibilities include an NFT-based art brokerage, decentralized prediction markets, regulatory auditing, crowdfunding, auctions, and yes, games and gambling.  Teams are of course welcome and expected to come up their own "take" on the problem space they would like to tackle.

Best practices should be employed in your deliverables and a good starting point is here: 
Index - Ethereum Smart Contract Best Practices (consensys.github.io)

Periodic Requirements:

1.  Team Self-Selection & Formation (July 3, 2023)
2.  Team Project Proposal (July 24, 2023)
2.  Team Project Check-Ins with Faculty (2) and proposal updates (To be scheduled weeks of July 17th, 2023 & July 31st, 2023)
3.  Final Team project code delivery and deployment (Thursday, August 17th, 2023)
4.  Final Team project presentation to class and post-mortem (August 14, 2023)

Project Proposal Requirements:

Project proposal drafts should be detailed in terms of:

* Use Case:  Describe the general use case and what your team is going to do and an overview of the solution.

* Approach (Design Approach with Diagram(s)):  What will your deployed project look like in terms of contracts and capabilities? [Feel free to leverage UML in your diagrams]

* Tools:  What tools (Solidity, Remix, VS Code, Oracalize, truffle, ganache, etc.) do you anticipate needing and leveraging?

* Anticipated Complexities and Mitigation Plans:  This stuff isn't easy.  What "gotchas" do you feel you may encounter?  What backup plans (tools, approach, etc.) do you have in case of trouble?

NOTE:  You may (and will) revise your proposal throughout the course even after initial submission.

Specific Project Requirements:

A "front end" is optional.  Teams are free to submit their Daap driveable solely through a defined API, and, at their sole discretion, may include a front end (HTML, Node.js, Web3, Angular, etc.).  Teams that choose to add a user-friendly (does not have to be beautiful!!!) front-end may be more impressive than just an API-based solution.  HOWEVER, AND HEAR THIS, NO AMOUNT OF FRONT END RAZZMATAZZ WILL MAKE UP FOR A FUNDAMENTAL LACK OF CAPABILITY IN THE SMART CONTRACT(S).  IT IS ABOUT THE SMART CONTRACT FUNCTIONALITY, NOT THE FRONT-END BELLS AND WHISTLES.  A very simple field-based front end is all that you should focus on, if you even decide to add one at all.  Remember, there is no requirement for a front end, and you will not be downgraded for not supplying one.  The very last thing you want is to deliver a beautiful user experience and have your Dapp's contract(s) basically not work.  Tactics might dictate getting the contract(s) working first with tests and APIs, and then, if you have time and are so incined, throw together a front end.

Project code for smart contracts must be written in the Solidity programming language.  Other languages may be used for additional project support (python, JavaScript, etc.).

All projects must include copious tests (Mocha, e.g.) that ensure fundamental functionality, and all tests must run successfully.

A token (coin) must be integrated (you may utilize any standard ERC token specification)

Projects should be be delivered onto the Sepolia Testnet for final delivery, testing and grading, although final deployment onto Ganache is acceptable.

Projects may access external data through the form of oracle frameworks, off-chain data, etc.

Projects may utilize decentralized storage options such as Swarm or IPFS.

Projects may utilize ENS (the Ethereum Name Service) at their discretion.

Projects may utilize Whisper messaging at their discretion.

Projects may utilize Docker containers in any way that might help facilitate delivery of capabilities

Projects must have some form of security awareness built in (e.g., onlyOwnable, etc. modifiers, requires() protections, gas limits, data privacy, etc.).  That said, we do not expect a faultless contract (e.g., if you need a source of randomness, you will not be penalized if your source of entropy is in a state of von Neumann sin or lacks Markovian randomness, or your contract makes potentially-compromising external calls).  [Note::  help can be found at https://consensys.github.io/smart-contract-best-practices/.  You may wish to employ a linter.]

Projects must emit and handle events.

Libraries may be used (e.g. SafeMath, OpenZeppelin, etc.)