Add new challenge: Onchain Proposals

[escottalexander]

Setup

The setup is like this; eth-tech-tree is a CLI for downloading, submitting and managing which challenges a user has completed. The repo that houses all the challenges is called eth-tech-tree-challenges. Each challenge is a new branch on that repo.

The challenges are Scaffold-ETH2 Extensions so you should be familiar with the process of creating extensions. It will also be helpful to reference an existing extension branch such as the Token Voting challenge. You might even want to copy all the files from that and modify as needed.

Here are the steps for adding a new challenge:

• Create a reference contract that fulfills the requirements you have in mind for the challenge
• Write tests that cover all the primary functionality of the contract
  • Try to make the testing as generic as possible, using as few methods as possible from the challenge contract (This will make it so the challenger will have fewer "required" methods and can fulfill the requirements in their own way as much as possible)
  • Don't write any tests that check for event emits (vm.expectEmit()). We cannot guarantee that a user will write these exactly as we intend because of the indexed attribute
  • Make note of all the references to the main contract. Anywhere where you are using contract.method(...). You will need to tell the user exactly what these methods are expecting and returning in the README.
• Add a contract to a directory located here: packages/foundry/extra/ with the same name as your contract except with an "I" preceeding the name (e.g. IVoting.sol), fill out this contract with all the expected methods that the test relies on. This is for the testing server to use as a placeholder. The test should be able to compile and run (with falures) when you use this contract as the challenge contract. The important thing is that it can compile.
• Fill out the README with all the required methods and make sure you tell the user exactly how you want the contract to act. Does it need to revert when it receives the wrong data? Tell them it needs to in the README. Does a method return a uint? Tell them! You want to be very clear about what your tests need but you also want them to be able to make design choices themselves. It is part of the challenge.
• Make sure you add some backstory for flair and a good explainer on why someone would want to create a contract that does what the challenge suggests
• Now remove your contract code except for

    //SPDX-License-Identifier: MIT
    pragma solidity ^0.8.19;

    import { console2 } from "../lib/forge-std/src/console2.sol";

    // Good luck!

• Using the create-eth extension system test the whole process of setting up an extension and solving the contract. See if you hit any unexpected bugs.
• Push your changes to GitHub and open a PR to the onchain-proposals-extension branch. If the branch doesn't exist, ping @escottalexander
• There will be an extensive review process to guarantee the tests are flexible enough to handle lots of differing solutions.

Challenge Details

Onchain Proposals challenge specifics
This challenge will require users to implement the Compound Governance contract structure and functionality by creating two separate contracts;

ERC20 Token whose supply and distribution can be changed by a proposal
Governance contract (manages voting state and proposal execution)
This challenge shouldn't encapsulate everything the Compound contracts can do, only the main mechanism of having onchain proposals that can affect the token supply (and distribution to specific accounts) should be implemented.

Anyone can create a contract and send 100 of the tokens (or whatever amount you choose) to their proposal contract (this is a requirement of a proposal contract). The proposal contract address is then submitted to the governance contract. Holders of the token then vote based on a timeline (hardcoded 1 week from proposal submission is fine). If the majority votes "for" the proposal then after the deadline the main governance contract can call the proposal contract which should affect the ERC20 supply and/or distribution - whatever the proposal contract enacts.

Feel free to ask any questions or express any ideas that will help the end user learn through this challenge.