Skip to content

Commit 18279a5

Browse files
committed
attestation schemas added
1 parent c188a5a commit 18279a5

File tree

4 files changed

+56
-2
lines changed

4 files changed

+56
-2
lines changed

change-credits/verification.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
---
2+
label: Verification
3+
order: -3
4+
---

data-schemas/attestations.md

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
---
2+
label: Attestation Schemas
3+
order: -3
4+
---
5+
6+
The Changescape leverage the Ethereum Attestation Service (EAs) to manage both initial claims of quantifiable impact as well as the verification of any claimed impact. The schemas for representing both of these attestations are specified below while an excellent overview around attestations and schemas can be found in the [EAS documentation](https://docs.attest.org/docs/category/core-concepts).
7+
8+
## Claim Schema
9+
10+
Before data can be verified it must first be attested to (or claimed) by the Good Generator(s). It is important to note that this is a separate requirement from the creation of a project's Hypercert. As can be seen from Change Code's Hypercert [specification](./hypercerts.md), the Hypercert is published before a project's work begins and accordingly would not have any information regarding results.
11+
12+
hypercertID | `bytes32`
13+
: Every attestation must link to the Hypercert of the project for which it is claiming impact. This is accomplished by including the Hypercert's unique 32 byte identifier.
14+
15+
impactUnit | `string[]`
16+
: The unit according to which the impact or positive externality is quantified--e.g. metric tons of carbon sequestered, liters of clean water, vaccine doses administered, etc.
17+
18+
impactQuantity | `int64[]`
19+
: The quantity of impact claimed according to the unit specified in the attestation.
20+
21+
evidenceDocumentation | `bytes32[]`
22+
: IPFS reference to any documentation the Good Generator wishes for the verifiers to review in order to assess the claims made.
23+
24+
!!!info Note
25+
As each project (with a single Hypercert) may very well have more than one quantifiable metric, *impactValue*, *impactUnit*, and *evidenceDocumentation* can each support arrays or multiple entries each. This is indicated by the inclusion of `[]` in each.
26+
!!!
27+
28+
While not explicitly part of the attestation schema, claim attestations made inside the Changescape include a modified version of the [`Attestor Resolver`](https://docs.attest.org/docs/tutorials/resolver-contracts#attester-resolver) contract in order to allow Good Generator's submitting claims to name specific Verifiers along with a quorum of those Verifiers required for the claim to be considered verified.
29+
30+
!!!warning Acknowledgement
31+
We recognize that having Good Generator's list allowed Verifiers may create issues of objectivity or conflict. In future versions of the Changescape, this setup will be replaced with a form of token gating through which only recognized experts can stake a form of reputation to evaluate projects.
32+
!!!
33+
34+
## Verification Schema
35+
36+
The second attestation schema structures verifications (or refutations) in reference to impact claims so that Change Credits can be appropriately issued.
37+
38+
hypercertID | `bytes32`
39+
: Every attestation must link to the Hypercert of the project being reviewed. As with the claim schema, this is accomplished by including the Hypercert's unique 32 byte identifier.
40+
41+
impactUnit | `bool[]`
42+
: This boolean field is used by Verifiers to either accept (true) or reject (false) the proposed set of impact units.
43+
44+
impactQuantity | `int64[]`
45+
: Provided an impact unit is accepted, this field captures the quantity of impact produced according to the attesting Verifier.
46+
47+
evidenceDocumentation | `bytes32[]`
48+
: IPFS reference to any documentation the Verifier wishes to provide.
49+
50+
As described in the Change Credit [minting flow](../change-credits/cc-minting.md), data may be provided by a Good Generator periodically across multiple submissions as the project progresses over time. Because of this flexibility, a single Hypercert may see multiple claim attestations made, consequently the hypercertID is not sufficient to uniquely identify a claim. To resolve this, each verification attestation points to a corresponding claim attestation through an [`refUID`](https://docs.attest.org/docs/tutorials/referenced-attestations).

data-schemas/hypercerts.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@ hidden_properties
4141

4242
## Example Hypercert Dimensions
4343

44-
```
44+
```json
4545
"hypercert": {
4646
"work_scope": {
4747
"name": "Work Scope",

retype.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,5 +7,5 @@ branding:
77
footer:
88
copyright: "© Copyright {{ year }} Change Code, Inc. All rights reserved."
99

10-
editor:
10+
editor:
1111
enabled: false

0 commit comments

Comments
 (0)