Sharing some work ive done to start preparing for the DAO gov UI build. started with the biggest unknown (for me), which is the entire solidity + front end process for building + submitting proposals. a brief review of what I’ve learned so far:
solidity stuff
- the relevant solidity is held in the Governor.sol base impl. when we are submitting proposals, it will be too the Governor.sol proxy that is deployed for ur DAO (here’s the 0x2C376E79B2B3d342Ff32eFD0446C02e8682044E1 for PA)
- all of the solidity is imp but in particular interest to us is the “propose” function which is what you call to submit a proposal. it takes in the following inputs:
— array of addresses you will be calling (since u can submit multiple txns in one prop)
— array of uint256 eth value for each txn
— array of calldata for each txn (THIS IS THE HARD PART)
— string of prop description
front end stuff
- the hardpart of doing this is generating the calldata for each transaction that will be a part of your proposal. calldata is the most efficient way to post function data to the blockchain, but you have to do some work in this instance to create the calldata first in the front end so you can pass it correctly into the “propose” function
- to do this well be using ethers contract.interface.encodeFunctionData, which creates calldata out of function names + function inputs. see screenshot below for example, and here’s the link to the ethers docs
other thoughts
- besides getting really comfortable with generating function calldata (learning how this works will set us up to learn how to write in assembly
), most of the other problems well have to solve will be how to create the simplest + modular impelemntations of front end building blocks for interacting with each part of the gov process + contracts (auctions, dao settings, proposal generation, proposal voting, etc)