[Eval] Evaluations MVP
Closed this issue · 1 comments
bitbeckers commented
Describe the feature you'd like to request
This is the first iteration of implementing attestations into the hypercert ecosystem. The scope of this dev cycle will be establishing the patterns required to grow our evaluation ecosystem. A more detailed discussion can be found in #1259 .
User stories:
V0: Users can attest a hypercert, i.e. confirms that the information is correct and that the contributors and minter are who they claim to be.
V0: Users can include in the attestation tags for a hypercert.
Deliverable
Example use case: Gitcoin attest a hypercert that was part of a round and labels the hypercert as part of that round.
This schema is pseudo code :)
Signs:
organisation: bytes32
isCorrect: boolean
claimTokenID: uint256
contractAddress: address
chainID: uint256
reason: string
external_uris: string[]
tags: string[]
In the GitCoin example:
organisation: 0xdasdsac...dfasfdsGitCoin
isCorrect: true
claimID: 23819765684465692442436222520223774801920
contractAddress: 0xa16dfb32eb140a6f3f2ac68f41dad8c7e83c4941
chainID: 11155111
reason: "Got accepted to GG19 OSS round"
external_uris: [https://explorer.gitcoin.co/#/round/10/0xb5c0939a9bb0c404b028d402493b86d9998af55e, {contract: 0xb5c0939a9bb0c404b028d402493b86d9998af55e}]
tags: ["GG19", "OSS"]
Describe the solution you'd like
Implementations needed:
- Create EAS schema in EAS registry
- Create minimal attestation app based on starter app
- Index attestations in Graph
- Implement EAS signer and schema in SDK
- Fetch attestations in Graph via SDK
- Display attestations in same view as hypercert
- Refine flow to support attestations on a chain that does not support EAS; to prevent lock-in
Stretch:
- on-chain curation of allowed attesters; can can also track approved addresses and filter them on the FE level.
Describe alternatives you've considered
.