# POB HASH Historians - Claim Verification Protocol
*NOTE: Please leave comments on provisions where you suggest changes or improvements.*

## Choosing Historians
Dave and team will select the Historians from among the applicants in HCIP2 on GitHub.

## Setting the Scope
Simplicity is best, so we should aim for a minimal design that serves the community's interest in having verified claims, yet still allowing owners to do what they want with their HASHes.

Two initial question about the scope of the Historian's work should be addressed before we begin.

#### Question 1 - Whether to Issue Warnings
Should Historians be limited to making verifications or should they also have the power to issue warnings in the metadata about potentially misleading claims wthout the owner submitting the claim for verification?

If we think unsophisticated buyers will not understand the verification system and credit whatever the title says, I think we should consider adding a warning mechanism that would append "[DISPUTED CLAIM]" or something similar to the title of the piece on OpenSea and secondary markets.

If we believe the vast majority of buyers are aware of the verification system and know how to protect themselves, warnings aren't needed.

NOTE: This document does not include proposed Warning procedures.

#### Question 2 - Whether to Narrowly Limit the Scope of the Verification
If an annotation submitted by an owner contains accurate historical claims (e.g. "XYZ token creation TX") but also unverifiable statements with poetic license (e.g. "launching a new era that will end the world's problems"), should we verify the annotation?

If so, should we consider delineating specifically what claims within an annotation have been verified? Should we consider making formatting edits that emphasize the verified claims like:
> ***XYZ token creation TX***, launching a new era that will end the world's problems

Or should we leave the annotation alone, but create a separate piece of metadata for claims verified by the historians. An annotation would then look something like this on OpenSea:

> Verified Claim: XYZ token creation TX
>
> Created by hasher1
>
> XYZ token creation TX, launching a new era that will end the world's problems
>
>
> TX HASH: 0x123456...
>
> NO: 1234
>
> WRITER: 0xabc...

NORE: This document does not include procedures for separating precise claims for verification.

## Claim Verification Guidelines
1. CLEAR SCOPE - We should specify and communicate the types of claims that can be verified. Annotations submitted by HASH owners may contain claims that cannot be objectively verified (for example: "most sophisticated hack" or "creating a new era in DeFi").
2. ACCOUNTABILITY - Each Historian should be willing to publicly back each verification and non-verification decision and put their own reputation on the line. Errors should be promptly acknowledged and corrected.
3. PRECAUTIONARY PRINCIPLE - We should default to not verifying claims because the reputational harm of a false verification vastly outweighs the failure to verify a correct claim, which can be remedied. Any Historian uncomfortable with a verification call should have veto power in this early stage.
4. SUPER HIGH CONFIDENCE - Only verify annotations where where we have nearly perfect confidence that every verifiable claim in it is correct.
5. PRECISION - Claims must be sufficiently particular in order to be verified, especially claims made in titles. For instance, the title "Project XYZ Genesis" is not specific enough, because it could refer to several transactions, including but not limited to:
* The deployment of the project's ERC20 token contract
* The deployment of the project's main logic contract
* The deployment of the project's first contract, even if it is just a helper library
* The first minting of XYZ tokens
* The first interaction with the token or logic contract
6. ASSUME BUYERS ONLY READ THE TITLE - We should not permit sufficiently clear descriptions to cure otherwise imprecise titles, because we have to assume buyers may rely on the title alone for verified claims.

## Submitting Claims for Verification
HASH owners would use the same "Edit" function on the UI to write the Title and Description.

I propose adding a new field for "Supporting URL" below Description to allow owners to paste in a link to a tweet or article that supports their claims. It should have "+" option to add up to three supporting links.

Above the "SAVE METADATA" button, owners would be able to check a box to "Submit For Verification." There should be a tooltip here linking to resources about how verification works and how claims should be worded.

## Historian Workspaces and Channels
I propose the creation of a new private Discord channel called ``#historians-only`` where the Historians and core team have access.

The existing ``#historians`` channel would remain public and would serve as a forum for discussions about how HASHes are verified and what improvements to the process can be made.

I propose that the Historians be given a separate role in the Discord with the suffix "HASH Historian" after their handles so that the community knows who is doing the verification and can hold them accountable.

The Historians should have a shared workspace to collaborate on verifications. It could be as simple as a shared Google Sheet, but should be easy for both Historians to edit and for the community to be able to see how the decisions get made.

## Verification Process
When a HASH owner submits a claim for historical verification, a bot should notify the ``#historians-only`` channel of the submission and the claims text should be pushed to the relevant working document.

New claims should also automatically be assigned to a primary Historian, and a push notification sent to that person via Discord DM/email/TG (method chosen by the Historian).

#### Initial Investigation
Primary historians have a duty to conduct an initial investigation of a submitted claim and render an initial verdict on his/her findings in the shared doc within 48 hours. Historians should also notify their peers when they plan to be AFK for more than 48 hours.

The initial investigation should involve:
* closely reviewing the HASH's Etherscan TX record;
* examining the sender and recipient EOAs and the contract called;
* conducting a web search on the subject of the claim to determine whether any contemporaneous sources support the claim;
* for contract calls, examining the Input Data field and following any leads found there;
* for claims related to time sequencing ("first X event"), closely examine the history of the EOA or contract; and/or
* conducting whatever other research is appropriate to verify the claim.

#### Initial Verdict
The primary Historian's initial verdict should be one of the following:
* Verify - sufficient evidence supports at least one historically verifiable claim
* Unverifiable - no objectively verifiable claims made or sufficient evidence to verify is lacking
* Reject - evidence suggests the claim is inaccurate
* TBD - primary Historian is not comfortable making an initial verdict and would like to discuss the claim with other Historians

#### Reasoning
The primary Historian should include his or her reasoning for the initial verdict and what sources he or she relied on.

#### Supporting Links
The primary Historian should include relevant links that support the initial verdict.

#### Other Notes
The primary Historian should use this field to include any remaining questions he or she has or otherwise flag an issue for the other Historians.

## Verification Decision
After an Initial verdict is rendered, the other Historians should review it and the supporting materials. Each non-primary Historian would then mark the "Historian [NAME] Approval" column for the claim with a "Y", "N" or "?" to signal their approval, rejection or need for further discussion, respectively.

Claims with a "Verify" Initial Verdict that have received "Y"s from all the other Historians are then considered ready for Verification.

## Effecting Verifications
On a preset schedule - possibly twice a week to start - a transaction would be sent updating the metadata if there are any claims ready for verification.

A Discord bot would send a notification to the ``#historians`` channel when any claims have been verified, identifying them and quoting the annotation.