IOU data schema added

Author: c-georgen

change-credits/cc-minting.md

@@ -1,11 +1,8 @@
 ---
 label: Minting Change Credits
-layout: page
 order: -2
 ---
 
-## Minting
-
 Because Change Credits are only minted following confirmation of realized, tangible, and verifiable impact, there the process by which these assets are created follows a number of steps and involves multiple types of actors.
 
 ### Participants
@@ -28,10 +25,11 @@ Verifier
 sequenceDiagram
     actor Verifier
     actor Good Generator
+    actor Change Code
+    Good Generator-->Change Code: propose impact goal for review
     create participant hypercert (ERC1155)
     Good Generator->>hypercert (ERC1155): mint impact goal
     actor Change Code
-    Change Code--xhypercert (ERC1155): review impact goal
     create participant Token Bound Account (ERC6551)
     Change Code->>Token Bound Account (ERC6551): deploy treasury account
     actor partner
@@ -53,4 +51,11 @@ sequenceDiagram
     end
 ```
 
-The above sequence diagram overviews the process of 
+The above sequence diagram overviews how Change Credits are created. While the system supports alternative flows to facilitate various forms of financing, we can consider this base form to have x steps.
+
+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, signalling 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.
+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

@@ -1,11 +1,8 @@
 ---
 label: Foundations
-layout: page
 order: -1
 ---
 
-# Foundations
-
 Change Credits are a novel *financial* primitive supporting resource allocation, verification, and tracking of positive externalities (social and environmental impact).
 
 They are the basis and grounding of Change Code's economic engine, providing a real-world tangible link to underpin a new form of beneficial currency.
@@ -35,7 +32,7 @@ ERC721 is the most widely adopted token standard for NFTs. The standard is well
 +++ ERC1155
 Hypercerts adhere to the ERC1155 standard for semi-fungible tokens. This mixed standard, existing in the divide between fungible and non-fungible tokens, offers ideal flexibility for the unique requirements of the hypercerts standard.
 +++ ERC20
-ERC20 tokens are fully fungible and well suited for liquidity and open exchange. IOUs issued in anticipation of Change Credits themselves are minted as ERC20 tokens to support the emergence of free exchange by holders who may wish to access liquidity.
+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.
 +++

contributing/community-conduct.md

@@ -1,11 +1,8 @@
 ---
 label: Community Code of Conduct
-layout: page
 order: -1
 ---
 
-# Community Code of Conduct
-
 ## Our Pledge
 
 We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.

contributing/contribution-guide.md

@@ -1,11 +1,8 @@
 ---
 label: Contribution Guide
-layout: page
 order: -2
 ---
 
-# Contribution Guide
-
 ## Community Conduct
 
 We are all people, all community members first, and developers second. All developers and other contributors agree to uphold Change Code's rules of [Community Conduct](./community-conduct.md).

data-schemas/hypercerts.md

@@ -0,0 +1,22 @@
+---
+label: Hypercerts
+order: -1
+---
+
+IOUs are implemented as ERC20 (fungible) tokens, to maximize both compatibility with existing tools and to streamline the transferability of IOUs before they are redeemed for Change Credits.
+
+To define a batch of IOUs inside the Changescape the following specifications are made:
+
+Name | `CC IOU | {Good Generator} {Index}`
+:   The token name assigned to each batch of IOUs always begins with "CC IOU", this is then followed by the name of the Good Generator and an index. The purpose of the index is to differentiate between different projects from one Good Generator.
+
+Symbol | `CC-IOU-{ProjectID}`
+:   The abbreviated token symbol begins "CC-IOU" and is followed by a project ID, where the project ID is composed of the unique ID assigned to the project's Good Generator followed by the project's index value.
+
+Total Supply
+:   The supply of a project's IOUs will vary over its lifecycle. Initially, Change Code will mint a target number of tokens as specified in the project's minted hypercert. As IOUs are redeemed for Change Credits, the IOUs returned to the TBA are subsequently burned.
+
+Supply Cap
+:   IOUs are implemented including the `ERC20Capped` extension. As such, the Good Generator can specify that the supply of all IOUs is capped at the initial supply set in their target.
+
+For more information regarding the ERC20 token standard, we refer you to documentation maintained by OpenZeppelin [here](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20).

data-schemas/index.yml

@@ -0,0 +1,4 @@
+icon: code-of-conduct
+expanded: true
+order: -5
+label: Token Implementations and Data Schemas

data-schemas/ious.md

@@ -0,0 +1,22 @@
+---
+label: IOUs
+order: -2
+---
+
+IOUs are implemented as ERC20 (fungible) tokens, to maximize both compatibility with existing tools and to streamline the transferability of IOUs before they are redeemed for Change Credits.
+
+To define a batch of IOUs inside the Changescape the following specifications are made:
+
+Name | `CC IOU | {Good Generator} {Index}`
+:   The token name assigned to each batch of IOUs always begins with "CC IOU", this is then followed by the name of the Good Generator and an index. The purpose of the index is to differentiate between different projects from one Good Generator.
+
+Symbol | `CC-IOU-{ProjectID}`
+:   The abbreviated token symbol begins "CC-IOU" and is followed by a project ID, where the project ID is composed of the unique ID assigned to the project's Good Generator followed by the project's index value.
+
+Total Supply
+:   The supply of a project's IOUs will vary over its lifecycle. Initially, Change Code will mint a target number of tokens as specified in the project's minted hypercert. As IOUs are redeemed for Change Credits, the IOUs returned to the TBA are subsequently burned.
+
+Supply Cap
+:   IOUs are implemented including the `ERC20Capped` extension. As such, the Good Generator can specify that the supply of all IOUs is capped at the initial supply set in their target.
+
+For more information regarding the ERC20 token standard, we refer you to documentation maintained by OpenZeppelin [here](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20).