The Historians DAO is comprised of volunteer researchers interested in helping tell the story of Ethereum through POB's HASH project. As a refresher, each HASH is minted from a unique Ethereum transaction hash, meaning that a HASH is an artistic representation of a particular occurrence on the Ethereum blockchain. The POB UI allows HASH owners to submit titles and descriptions describing the significance of the HASH's underlying transaction, and then to request that these annotations be verified through this Verdict Form.

The HASH Historians Process

The work of the HASH Historians is to review owner annotations, research the claims therein and write Verdict summaries describing our findings. At the conclusion of our research, we assign each HASH annotation a Verdict of either Verified or Disputed. Once three Historians have upvoted a Verified or Disputed Verdict, it may be submitted on-chain by anyone.

So to break that into pieces, here are the distinct steps:

1. Owner mints a HASH from a unique Ethereum transaction
2. Owner adds a title and description for the HASH and submits it on-chain
3. Owner requests a verdict on the HASH annotation through the Verdict Form
4. A Historian researches the annotation's claims and renders either a Verified or Disputed verdict and makes a written summary of their findings
5. Other Historians review the Verdict and upvote it if they agree that it is supported by the evidence
6. Once three Historians have upvoted a Verdict, it may be submitted on-chain

HASHes with on-chain Verdicts show either a ✅ for Verified or ❌ for Disputed appended to the beginning of the HASH title on OpenSea (though refreshing metadata may be required).

Tips for Getting your HASH Annotation Verified

To get your HASH annotation verified, you should follow strive to be accurate, be clear and be helpful.

The most important aspect of writing verifiable HASH annotations is accuracy. You should know what happened as a result of the underlying transaction and should be able to describe it in layman's terms. Sometimes this requires you to know how a particular contract's functions work. Be sure to check out the transaction's fields on a block explorer like Etherscan, including Input Data - this where the function name and inputs can be found. If you'd like help understanding a transaction before writing an annotation, jump into the Historians' #general channel in the POB Discord and we'd be happy to help. It's also fine to choose "Save + Submit Later" for an annotation if you want to avoid the possibility of having to change it later with another on-chain transaction.

Next, use clear, concise and unambiguous language when writing your annotation, especially in the title. Remember that we are engaged in a cooperative history-writing effort and that the intended audience for our product will care more about clarity than cleverness. Use active voice, avoid run-on sentences and identify all the relevant parties. Puns, shade and grammatical memes shouldn't ever add potential confusion, and those that don't affect clarity are probably better to include in the description rather than the title.

Finally, show your work! Provide helpful context and links to supporting evidence that make your claims easy to verify and illuminating to the reader. Context is crucial for claims that involve some off-chain fact and you should be sure to understand which factual claims you are making. The claim "Mark Cuban buys 1,000 Project X tokens" contains two distinct claims about a transaction: 1) it is a swap or transfer of 1,000 Project X tokens into wallet Y and 2) wallet Y is controlled by Mark Cuban. The first claim is verifiable on-chain but the second requires some extrinsic evidence - in this example a tweet from Mark Cuban claiming wallet Y is his address would suffice. You almost certainly know more about the context of your HASH than the Historians do - please leave us breadcrumbs.

Common Sources of Off-chain Evidence

When providing context for your HASH annotation, consider including:

• Tweets from the relevant person or team
• News articles (cryptonative media sources are often better than legacy)
• Blog posts from the team (Mirror, Medium, Project official site, etc.)
• Technical hack/exploit debriefs by security experts (rekt.news is a good source)
• Link to the official project site

Five Common Mistakes to Avoid

#1 - Omitting a Title

We sometimes see HASH annotations that only have content in the description field and leave the title blank. Make sure you have a title! Because only the title appears on the secondary sales platform OpenSea, we require that to be able to verify a claim. You can omit a description if you like as long as the title is clear.

#2 - Making Unverifiable Claims

Sometimes an annotation doesn't give us enough factual material to be able to verify or dispute.

Be sure that your claims about a HASH are verifiable by the Historians. Make sure there is at least one factual and falsifiable claim in the annotation, and that it describes the substance of the underlying transaction.

Avoid using language that is inherently subjective (e.g. "craziest sale"), vague, unsourced (unattributed quotes) or where it's not clear who the relevant parties or projects are.

#3 - Misusing “Genesis” or “Creation”

The word "genesis" has a special meaning when it comes to crypto history - the first block of the Bitcoin and Ethereum blockchains are known as the genesis block, as they initiated the state of the ledger. Before genesis, there was nothing, and after, there was something.

We will verify a "genesis" claim for a transaction that either:

1. Created an ERC20 token; or
2. Created a contract that contains all of the project's cryptoeconomic logic.

This second category applies to NFT contracts that contain the total supply, the issuance and ownership logic, the metadata storage information and the transfer logic. Most ERC-721 compliant contracts will qualify.

This restrictive definition means that for certain projects with interdependent contracts (i.e., most DeFi projects) there will not be a single "genesis" contract. Instead owners of DeFi contract creation HASHes should annotate such transactions as the "creation" of X contract with a description of the role of the contract within the project.

The word "creation" is broader than "genesis" but it should refer to contract creations or the initial funding of an externally owned account. It should not be used to describe mints of an NFT within a collection or transfer TXs.

#4 - Insufficient Claim Support

Some HASH annotations describe the significance of a transaction without providing enough breadcrumbs for the Historians to follow to be able to confirm. This is especially important in two situations:

1. When a claim refers to an off-chain event or fact that can't be verified from the transaction receipt itself; and
2. When the transaction is an interaction with an unverified contract.

If either situation applies to your HASH annotation, make sure you provide enough support to enable the Historians to be able to verify your claim.

💡 When making a claim that a real world person was involved in a transaction, make sure to provide evidence that the person controls the wallet involved.

#5 - Providing Confusing Context

Often significant events on Ethereum manifest with a single transaction that has the primary historical impact but is connected to other related transactions of secondary importance.

For instance, major hacks or exploits typically involve a draining transaction where assets flow out of the protocol into the exploiter's control, but which was set up by additional transactions (i.e., the initial funding of the exploiter's EOA, the deployment of the malicious attack contract, a token approval, etc.) or which led to subsequent transactions (i.e., transfer of funds out of exploiter's wallet/contract, on-chain messages between the exploiter and the affected protocol team, return or burning of funds).

These secondary transactions have historical significance, but it's important when annotating such HASHes that you provide the appropriate context and avoid suggesting that a secondary transaction is actually the primary transaction. We’ve seen titles like "The [Famous Project] Hack" for secondary transactions like token approvals or EOA initial funding transfers. Even if the description accurately describes how the underlying transaction is a secondary transaction and places it in proper context to the primary transaction, the title misleadingly suggests that it is the primary transaction.

Hopefully these tips help you understand how to write a verifiable HASH annotations - we're available in the POB Discord Historians section to answers any questions you have. Let's make history together.