Grants Process
NOTE: This is a working draft. All the ideas presented below are just that - ideas. We encourage everyone to submit their own ideas and start discussions around what can be done to improve the Grants Process within Ethereum.
Summary
This document was sparked by a recent Twitter thread where members of the Ethereum community came together to create a document aimed at disscussing ideas for new methods and processes that the Ethereum Foundation and it's community can work on to make the Grants process the best it can be for its recipients.
The Discussion
Main variables to consider prior to giving the grant
- Firstly, work should already be in progress.
- Is the project working towards an achievable goal?
- The team is recommended to have experience delivering ETH/DLT solutions
- Teams that are potential recipients of a grant should have a brief initial chat with EF to getting to know them, how they work and what their goals are. There needs to be due diligence to some degree. This also may not be necessary if a project with already completed work can be reviewed publicly.
- The Community (developer community) should be updated with their progress and kept engaged with learning material etc..
What can the Ethereum Foundation do to make the grants process better?
- The project’s work should have already begun and the project should disclose what the grant will be used for.
- Grants should not pay for planning rather for execution. Once the applicant receives a Notice of Grant and the funds have been disbursed, they will continue to work on the project.
- Visibility into grant decisions and why certain amounts are given
- From a grantee perspective, when receiving a grant of certain amounts it would be nice to know why this particular amount was granted. It would be helpful for the grant provider to explain WHY the grant was awarded and WHY such an amount.
- It would also be good to clarify what is expected from the specific grant amount. Also, it would be nice to know what the projects have to do in order to potentially receive a follow-up grant etc..
- Implement Checkpoints / Demos
- The grant recipients are responsible for meeting with the foundation grant team for financial reporting requirements and development updates.
- Disclosure of funds spent
- A timeline of use-of-funds should be announced prior to receiving the capital. For example, 2 full-time devs and 2 part-time, 40 hours a week and 20 hours a week respectively.
- Financial reporting includes:
- How much was spent each month and what it was for
- For personal privacy/security, there is no need to disclose how much each person received.
- An idea of what the rest of the funds will be used for
- Support/Guidance
- For funds usage and potential advisory: tips/advice on how to use their grants, such as if they should cash out / convert to Dai in order to cover their operations for X amount of time.
Some ideas/options include:
i. Multi-Sig where the grant funds are held in Dai/Eth
- This gives a transparent view of the distribution of funds given out on a monthly basis and to fund consumption progress. Perhaps one funding schedule announced by the team, they then give them funds? Clear usage of funds/transparency.
- The multi-signature wallet requirement ensures redundancy and prevention from accidental loss or theft of funds.
ii. The grants process doesn't need to enforce an ideal situation because if a project is working on DLT tech you should be trying to #hodl crypto and pay your workers in tokens. If the EF transfers USD to a foreign account, the banks are going to take a fat ~5% FX fee/premium. If you're not running on USD and you don't want to hold ETH, the team may find it best to take the ETH and sell it at a local exchange (jurisdiction /legal dependent).
- For example, DAI is, of course, a solution to the volatility issue, but if you're not in the US you're going to struggle to liquidate it to local currency, plus you're taking a position on USD compared to your local labor.
iii. As a grant giver, you may need the developer community or foundation to help out. It is what the project needs - some are self-sufficient and require very little involvement but others may need some hand-holding and need an army of internal/external resources.
iv. Mentoring from the funding foundation to help guide the grantee. This would include reporting to the funding foundation on a scheduled basis. Where the mentor can chat with the team about the overall financial status and project performance of the grant project.
- Product market fit (PMF) - This section is optional/dependant on the project origins
- Implement regular PMF analysis and identify whether the portfolio company will survive in the long run and then assist them in refining their PMF (if it is not too late). This section is optional/dependant on the project because some grants aren't concerned with market fit. For example, many documentation or research projects aren't going to be valuable in any market.
- Encourage inter-grantees company partnerships and synergies
- When a company gets a grant from a foundation, they agree to work together and it should be a win-win partnership.
- Closeout requirements
- This process includes a review of the final financial and technical progress from the grantee, the grant lifecycle end. The project is then considered for a follow-up grant or the grant process closes.