Fundamental Report Workflow
The following is a detailed breakdown of the workflow of a high quality Rater.
Last updated
The following is a detailed breakdown of the workflow of a high quality Rater.
Last updated
Follow the process for Creating & Submitting Reports to find a protocol and accurately create the document for your report. This is critical for successful submission, once your report has been finalized.
Before you start reviewing, familiarize yourself with the project by using it and collecting written content you can find on the internet.
Create a list of all sources to explore when looking for details about the protocol. This can include Medium articles, social media posts, Discord communities (where you can reach out to people) and maybe even your social network.
You can find a summary of sources to review here:
After you have the list, start populating the report.
The value proposition evaluates the unique selling point or in other words, the actual value the protocols brings to its users.
Was the project the first ever to provide this service?
Did it improve on others?
Is it a fork with little innovation?
It can be helpful to understand their history. This can be found by looking at their website and medium. The first 3 articles can often prove exceptionally helpful. Additionally, pre-existing reviews and analyses from official sources can be used to find patterns. What information do you find repeatedly?
The competitive moat is measured by directly comparing the protocol with its competition (using credible analytics tools such as Dune or Tokenterminal) and is broken down into the following categories.
Value Proposition
How relevant is the product, does it solve a big pain point for its users?
How innovative is the product (did it introduce novel solutions or just a fork)?
Look at the protocol's history, why was there a need to create the product, does it solve the problem it was built for?
Another way to think about this: What would change, if the protocol didn't exist (how relevant is it for DeFi)?
Market fit/demand:
Use relevant performance indicators depending on the type of protocol
Fees are always a good indicator (means users are willing to pay for the service)
For lending protocols: Amount of outstanding loans, TVL, number of user, interest fee, etc.
For DEXes: Trading volume, TVL, number of user, etc.
For Yield Aggregators: TVL, number of user, number of pools/integrations, etc.
Target market size:
What is the current and future size of the problem the protocol is aiming to solve?
Use estimates comparing to TradFi market
Competitiveness within
market sector(s):
Compare market share using the same KPI's as in "market fit/demand question" (e.g. market share of trading volume, TVL, etc.)
Is the protocol positioned as clear market leader, as strong 2nd/3rd competitor, somewhere in the middle, or not able to compete with the rest?
Integrations and partnerships:
How important of a money lego is the protocol (measured by # of horizontal integrations, i.e. other projects building on top of it)?
Check if they have exclusive partnerships
Are the partnerships & integrations relevant and for the betterment of the protocol?
It’s important to not confuse exclusive partnerships with partnerships with the protocol simply using their services. The further down the stack, the harder it is to be forked.
As the name suggests, the tokeneconomics section evaluates the token design and its use cases. A first important indicator of healthy tokeneconomics is the actual distribution of the token (genesis and right now), as well as the distribution mechanisms.
How is it going to be distributed going forward?
Does that align all stakeholders?
Is there a buyback protocol?
Who are the addresses in Etherscan? Is it a treasury that belongs to the protocol?
Their documents should contain if there are fees, and issuance and distribution are often mentioned in the title of news articles. If you run into difficulties, scanning the community forum or doing interviews in the community can help you find the information you need.
Lastly, this section reviews what the purpose of the token is, what can it be used for and if it accrues any value for the token holder (revenue or governance rights).
Evaluating the team is another important piece of the puzzle as it gives us an indication for what can be expected. Is the team well experienced, i.e. did one or several team members already successfully found or lead a company, start-up, or other web3 protocol.
One important aspect of this section is to evaluate whether the team was capable of attracting the right resources, e.g. team members, infrastructure or funds. Being able to attract large and well-known VC's for example can be a promising sign (though the absence of funding is not necessarily negative).
How capable is the team?
What is the team’s experience?
Follow teammates on Twitter or other
Anonymous founders are ok but are there public-facing members?
Governance is an important part of DeFi and hence part of this report. The goal of this section is to find out how robust the governance system the protocol has in place actually is, and whether they serve all stakeholders (e.g. community) or just a few (e.g. developer team).
Hence, this section looks at the process and technology that enable governance. In addition, providing transparency about who holds the keys (smart contract admin keys) is another important piece of the puzzle that needs to be analyzed in this section.
Are the smart contract admin keys easily accessible? Through a google search or on discord?
What does the voting history look like on snapshot
Who is voting on proposals?
How does the governance compare to others?
Is there a clear step-by-step process to how governance works?
The regulatory section is the smallest paragraph in terms of questions and cannot always be answered (e.g. if the DAO is fully decentralized without a legal entity). However, for all protocols that have a legal entity, the Rater is required to find out what the legal accountability looks like and in which jurisdiction the company is located at.
The Regulatory section describes the extent and quality of the regulatory environment that affects the Protocol. To be able to guarantee functionality, security, and legality the protocol should comply with regulatory requirements, or limit itself to facilitating services to users who are willing to operate outside of the traditional regulatory environment.
Does the protocol have legal accountability?
Does the protocol have any form of legal accountability?
Can users and partners hold the protocol accountable in case of a breach of the agreement? What is the quality of the legal jurisdiction?
Are their protections in place for investors?
If the protocol has a legal entity, what is the quality of the jurisdiction the entity is established in? Will the jurisdiction be able to facilitate the legal framework for the protocol to expand while remaining accountable?
Once you feel you have addressed all section of the review to a sufficient degree, submit the report in the 🔎│report-feedback in discord.
A reviewer will pick up on your report and give your feedback.
After you have integrated the feedback of the reviewer you can submit the report using this typeform.
Please also announce your submission in the ⤴│submit-report Discord Channel to make Governor aware of your submission.