spec cleanup

Author: c-georgen

change-credits/cc-minting.md

@@ -62,3 +62,5 @@ The above sequence diagram overviews how Change Credits are created. While the s
 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 Credit Ownership
+
+As detailed [here], a key utility of Change 

data-schemas/change-credits-spec.md

@@ -1,8 +1,46 @@
 ---
-label: Change Credits Specification
+label: Change Credits
 order: -4
 ---
 
-Change Credits are non-fungible (NFT) tokens implemented according to the ERC721 standard, the most commonly used NFT standard in web3.
+Change Credits are non-fungible (NFT) tokens implemented according to the ERC721 standard, the most commonly used NFT standard in web3. The motivation to use non-fungible tokens, used most commonly as digital collectibles or as tools to control membership access, is two fold.
 
-To define a  inside the Changescape, the following specifications are made:
+First, Good Generators may elect to confer invitations to events or provide partner only forms of communication or community. These uses of "token gating" are well solved by NFTs as they provide clearest binary between partners (those who hold a project's NFT) and others. The second consideration for constructing Change Credits as NFTs is admittedly more abstract. While there is no ignoring the fact that larger contributions to projects can have a larger impact, it is important to emphasize and embrace the idea that simply partnering for impact in the first place and at any level of contribution is the most important step one can take.
+
+Change Credits are implemented as follows:
+
+`Name` | CC | \{Good Generator\} \{Index\}
+:   The token name assigned to each set of Change Credits always begins with "CC". 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-\{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.
+
+`tokenURI`
+:   The `tokenURI` sets the IPFS link to the metadata (defined below) with further details of the NFT. The Change Credit implementation includes the [`ERC721URIStorage`](https://docs.openzeppelin.com/contracts/5.x/api/token/erc721#ERC721URIStorage) extension so that each instance of token in the set can have its own unique metadata.
+
+`Metadata`
+:   Included here is the json schema for the metadata stored at the NFT's `tokenURI`. The first 4 properties are included to comply with the metadata structure set by NFT marketplaces and viewers such as [OpenSea](https://docs.opensea.io/docs/metadata-standards). 
+```json
+{
+  "description": "{A description, not exceeding 200 characters, of the work accomplished by the project}", 
+  "external_url": "{Unique Changescape URL}", 
+  "image": "{link to Hypercert Image URL}", 
+  "name": "CC | {Good Generator} {Index} {Serial #}",
+  "attributes": [
+    {
+        "display_type": "number",
+        "trait_type": "Contribution",
+        "value": "{Total value of the contribution behind the Change Credit}"
+    },
+    {
+        "display_type": "number",
+        "trait_type": "Retirement",
+        "value": "{Portion of the Change Credit that has already been retired by the Good Generator}"
+    },
+    {
+        "display_type": "number",
+        "trait_type": "Redemption",
+        "value": "{Portion of the Change Credit that has already been redeemed by the holder}"
+    }]
+}
+```

data-schemas/hypercerts.md

@@ -7,39 +7,39 @@ Change Code leverages the Hypercerts protocol, itself developed from the ERC1155
 
 ## ERC1155 Fields
 
-Name | `CC Hypercert | {Good Generator} {Index}`
+`Name` | CC Hypercert | \{Good Generator\} \{Index\}
 :   The Hypercert name mirrors the name used for a project's IOUs. The concept of an index is again used to support single organizations working across multiple initiatives.   
 
-Description
+`Description`
 :   A description, not exceeding 200 characters, of the work to be done by the project.
 
-Image
+`Image`
 :   While the image field is required by the Hypercerts standard, we do not believe a single immutable image to be valuable for the purposes of serious impact validation. To satisfy this requirement, the Changescape backend will automatically generate and provide an image to satisfy the requirement.
 
 ## Hypercert Dimensions
 
-work_scope
+`work_scope`
 :   A list of tasks to be done by the project. In development parlance this is a list of *outputs*--e.g. # of solar panels installed, kilos of supplies, $ of direct aid, # of vaccines.
 
-work_timeframe
+`work_timeframe`
 :   The time period during which the project work is to be carried out. In line with the Hypercerts standard, this is represented as an ordered pair of UTC timestamps.
 
-impact_scope
+`impact_scope`
 :   Inside the Changescape `impact scope` is used to refer thematically to projects by category. For example, the [UN Sustainable Development Goals (SDGs)](https://sdgs.un.org/goals) or the [Ecological Benefits Framework (EBF)](https://ebfcommons.org/lex-icons/). Because the Hypercerts data is only aspirational, it would be premature to immutably publish indicators, which are instead reserved to be published only once verified inside Change Credits.
 
-impact_timeframe
+`impact_timeframe`
 :   The time period during which impact *outcomes* will be measured and calculated. For Hypercerts inside the Changescape, the start time is set equal to the start time for the `work_timeframe` while the end time is set for the end of the work period plus five (5) years. Again this data is represented as an ordered pair of UTC timestamps.
 
-contributors
+`contributors`
 :   A list of participants (organizations) that are contributing to the work done in the project. Each element in the list is composed of an on-chain address, a name, and a weight. The purpose of the weight is to signal relative contribution and may optionally be used to weight distributions among contributors.
 
-rights
+`rights`
 :   As of version 1.0 of the Hypercerts standard, this value can only be set to *public display*. As it is a required field, Change Code simply applies the default value but does not otherwise use this information.
 
-hidden_properties
+`hidden_properties`
 :   In development
 
-## Example Hypercert Dimensions
+## Sample Hypercert Dimensions
 
 ```json
 "hypercert": {

data-schemas/ious.md

@@ -5,18 +5,18 @@ 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:
+IOUs are minted according the the below specification:
 
-Name | `CC IOU | {Good Generator} {Index}`
+`Token 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}`
+`Token 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.
+`Total Supply`
+:   The supply of a project's IOUs will vary over its lifecycle. Initially, a target number of tokens as specified in the project's hypercert will be minted and held in the project's token bound account. As IOUs are redeemed for Change Credits, the IOUs returned to the TBA are subsequently burned.
 
-Supply Cap
+`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).

mutual-money/currency-minting.md

@@ -0,0 +1,4 @@
+icon: container
+expanded: true
+order: -4
+label: Mutual Money