cc retirement flow added, minor language updates

Author: [email protected]

change-credits/cc-minting.md

@@ -31,36 +31,47 @@ sequenceDiagram
     create participant hypercert (ERC1155)
     Good Generator->>hypercert (ERC1155): mint impact goal
     actor Change Code
-    create participant Token Bound Account (ERC6551)
-    Change Code->>Token Bound Account (ERC6551): deploy treasury account
-    actor partner
+    create participant Treasury Account (ERC6551)
+    Change Code->>Treasury Account (ERC6551): deploy treasury account
+    actor Partner
     loop
-        partner->>Token Bound Account (ERC6551): send $
-        Token Bound Account (ERC6551)->>partner: mint IOUs (ERC20)
-        Token Bound Account (ERC6551)->>Good Generator: remit funding received
+        Partner->>Treasury Account (ERC6551): send $
+        Treasury Account (ERC6551)->>Partner: mint IOUs (ERC20)
+        Treasury Account (ERC6551)->>Good Generator: remit funding received
     end
     Good Generator-->Good Generator: implement project
     loop
         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)
+        Change Code->>Treasury Account (ERC6551): mint Change Credits (ERC721)
     end
     Loop
-        partner->>Token Bound Account (ERC6551): return IOUs
-        Token Bound Account (ERC6551)->>partner: receive Change Credits
+        Partner->>Treasury Account (ERC6551): return IOUs
+        Treasury Account (ERC6551)->>Partner: receive Change Credits
     end
 ```
 
 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, 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.
+2. After the projects' hypercert has been deployed, Change Code deploys an associated Token Bound Account (ERC6511) 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 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 Credit Ownership
 
-As detailed [here], a key utility of Change 
+Beyond forming the economic basis for [Mutual Money](../mutual-money/currency-minting.md), Change Credits create a special relationship between Partners and the Good Generators they back. As can be seen in the [schema](../data-schemas/change-credits-spec.md) for Change Credits, contributions to project's are represented as NFTs, meaning that each contribution, regardless of size, still creates a single token. The reasoning behind this decision is, at least in part, a statement of values from Change Code that all contributions matter and should be recognized.
+
+When it comes to the rights conferred to Change Credit holders (Partners), each project's Good Generator is required to specify. They can choose to select and calibrate any (or all) of the following.
+
+##### Voting Power
+Good Generators can use Change Credits to include their Partners in decision making processes. These can be small decisions or large decisions, implemented on a one-time or ongoing basis. Additionally, Good Generators can select how to allocate voting power. Each NFT holder can be given a single vote or alternatively the `Balance` can be used so that Partners representing larger economic interest are given larger influence.
+
+##### Exclusive Access
+It is not uncommon for organizations producing positive externalities host events, whether social, cultural, or academic, where attendance is in high demand. Change Credits can be used to grant access to these events.
+
+##### Credit Retirement
+Certain Good Generators may be social enterprises, capable of producing both profit and positive externalities, or may be engaged in various forms of blended finance. In either case, there will be Good Generators who may be both capable of and interested in offering an economic incentive to further entice Partners to support their positive work. One means to realize this alignment is through Change Credit [retirement](./cc-retirement.md).

change-credits/cc-retirement.md

@@ -0,0 +1,30 @@
+---
+label: Change Credit Retirement
+order: -4
+---
+
+When a Good Generator is able concurrently generate positive impact and traditional revenue, an opportunity emerges to further align interests between themselves and their Partners. These social enterprises may leverage Change Credits to jump start their work in producing green energy, developing affordable housing, lowering the cost of healthcare or education, or achieving almost any other means of positive change that can also produce revenue.
+
+A more traditional model for these social enterprises would be to offer equity or debt from their organizations where the positive impact is seen and structured as merely an ancillary benefit. The shortcoming in such a model is that there is no economic value ascribed to the impact externality itself, but the cost is still present. Imagine a company that made tables and chairs but could only sell its tables, while being expected to produce and distribute its chairs without payment. Would this company be able to effectively compete for capital against a business that produced and sold only tables without the deadweight of chair production.
+
+The Changescape is different. Inside the Changescape, positive externalities are seen as economic goods unto themselves. In support of this paradigm shift, instead of selling equity or debt with *blended returns*, social enterprises can instead commit funds to repurchase and retire their Change Credits.
+
+## Retirement Flow
+
+```mermaid
+sequenceDiagram
+    actor Good Generator
+    participant Treasury Account
+    actor Partner
+    Good Generator->>Treasury Account: fund for retirement
+    Partner-->Treasury Account: signal interest in retirement
+    Treasury Account->>Partner: distribute funds and update Change Credit
+```
+
+The above sequence diagram offers an overview of the steps of Change Credit retirement, which is described in greater detail across 6 steps.
+
+1. Before any of the above interactions take place, the Good Generator may optionally specify a target or even guaranteed amount of funds that will be used to repurchase and retire its Change Credits. This target can be published as part of deploying the project inside the Changescape or may simply be disseminated through the organizations usual channels communication.
+2. Once funds are available (and after Change Credits have already begun to be distributed), the Good Generator would remit funds into the project's Treasury Account.
+3. With funds available in the account, the Good Generator must specify how retirement will occur--declaring the price they are willing to pay for each Change Credit received and optionally setting a maximum fraction of each Change Credit that may be retired.
+4. Partners holding Change Credits may now signal themselves as interested in retirement, optionally setting their own maximum retirement portion.
+5. As Partners signal interest in retirement, the Treasury Account automatically distributes funds and updates the `Balance` and `Retirement` values of participating Change Credits accordingly.

change-credits/verification.md

@@ -19,13 +19,13 @@ sequenceDiagram
     actor Good Generator
     actor Change Code
     participant EAS
-    participant Token Bound Account (ERC6551)
+    participant Treasury Account
     Good Generator-->Good Generator: implement project
     loop
         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)
+        Change Code->>Treasury Account: mint Change Credits (ERC721)
     end
 ```
 

data-schemas/change-credits-spec.md

@@ -18,6 +18,9 @@ Change Credits are implemented as follows:
 `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.
 
+`minContribution`
+:   The `minContribution` specifies the smallest monetary contribution that can be made to a project to mint a Change Credit. This variable sets a minimum only on price and is not intended to be a mechanic for any further price action.
+
 `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
@@ -41,6 +44,10 @@ Change Credits are implemented as follows:
         "display_type": "number",
         "trait_type": "Redemption",
         "value": "{Portion of the Change Credit that has already been redeemed by the holder}"
-    }]
+    },
+    {
+        "display_type": "number",
+        "trait_type": "Balance",
+        "value": "{Remaining balance after subtracting Retirement and Redemption}"}]
 }
 ```

mutual-money/currency-minting.md

@@ -0,0 +1,6 @@
+---
+label: Currency Minting
+order: -1
+---
+
+*in progress*