Step 2: Impact Estimate Post

Once a project is posted to the protocol, anyone can create an Impact Estimate for the project. The Impact Estimate initiates the validation process for the project.

Just like the project itself, the Impact Estimate too is a public good, since it provides the ecosystem with a validated impact estimate of a public good. The value of the Impact Estimate is proportional to the value of the project itself — yet the effort it may take to estimate a project varies based on the complexity of the review, access to credible data, difficulty to accurately determine economic impact, and so on. Each project also requires a certain amount of expertise to review; while higher impact projects require an overall greater amount of expertise, since a certain baseline of expertise is required even for a project with minimal impact, the amount of expertise required increases at a decreasing rate — thus making higher impact projects more profitable to Estimators.

In the Impact Estimate post the Estimator specifies the following information:

  1. Project’s on-chain hash.

  2. Timestamp of impact estimate post.

  3. Overall estimated economic impact score of the project.

  4. Project credibility score.

  5. Categories that are most relevant to the project, and the relative importance of the category to the project.

  6. Urgency of validation.

  7. Validation effort level.

  8. Comments

Based on the information provided in the post, the protocol calculates the validation fee that the Estimator will be required to submit to initiate the validation process (this fee only needs to be paid once an Estimate post clears the waiting list and validation can proceed).

Not all of the information above is required to successfully submit the Estimate post, but the more information provided the less effort is required from validators to do their task — which means that the Estimator can pay a smaller validation fee (and end up receiving a greater portion of the Impact Estimate value). Estimators therefore have the incentive to look for high impact projects (such projects should also have lots of credible data and low effort to validate), and provide as much information as possible in the Impact Estimate post.

The required fields include: project’s on-chain transaction hash, timestamp of impact estimate post (automatically generated by the contract), overall estimated economic impact score of the project (with supporting sources), relevant categories and relative importance, estimation difficulty, and validation effort — these fields are sufficient for the protocol to calculate the amount of expertise required for validation and associated validation fee required.

2.1. Project Hash

The project’s on-chain hash is the content identifier for the project from decentralized storage. The hash maps to the Project Post on-chain. This hash is required information in the Impact Estimate post.

2.2. Timestamp

The Impact Estimate post timestamp is generated by the protocol once the post is successfully submitted.

2.3. Estimated Impact Score

The overall estimated economic impact score is required for the Estimate post, and allows the protocol to calculate the expertise necessary to validate the estimate, and is part of the associated validation fee. Projects with higher estimates require more expertise to validate (although expertise increases at a decreasing rate for higher estimates). The impact score should cite sources to back up the estimate (not required but reduces the effort of validators).

2.4. Credibility Score

We propose two tiers of validation: in the first tier, validators with expertise in a subject matter are asked to assess both the credibility and the relative impact of the public good on their field. In the second tier, validators from across the ecosystem determine the overall impact of the project based on the credibility and impact input from domain-specific validators. Estimators are not required to provide a Credibility Score for the project, but such score helps validators in their review process.

2.5. Project Categories

To review the credibility of a project, Validators need to be selected based on their expertise in the domain (or domains) of knowledge relevant to the project. The Estimator needs to specify the relative impact of the project within relevant categories so that sufficient expertise can be deployed to review the project. The estimated relative impact of a project in all its relevant categories sums up to the estimated overall impact of the project on the economy.

The data for Project Categories should include the hash identifying the category, the relative impact score in the category, and a brief summary justifying the decision (the latter is optional). Project Categories are a required field that helps the protocol assign validators to the estimate.

2.6. Validation Urgency

While the validation process should run its course to achieve reliable and accurate results, at times it may be necessary to accelerate the initial credibility score portion of the review. For urgent credibility reviews validators will receive a greater compensation to move the estimate up in the waiting list.

The Validation Urgency is assumed to be not urgent unless otherwise specified. Specifying the Estimate post as urgent would only accelerate the initial credibility score of the post, while the other sections will be validated at the same rate as any other post. Therefore, this option should only be selected if a credibility score needs to be obtained quickly. This option may be useful for a decentralized news service, for example, as an early credibility score may be necessary for such service to be useful.

2.7. Validation Effort Level

Projects with the same expected impact may require a different amount of effort from validators — either due to the complexity of the project or other factors. Yet, more required effort does not necessarily mean that the compensation level for validators will be higher (as compensation is tied to impact and not to effort). Since validators will prefer to review projects that require less effort than those that require more effort, this would motivate contributors to produce more straightforward content. Similarly, Estimators may share a greater portion of their expected return with validators to advance their position in the waiting list. Finally, developers will have the incentive to develop tools to simplify and speed up the validation process.

Validation effort level is a required field, and helps Validators determine whether they want to review a project.

2.8. Comments

The comments field allows the Estimator to provide any additional information or context for the project. This field may be especially useful for projects that are difficult to estimate (based on limited data, uncertainty, ineffective estimation tools, and so on). If a project estimate has a high level of difficulty it carries with it an economic and reputational risk for the Estimator, for validators, and for the ecosystem more broadly (the risk that such projects would hurt the currency as an effective store of value). It is therefore preferable for the Estimator to choose a lower impact estimate that she can justify with a higher degree of confidence, and flag the project as requiring another round of estimation at a later time (when more data is available or better estimation tools are developed, for example). By doing so, the public goods contributor can still receive some compensation while everyone else (Estimator, validators, and the ecosystem as a whole) would benefit from reviewing lower risk estimates.

Estimators are not required to fill out the comments field, but it may be beneficial to flag if a project may require a future estimate.

Last updated