Foundations updated with networks. Verifcation added. Minting Overview updated to reconcile with Verification. Attestation schemas added.

Author: c-georgen

change-credits/cc-minting.md

@@ -27,6 +27,7 @@ sequenceDiagram
     actor Good Generator
     actor Change Code
     Good Generator-->Change Code: propose impact goal for review
+    participant EAS
     create participant hypercert (ERC1155)
     Good Generator->>hypercert (ERC1155): mint impact goal
     actor Change Code
@@ -40,8 +41,9 @@ sequenceDiagram
     end
     Good Generator-->Good Generator: implement project
     loop
-        Good Generator->>hypercert (ERC1155): submit impact evidence
-        Verifier--xhypercert (ERC1155): review evidence
+        Good Generator->>EAS: publish claim attestation
+        Verifier--xEAS: review evidence
+        Verifier->>EAS: publish verification attestation
         Change Code->>Token Bound Account (ERC6551): mint Change Credits (ERC721)
     end
     Loop
@@ -55,6 +57,6 @@ The above sequence diagram overviews how Change Credits are created. While the s
 1. The Good Generator submits an impact goal and plan for review by Change Code, as part of their onboarding process. Once approved to mint via the Changescape, the Good Generator mints their hypercert, signaling the beginning for their project.
 2. After the projects' hypercert has been deployed, Change Code deploys an associated Token Bound Account (TBA) to act as a treasury for the project to receive funds into and mint tokens from.
 3. Partners begin contributing funds into the project's TBA in exchange for IOUs redeemable for Change Credits once the latter begin to be minted. These funds are then remitted to an account from which the Good Generator can spend to cover the costs of their work. This process can be done in an open-ended asynchronous manner, with funds being contributed to the project through the project's lifespan.
-4. As the Good Generator carries out their work to produce impact, they periodically submit evidence for review. This evidence is stored as records tied to their original hypercert and can be accessed by specified Verifiers.
+4. As the Good Generator carries out their work to produce impact, they periodically submit evidence for review. This evidence is published via the Ethereum Attestation Service (EAS). These claims are then reviewed and approved or rejected by Verifiers.
 5. Once evidence is confirmed by Verifiers, Change Code intakes the data provided to assign a quantity of Change Credits to be created and mints them via the project's TBA.
 6. With Change Credits minted and available via the TBA, the project's Partners can redeem their IOUs and receive their proportional share of Change Credits.

change-credits/foundations.md

@@ -39,4 +39,27 @@ Hypercerts adhere to the ERC1155 standard for semi-fungible tokens. This mixed s
 ERC20 tokens are fully fungible and well suited for liquidity and open exchange. IOUs issued in anticipation of Change Credits are minted as ERC20 tokens to support the emergence of free exchange by holders who may wish to access liquidity.
 +++ ERC6551
 Referred to as "token bound accounts" (TBAs), ERC6551 tokens function as a form of smart contract wallet where an account is simultaneously able hold or mint tokens itself and be considered a token (an NFT more specifically) in its own right. Change Code leverages TBAs to serve as *treasury accounts* for the receipt of funds into projects and the minting of Change Credits.
-+++
++++
+
+### Network Infrastructure
+
+To maximize the reach of our work and do our best to always meet changemakers where they are, the Changescape is designed as a cross-chain or multi-chain protocol. Leveraging shared tools and being available to existing communities across different ecosystems is among our most important design considerations.
+
+#### Blockchain
+
+##### Optimism
+Initial smart contracts for the Changescape are being deployed onto the Optimism L2 mainnet. The Optimism community has demonstrated a deep commitment toward positive impact, both inside of and beyond climate specific initiatives. Moreover, the technology involved in the [OP Stack](https://docs.optimism.io/stack/getting-started) is among the most closely aligned with the the Ethereum core and its roadmap prioritizes key pieces of the Ethereum ecosystem that are critical to Change Code, such as [EAS](https://docs.attest.org/docs/quick--start/contracts#optimism).
+
+##### Celo
+For years the Celo blockchain stood out as the largest layer 1 blockchain network focused around positive impact. The network is currently undergoing a transition to enter the Optimism orbit as a part of the upcoming Optimism [Superchain](https://docs.optimism.io/stack/explainer). Change Code is closely following the advances of both [Celo](https://forum.celo.org/t/clabs-proposes-migrating-celo-to-an-ethereum-l2-leveraging-the-op-stack/7902) and the Superchain to eventually migrate our primary deployments when the time is right.
+
+##### Aztec
+While not currently emphasized in many circles focused on ReFi (regenerative finance) or public goods, the issue of privacy is something that we view as central to our long term vision and needs. It is often neglected that working for the benefit of all is a privilege and that while it may be safe for those in the *West* or the *Global North* to advance climate initiatives, engage in investigative journalism, or attempt to advocate for peace, many are not as fortunate. There are many situations in which climate action can be and is met with threats and physical violence, where educating women or ethnic minorities can make one a target of ideologues, or where it is impossible to mediate for peace without being at risk from extremists on either side of the divide.
+
+For these reasons and many more, Change Code has a long term interest in the use of zero-knowledge and other privacy preserving technology. We are actively researching to eventually upgrade our protocol to support project deployments where any identifying information about participants can be publicly shielded while still enabling robust verification. [Aztec](https://docs.aztec.network/), together with it's smart contract language Noir, presents the ideal route to achieve this vision.
+
+#### Interoperability
+
+Beyond any choices for which networks may be used to deploy the *logic* for the Changescape, is the question of where various tokens--IOUs, Change Credits, and Mutual Money--may be accessed. To make Change Credit tokens accessible across chains, while avoiding centralized bridges and potential honeypots which can be drained by attackers, Change Code is integrating [LayerZero](https://layerzero.network/how-it-works) for cross-chain token transfers.
+
+While this list will grow overtime, Change Code is currently prioritizing building connections to make our tokens available on Arbitrum and Solana as both chains have substantial ReFi and public goods communities.

change-credits/verification.md

@@ -3,22 +3,40 @@ label: Impact Verification
 order: -3
 ---
 
+The Changescape is designed as an *impact maximizing* protocol, meaning that every design decision is intended to drive capital and interest toward projects producing positive externalities most efficiently and effectively. Instead of focusing on social validation or popularity, the Changescape centers the concept of verification in the protocol so that primary impact representation in the system, Change Credits, are only ever minted from verified impact, rather than from mere claims of impact.
 
-Change Credits form the basis and backing of Mutual Money. As such, the verification of all impact claims is critical to ensuring that not only is the currency fully *backed* but also
+## Ethereum Attestation Service
+
+In order to accomplish this verification and ensure maximum interoperability with the broader space, Change Code leverages the Ethereum Attestation Service (EAS).
+
+EAS relies on `schemas` to structure the data provided as `attestations` that can be viewed either publicly or with specified permissions. As can be seen [here](../data-schemas/attestations.md), Change Code has two separate schemas defined. The first schema, the claim schema, is used by Good Generators to publish their claim attestations, the evidence they provide to substantiate their work and the impact produced. The second schema is used by Verifiers, after having reviewed the claims attestations, to denote either their acceptance or rejection of the claims made and to provide their quantification of the amount of impact produced.
+
+## Verification Flow
 
 ```mermaid
 sequenceDiagram
     actor Verifier
     actor Good Generator
     actor Change Code
-    participant Ceramic Network
+    participant EAS
     participant Token Bound Account (ERC6551)
     Good Generator-->Good Generator: implement project
     loop
-        Good Generator->>Ceramic Network: publish claim attestation via EAS
-        Verifier--xCeramic Network: review evidence
-        Verifier->>Ceramic Network: publish 
-        Change Code--xhypercert (ERC1155): assign token quantity
+        Good Generator->>EAS: publish claim attestation
+        Verifier--xEAS: review evidence
+        Verifier->>EAS: publish verification attestation
         Change Code->>Token Bound Account (ERC6551): mint Change Credits (ERC721)
     end
-```
+```
+
+As shown in the above sequence diagram, the process of verification can (and often will) be carried out as a loop. As a project is implemented over a period of weeks, months, or even years, the Good Generator may periodically submit claim attestations on recent accomplishments and evidence. As soon as these claims are available (or at some pre-arranged cadence), Verifiers may review this data and submit their own attestations. Finally, with these review attestations published, Change Code programmatically mints Change Credits in accordance with the impact quantity specified by the Verifiers.
+
+By allowing for interim data reporting, the protocol enables Verifiers to have access to data in a more timely manner, which in practice enables more robust dispute or follow up. Additionally, with this setup, Change Credits are available to Partners sooner than if all reporting were unnecessarily forced to only occur at the end of a project's timeline.
+
+## Verifiers
+
+Verifiers are experts impact measurement and evaluation selected to review data provided by Good Generators and assess the veracity and quantity of impact generated. When a project is instantiated, Verifers are specified along with an approval quorum. For example, a project may have listed 3 potential verifiers with any 2 being required to approve the project's claims for Change Credits to be issue.
+
+When it comes to the quantity of Change Credits to be issued, this number is obtained by a simple average of the all quantities reported by each approving Verifier.
+
+In the initial iteration of the Changescape, Verifiers are proposed by a project's Good Generator and approved by Change Code based on their expertise while confirming they are free from any conflicts of interest. In future versions of the protocol, this process is set to be upgraded to have Verifiers organized as a collective (or DAO) with the ability to control its own membership.

data-schemas/attestations.md

@@ -47,4 +47,10 @@ impactQuantity | `int64[]`
 evidenceDocumentation | `bytes32[]`
 :   IPFS reference to any documentation the Verifier wishes to provide.
 
-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).
+As described in the Change Credit [verification flow](../change-credits/verification.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 Storage
+
+Because the Changescape is designed as a cross-chain or multi-chain protocol, the matter of data storage for attestations is especially important. EAS supports either on-chain or off-chain attestation storage, with the former option being both more expensive and more conducive to a single chain experience.
+
+Changescape attestations are instead stored off-chain via the [Ceramic Network](https://developers.ceramic.network/docs/introduction/intro), a decentralized database network that supports InterPlanetary File System (IPFS). While remaining chain-agonistic for both writing and reading data, Ceramic manages to provide immutability by periodically [merklizing](https://docs.attest.org/docs/tutorials/ceramic-storage#ceramic-as-a-data-ledger) all updates and publishing the root to the Ethereum chain.