Questions:

1. Are Attestation Issuer URI, attestationURI optional?

DAOIP-3 specifies an efficient strategy for publishing and searching for on- and off-chain DAO-related attestations. The end goal here is to make sure that the state of attestations is interoperable. Well, what does this mean? Assume this scenario:

1. Alice donates 0.053 ETH to DreamDAO via Gitcoin, which they publish as an off-chain attestation.
2. Alice receives a proof-of-contribution attestation from VitaDAO through Disco. This attestation was issued on-chain via EAS.
3. Alice gets her last month’s delegate activity uploaded on-chain as a custom attestation made by Karma.

Imagine now that DeepDAO, an aggregator that already tracks Alice’s governance contributions (her votes and proposals to DAOs) decides to start aggregating more information on her. To integrate with Gitcoin, Disco, and Karma, DeepDAO will need to understand the attestation management as well as the attestation schemas in all 3 cases. But, as you can imagine, the trouble doesn’t stop at 3. We have 10s of tooling providers already issuing various on- and off-chain attestations, and this number will only increase. Hence having a common schema will save everyone’s time. This is what DAOIP-3 is trying to achieve.

How does it work?

It's pretty straightforward. The standard specifies that all attestations compliant with the standard MUST look like this:

{
	"@context": ["<https://daostar.org/schemas>", "<https://www.w3.org/ns/credentials/v2>"],
	"type": ["VerifiableCredential", "Attestation", "<the type of the attestation if any>"],
	"issuer": "<URI returning data conforming to the Attestation Issuer JSON-LD Schema>",
	"attestationURI": "<the URI or API request from which someone can obtain the attestation>",
	"expirationDate": "<ISO DateTime>",
	"credentialSubject": {
		"<mySubjectProperty>": "<mySubjectValue>"
	}
}

<mySubjectProperty> is a placeholder variable for your use-case. For example, if you were to attest for contributing to a DAO, properties such as contribution type, impact, proof, etc. may need to be captured. Consider this EAS schema. Any issuer can use this schema to create DAOIP-3 attestations. Let us assume that DAOstar is an issuer interesting in awarding an onchain attestation to anyone who reads this article. To issue such an attestation, we could easily design a front-end that takes a person’s address and date of read to issue an attestation:

*Forgive the poor design

Once the address and date are available, the issuer (DAOstar) can fill the rest of the info required by the schema. It might look like this if vitalik.eth reads this article on 04.08.2024 [change this by updating the issuer field]. The dates are in ISO-8601 format. Note that the attestation also contains an issuer field, which brings us to the next requirement.

Every issuer (like DAOstar in this case) should publish an Attestation Issuer endpoint returning data in this format: