# Cosmo-Local Credit

> Cosmo-Local Credit helps people and organizations support, share, and exchange goods and services.

# Getting started

Cosmo-Local Credit (CLC) is a progressive web app for creating, discovering, holding, transferring, and exchanging digital assets, including redeemable vouchers, through independently governed Commitment Pools. The CLC App is available at [cosmolocal.credit](https://cosmolocal.credit).

[Grassroots Economics Foundation](https://grassrootseconomics.org/about/) (GEF) operates the App and supporting infrastructure. Unless GEF expressly accepts another role for a particular Offering or transaction, it is not the issuer of a user-created voucher, the Pool Steward of a user-created pool, a custodian, lender, borrower, guarantor, insurer, or redeemer. Issuers are responsible for their voucher commitments, and Pool Stewards are responsible for their pool rules.

Read [Concepts and Vocabulary](/introduction/concepts) for the exact product layers, roles, actions, values, fees, and status terms used in these docs.

Before creating an account or transacting, read the [Terms of Service](/governance/terms). In particular:

- You must be at least 18 years old, have reached the age of legal majority that applies to you, and have contractual capacity.
- You are responsible for confirming that your account, voucher, pool, or transaction is lawful in every relevant jurisdiction.
- Wallet credentials must be protected. GEF may be unable to recover a lost wallet or reverse an authorized transaction.
- Public-blockchain transactions and records may be visible, permanent, and irreversible.
- A listing in the App is not a GEF endorsement or a guarantee of redemption, value, liquidity, convertibility, or cash-out.

## Start with the current App

### 1. Browse the Market

Open [cosmolocal.credit](https://cosmolocal.credit) to explore the public **Market**, the App's discovery catalog. Review the responsible issuer, the promised goods or services, location, availability, and published terms. A Market listing is not automatically an exchange venue, seller relationship, independent valuation, endorsement, or guarantee.

### 2. Create or access an account and wallet

The App uses an account for profile and session access and a wallet for blockchain authorization. Protect your passkey, paper-wallet material, recovery information, devices, and any other credentials. Review every asset, amount, address, pool, fee, and authorization before confirming a transaction.

### 3. Create a voucher

A voucher combines several distinct layers:

1. token-contract mechanics and balances;
2. the issuer's voucher designation and published terms;
3. one or more Offering records for associated goods or services; and
4. the issuer's real-world fulfillment.

Creating or minting a token does not by itself prove that an Offering exists, that the issuer has capacity, or that GEF guarantees redemption.

### 4. Create or assess a Commitment Pool

A Commitment Pool is a governed arrangement. Its current `SwapPool` contract can hold supported token inventory and execute direct swaps. Before using or contributing to one, review:

- the accountable Pool Steward and the current contract owner;
- the proxy administrator and controllers of configured dependencies;
- admitted vouchers and other supported assets;
- exchange-rate or quote methods;
- the App's **“Credit limit”**, which is a pool token-balance cap rather than personal credit;
- Pool and protocol fees;
- available inventory and the Pool owner's liquidity-withdrawal power; and
- any separately published contribution, guarantee, reserve, or insurance terms.

A deposit transfers assets to the `SwapPool`. Protocol v1.1.0 does not mint Pool-share tokens or automatically give the depositor repayment, withdrawal, reward, or governance rights.

### 5. Use the correct action

- **Send** transfers a token balance to another address.
- **Pool swap** exchanges one supported asset for another through one `SwapPool`. On-chain swap settlement does not prove issuer fulfillment.
- **“Redeem”** opens the send flow with the token owner's address prefilled. It presents or returns the voucher to the issuer; completed redemption also requires the issuer's promised performance and a discharge record that prevents reuse.
- **“Retire voucher”** hides the catalog listing. It does not burn balances, cancel the voucher, or extinguish the issuer's outstanding obligations.
- **Pool liquidity withdrawal** lets the Pool owner transfer available inventory.
- **Fee collection** sends accrued Pool fees to the configured recipient.

See the [practical voucher example](/introduction/example) for the complete lifecycle.

## Current, deployment-dependent, and proposed capabilities

The current App provides a Market and supported flows for accounts, wallets, vouchers, Offerings, pools, transfers, direct Pool swaps, and related records. Availability depends on the active deployment, asset, Pool configuration, device, network, eligibility, provider, jurisdiction, and published terms.

Payment services, support methods, rewards, guarantees, contribution arrangements, and other provider integrations are deployment-dependent. Their responsible party, fees, limits, eligibility, and legal terms must be disclosed where they are offered.

Protocol v1.1.0 provides direct Pool execution and a quote-only `SwapRouter`. Multi-hop execution, HTLC or escrow routing, batch netting, shared insurance, proposed governance assets, network liquidity programs, and regulated payment rails remain proposed or deployment-dependent unless a specific deployment identifies them as active.

Any future loan or other credit product requires separately presented supplemental and transaction terms. An ordinary transfer, Pool deposit, Pool swap, redemption presentment, fulfillment, or discharge is not automatically a loan, advance, or repayment.

Next, read the [Protocol overview](/protocol/overview), the [governance mechanics](/governance/mechanics), or the broader [White Paper](/white-paper).

# Concepts and vocabulary

Cosmo-Local Credit connects an application, an open protocol, independently governed pools, and the real-world commitments represented by vouchers. These layers work together, but they are not the same thing.

This page defines the terms used across the documentation. Exact app labels appear in quotation marks where the interface uses a shorter or potentially ambiguous name.

## Product and protocol layers

| Term | Meaning |
| --- | --- |
| **Cosmo-Local Credit (CLC)** | The product family: the CLC App, its documentation, and the wider commitment-pooling work. |
| **CLC App** | The progressive web app at [cosmolocal.credit](https://cosmolocal.credit). GEF operates this interface and its supporting services. |
| **Commitment Pooling Protocol (CPP)** | The reusable model of curation, valuation, limitation, exchange, and accountable governance. |
| **Protocol v1.1.0** | The verified public smart-contract release documented in the [Protocol reference](/protocol/overview). |
| **Commitment Pool** | A governed arrangement that curates assets, publishes rules, and enables exchange. **Pool** is the ordinary shorthand. |
| **`SwapPool`** | The current Protocol contract that holds token inventory and executes direct swaps. It is one technical component of a Commitment Pool. |
| **Proposed CLC governance token** | A future governance design in the White Paper. It is not a current App or Protocol v1.1.0 asset. |
| **Proposed CLC Network Pool** | A future network-level clearing and coordination design. It is not the same as a current `SwapPool`. |

## Tokens, vouchers, and Offerings

A **token** is an on-chain balance or digital asset. Token mechanics can record supply, transfers, expiry, and burning, but they do not by themselves promise goods, services, cash conversion, or redemption.

A **voucher** is a token or record that an issuer represents as a redeemable commitment under published terms. Those terms should identify what is promised, who is responsible, where and when it can be presented, material limits, and the fulfillment and complaint process.

An **Offering** is the catalog record for goods or services associated with a voucher. Publishing an Offering does not mint tokens, prove availability, or show that fulfillment occurred.

These are four separate layers:

1. the token contract and balances;
2. the voucher designation and published terms;
3. one or more Offering records; and
4. the issuer's real-world performance.

## Accountable roles and technical control

| Role or authority | Responsibility or power |
| --- | --- |
| **Issuer** | Publishes and fulfills a voucher commitment. This responsibility is not automatically transferred merely because contract ownership changes. |
| **Holder** | Controls a voucher balance. Control does not prove fulfillment, cash value, or a guarantee. |
| **Service provider** | A public-facing persona. A service provider becomes an issuer when it publishes a voucher commitment. |
| **Pool Steward** | The accountable person, cooperative, public agency, federation, multisig, service, or other structure that publishes and administers Pool rules. |
| **Pool owner** | The address with the current `SwapPool` owner powers, including configuration, fee collection, and available-liquidity withdrawal. |
| **Proxy administrator** | The authority that can upgrade a proxied contract implementation. It may differ from the Pool owner. |
| **Dependency controller** | An owner or writer controlling a registry, limiter, quoter, oracle, fee policy, or protocol-fee controller. |
| **Catalog moderator** | An App operator that can correct, hide, or restore catalog records without changing on-chain balances. |
| **Fee recipient** | The configured address receiving a Pool or protocol fee. It is not necessarily the Pool Steward or owner. |
| **Supporter or liquidity provider** | A participant contributing assets under separately disclosed terms. The current `SwapPool` does not create Pool shares or automatic repayment, withdrawal, reward, or governance rights. |

“Community member” is informal social language. It does not by itself create admission, ownership, governance, repayment, or other legal rights.

## Actions and lifecycle

| App or documentation term | What it means |
| --- | --- |
| **Create or publish a voucher** | Deploy or configure a token and publish its catalog record and terms. |
| **Issue or mint** | Create token balance under the configured owner or writer authority. |
| **Publish an Offering** | Add a goods or services record beneath a voucher. |
| **Send** | Transfer a token balance to another address. |
| **“Redeem”** | In the current App, open the send flow with the token owner's address prefilled. This presents or returns tokens to the issuer; it does not prove fulfillment. |
| **Fulfill** | The issuer provides the promised goods, services, benefits, or other performance. |
| **Discharge** | Record fulfilled units so they cannot be presented again, for example by receiving, burning, cancelling, or otherwise disabling them under the published terms. |
| **“Retire voucher”** | Hide a voucher from the App catalog. Balances and history remain, and an administrator can restore the listing. It is not a burn or cancellation. |
| **Pool deposit or contribution** | Transfer assets into a `SwapPool`. Rights to repayment, withdrawal, rewards, or governance exist only when separately disclosed. |
| **Pool swap** | Exchange one supported asset for another through one `SwapPool`. This is not issuer fulfillment or automatically a loan. |
| **Pool liquidity withdrawal** | The Pool owner transfers available inventory to a selected address. |
| **Fee collection** | A configured recipient collects accrued Pool fees. |

Use **swap settlement** for the on-chain transfers and fee accounting that complete a Pool swap. Use **redemption presentment**, **fulfillment**, and **discharge** for the separate real-world voucher lifecycle.

## Market, values, limits, and fees

The App's **Market** is a discovery catalog for vouchers, Pools, Offerings, and public information. A listing is not automatically an exchange venue, seller relationship, endorsement, valuation, or guarantee.

Keep these value terms separate:

- **Offering price:** the amount requested for a listed good or service;
- **voucher stated value:** a value represented in the issuer's published terms;
- **Pool exchange rate or quote:** the transaction parameter produced by a Pool's configured quoter;
- **oracle reference:** external data used by a configured valuation module; and
- **redemption terms:** what the issuer promises to provide and under what conditions.

The App label **“Credit limit”** refers to a Pool's configured token-balance cap: the maximum amount of that token the Pool may hold after a deposit. It is not a personal credit line, an issuer-capacity check, or a guarantee of redemption. Proposed rolling, account, and network-wide limits in the White Paper are different mechanisms.

Current Protocol v1.1.0 can charge a **Pool fee** and an additional **protocol fee**. The proposed White Paper model separately describes a future **network rake** taken from Pool fees and possible routing or service fees. These models must not be combined when explaining current charges or calculating future revenue.

## Protections and evidence

Curation, registry inclusion, a limit, a reserve, App visibility, or a blockchain transaction does not by itself establish endorsement, issuer capacity, fulfillment, a guarantee, or insurance.

Any protection should identify the obligated party, covered event, funding, cap, exclusions, duration, evidence, and claim process. On-chain records can show addresses, assets, amounts, timestamps, and contract events. Issuer performance, satisfaction, governance deliberation, and social impact require separate disclosures, reports, attestations, or other evidence.

## Status words

- **Current:** verified in the CLC App or Protocol v1.1.0 described by these docs.
- **Deployment-dependent:** available only where a particular deployment, Pool, provider, jurisdiction, or published policy enables it.
- **Historical:** evidence or functionality from the earlier Sarafu Network service.
- **Proposed:** a design or roadmap mechanism that is not represented as deployed.

The [Getting started guide](/introduction/getting-started) applies these terms to the current App. The [Protocol reference](/protocol/overview) documents the verified contracts, while the [White Paper](/white-paper) presents the wider design and proposals.

For a supplementary, learn-through-play introduction to commitments, settlement, resource flows, exchange, and pooling, explore the [Grassroots Economics educational games](https://grassrootseconomics.org/games/). The games are learning resources, not definitions of current App or Protocol behavior.

# Practical voucher example

This example follows a voucher from issuance through a Pool swap, redemption presentment, fulfillment, and discharge. It illustrates the roles involved; it is not a promise that a particular voucher, pool, route, or outcome will be available.

For definitions used here, see [Concepts and Vocabulary](/introduction/concepts).

## 1. An issuer publishes a commitment

Imagine a community kitchen creates a digital meal voucher. Before issuing it, the kitchen publishes information a holder needs to make an informed decision:

- the kitchen's identity and contact details;
- the meal or other Offering represented by one voucher;
- supply, unit, stated value, and the kitchen's capacity to perform;
- where and during what hours it can be presented;
- any expiry date, booking process, fees, taxes, or transfer restrictions; and
- how presentment, fulfillment, complaints, refunds, substitutions, and other remedies work.

The kitchen is the issuer. It must keep this information accurate, avoid issuing beyond its reasonable capacity, and honor vouchers according to the terms under which holders acquired them. Creating the token or publishing the Offering does not prove that capacity or make GEF the issuer.

## 2. A Pool Steward admits the voucher

A food-security Commitment Pool reviews the kitchen, its voucher terms, and the Pool's own purpose. If admitted, the Pool Steward publishes the rules that apply, including:

- who is accountable for the Pool;
- the current `SwapPool` owner, proxy administrator, and material dependency controllers;
- accepted assets;
- exchange-rate or quote methods;
- token-balance caps, called **“Credit limits”** in the App;
- Pool and protocol fees;
- inventory and liquidity-withdrawal powers; and
- any separately funded guarantee, reserve, or support arrangement.

Admission means that the Pool's configured rules allow the voucher. It does not prove fulfillment capacity, establish cash value, or create insurance.

## 3. A participant contributes inventory

A supporter transfers meal vouchers or another supported asset into the `SwapPool` under the applicable published terms. That deposit increases available inventory.

The transfer does not automatically create a Pool share, repayment claim, withdrawal right, reward, or governance power. Any such right must come from a separate disclosed arrangement.

## 4. A holder makes a Pool swap

A holder exchanges one supported asset for meal vouchers through the Pool. The displayed quote is a transaction parameter produced by the configured quoter, not proof of the voucher's cash value or the kitchen's performance.

The direct Pool swap settles on-chain by transferring the input, output, Pool fee, and any additional protocol fee. It is not automatically a loan, issuer redemption, or real-world fulfillment.

## 5. The holder presents the voucher

In the current App, choosing **“Redeem”** opens the ordinary send flow with the token owner's address prefilled. Sending the voucher back is evidence of presentment to the issuer; it does not by itself prove that the kitchen supplied a meal.

The kitchen verifies the presentment and provides the promised meal under its published terms.

## 6. The issuer records fulfillment and discharge

After providing the meal, the issuer records the fulfilled units so they cannot be presented twice. Depending on the published process, this may involve receiving, burning, cancelling, or otherwise disabling the returned voucher.

If the kitchen does not honor its commitment, the holder uses the issuer's published complaint or remedy process and any rights available under applicable law. Neither GEF nor the Pool Steward becomes the redeemer merely because the App displayed the voucher or the Pool enabled a swap.

Choosing **“Retire voucher”** in the App is different: it hides the catalog listing while balances and history remain, and an administrator can restore it. It is not fulfillment, discharge, burning, or cancellation.

## Responsibilities at a glance

- **Issuer:** describes and fulfills the voucher and records discharge.
- **Pool Steward:** publishes and administers the Pool's rules, rates, fees, limits, controls, and any expressly assumed guarantee.
- **Holder:** reviews the issuer, voucher terms, Pool rules, quote, wallet authorization, and applicable law.
- **Technical controllers:** exercise only the contract, dependency, upgrade, catalog, or fee powers assigned to them.
- **GEF:** operates the CLC App and supporting infrastructure, subject to the [Terms of Service](/governance/terms); it does not automatically take on the other roles.

## Future credit arrangements

A future Pool or other responsible party could separately offer a transaction as a repayable advance, secured transaction, or other credit product. Such a product would require separately presented supplemental and transaction terms identifying the parties, amounts, due dates, fees or interest, collateral treatment, assignment, default, remedies, and discharge evidence.

An ordinary send, Pool deposit, Pool swap, voucher presentment, fulfillment, or discharge does not create those obligations on its own.

# History

[Grassroots Economics Foundation](https://grassrootseconomics.org/about/) (GEF) built and stewarded the historic Sarafu Network and now operates the CLC App. Its commitment-pooling work developed through years of living and learning alongside communities in Kenya that sustained mutual care through shared commitments. Long before digital systems, people made promises to one another and held them through common memory, relationships, and local accountability. The book [Grassroots Economics: Reflection and Practice](https://grassrootseconomics.org/book/) describes this as a commons of commitments: promises that can be exchanged, fulfilled, and renewed without requiring one central authority.

That work was first expressed through community currencies—local ways to record and honor obligations when national currency was scarce. The deeper lesson was not a particular currency. It was a pattern of curation, shared valuation, limits that protect a commons, and exchange that preserves reciprocity. Those lessons informed the Commitment Pooling Protocol (CPP).

## From the historic Sarafu Network to Cosmo-Local Credit

The historic Sarafu Network served as a practical learning environment for community currencies and Commitment Pools across communities, schools, clinics, farms, cooperatives, and other local organizations. GEF used that experience to explore how independently governed commitments could be connected without collapsing them into a single dominant market or removing local responsibility.

The service formerly presented as Sarafu Network transitioned to the CLC App at [cosmolocal.credit](https://cosmolocal.credit), which GEF operates. This was a transition of the public service and continuing body of work. It does not mean that every historic Sarafu account, wallet, token, voucher, pool, balance, report, participant, or obligation migrated or remains available in the current App.

Cosmo-Local Credit carries forward the history, lessons, open software, and commitment-pooling work. The current product family includes the CLC App, its documentation, and an open protocol for independently governed vouchers and Commitment Pools. Issuers remain responsible for what they promise, Pool Stewards remain responsible for their rules and any guarantees they publish, and communities and institutions can use governance arrangements suited to their circumstances.

One path, in brief:

1. Community currencies made local obligations visible when cash was scarce.
2. Commitment pooling developed curation, valuation, limitation, and exchange into reusable protocol components.
3. The historic Sarafu Network tested and refined those ideas across many real communities and organizations.
4. The service transitioned to Cosmo-Local Credit without representing that all historic users, assets, records, or obligations transferred.
5. The current App provides supported wallet, voucher, Pool, and direct-swap workflows; wider routing, clearing, liquidity, insurance, and governance mechanisms remain proposed or deployment-dependent.

Read [Concepts and vocabulary](/introduction/concepts) for the layers and status terms used across the docs. The [Terms of Service](/governance/terms) govern use of the CLC App. The [White Paper](/white-paper) presents the wider design, research, and roadmap.

## Further learning from Grassroots Economics

These organizational and educational resources provide additional background. They supplement, rather than define, current CLC App and Protocol behavior.

- [About Grassroots Economics](https://grassrootseconomics.org/about/) — its mission, team, values, and longer organizational history.
- [Research and open data](https://grassrootseconomics.org/research/) — peer-reviewed papers, working papers, datasets, reports, and academic studies.
- [Grassroots Economics: Reflection and Practice](https://grassrootseconomics.org/book/) — the book in free digital and audio formats, with printed editions also available.
- [The Grassroots Journal](https://grassrootseconomics.org/blog/) — field notes, research updates, community stories, and evolving practice.
- [Educational games](https://grassrootseconomics.org/games/) — learning resources about commitments, settlement, resource flows, exchange, and pooling.

# Protocol

Protocol v1.1.0 contracts provide the on-chain building blocks for the **Commitment Pooling Protocol (CPP)** described in [Chapter 1](/white-paper/chapter-01-commitment-pooling-protocol-cpp-the-core-primitive) of the white paper. This reference follows the public [`v1.1.0` release](https://github.com/cosmo-local-credit/protocol/tree/v1.1.0).

Use [Concepts and vocabulary](/introduction/concepts) for the product layers, accountable roles, action lifecycle, values, limits, fees, and status terms used here.

Grassroots Economics Foundation (GEF) operates the Progressive Web App at [cosmolocal.credit](https://cosmolocal.credit), which offers one way to interact with these contracts. The App and the contracts are distinct. Operating the interface does not by itself make GEF a Voucher issuer, Pool Steward, custodian, guarantor, or counterparty to a user transaction. Those roles depend on the relevant deployment, controller addresses, and published issuer or Pool terms. See the [Terms of Service](/governance/terms).


## Deployment pattern

Most stateful modules are initialized as **ERC-1967 proxy instances** through Solady's `ERC1967Factory`. Multiple instances can share an implementation while keeping separate owners, configuration, and storage. A deployment may also use deterministic salts so addresses can be predicted before deployment.

Not every contract is proxied. `DecimalQuoter` and `SwapRouter` are stateless direct deployments; `RescueVault` and `ERC1967Factory` are also deployed directly. The remaining stateful modules listed below are designed for proxy deployment.

Each proxy has an administrator that can replace its implementation. Proxy administration is separate from contract ownership and should be assigned to an appropriately governed address. An upgrade can change behavior even after a Pool has sealed configuration, so users should assess both the Pool owner and the proxy administrator.

EIP-165 support is also contract-specific, not universal. It is exposed by `GiftableToken`, the three quoters, `OracleRelay`, `Limiter`, several registries and indexes, `Splitter`, `EthFaucet`, `PeriodSimple`, and `RescueVault`. `SwapPool`, `SwapRouter`, `FeePolicy`, `ProtocolFeeController`, and `CAT` do not expose `supportsInterface` in v1.1.0.


## Component map

- **GiftableToken** — ERC20 supply, minting, burning, and optional-expiry mechanics. An issuer can use an instance as a Voucher, but the contract alone does not define what can be redeemed, by whom, where, or on what terms.
- **SwapPool** — Token vault and swap-settlement engine. A deployment can attach curation, valuation, fee, limit, and protocol-fee components or leave supported dependencies unset.
- **DecimalQuoter, RelativeQuoter, and OracleQuoter** — Interchangeable valuation modules for decimal parity, owner-managed relative rates, or oracle-derived rates. `OracleRelay` can relay one external feed for use by an `OracleQuoter`.
- **FeePolicy and Limiter** — Optional pair-fee rules and per-token Pool-balance limits.
- **ProtocolFeeController** — Optional, mutable protocol-fee rate, recipient, and active state that a Pool can consult during settlement.
- **TokenUniqueSymbolIndex, AccountsIndex, and ContractRegistry** — Token, account, and address discovery components. `CAT` records an account's ordered settlement-token preferences.
- **SwapRouter** — Quote-only exact-input and exact-output calculations over a proposed multi-Pool path. It does not custody tokens or execute swaps.
- **Splitter, EthFaucet, PeriodSimple, and RescueVault** — Supporting distribution, gas-funding, rate-limit, and asset-recovery utilities.

The contracts can be combined in different ways. A registry listing, quote, or graph path is not a guarantee that a transaction will execute: current liquidity, token limits, fees, oracle state, authorization, deadlines, network conditions, and each Pool's configuration still apply.

# Smart contracts

This page describes the main Pool and Voucher contracts in protocol v1.1.0. Contract behavior provides settlement mechanics; it does not replace the issuer disclosures, Pool rules, or other transaction terms that apply to a particular use.

Use [Concepts and vocabulary](/introduction/concepts) to distinguish the governed Commitment Pool from `SwapPool`, and swap settlement from redemption presentment, fulfillment, and discharge.


## Voucher (`GiftableToken`)

`GiftableToken` is an ERC20 token with mechanics that an issuer can use for a Voucher:

- **Authorized minting** — The owner can designate writers that may issue tokens with `mintTo`.
- **Optional expiry** — An expiry of `0` means no contract-level expiry. Otherwise, transfers, minting, and burning revert at or after the configured timestamp. Anyone can persist the terminal `expired` state by calling `applyExpiry` directly.
- **Supply accounting** — `totalMinted` and `totalBurned` expose cumulative supply activity. The owner-only `burn` function burns tokens held by the owner address.

The token contract does **not** identify the issuer's goods or services, set a redemption value, prove capacity, or promise cash conversion. A `GiftableToken` becomes a redeemable commitment only through the issuer's separately published terms and conduct. Issuers remain responsible for accurately describing and honoring those terms.


## Commitment Pool (`SwapPool`)

`SwapPool` is a token vault and swap-settlement engine. Although it exposes ERC20 metadata for the Pool name, symbol, and decimals, the v1.1.0 contract does not mint Pool-share tokens. Liquidity is supplied by transferring tokens into the Pool, and the contract owner can withdraw available liquidity.

### Composition and optional dependencies

| Configuration | When unset | Sealable address slot |
| --- | --- | --- |
| `tokenRegistry` | Any token can pass the Pool's curation check | Yes |
| `tokenLimiter` | Deposits have no contract-level balance cap | Yes |
| `quoter` | The raw input amount is treated as the raw quoted output amount | Yes |
| `feePolicy` | The Pool fee is zero | Yes |
| `feeAddress` | Pool fees are not accrued as withdrawable fees for a designated recipient | Yes |
| `protocolFeeController` | No protocol fee is charged | No |

The five seal bits permanently lock the current `feePolicy`, `feeAddress`, `quoter`, `tokenRegistry`, and `tokenLimiter` addresses against their corresponding setters. `protocolFeeController` and `feesDecoupled` are initialization values and are not among those five bits.

Sealing an address slot does not freeze the contract at that address. A sealed registry, limiter, quoter, or fee policy—and a configured protocol-fee controller—can still change if its own governance permits it. The ERC-1967 proxy administrator can also upgrade the Pool implementation. A meaningful immutability claim therefore depends on the governance of the Pool owner, proxy administrator, and every configured dependency.

### Swap settlement

For a swap, `SwapPool`:

1. Checks that input and output tokens pass the optional registry and tests the requested input against the optional Pool-balance limit.
2. Pulls the input token from the caller and measures the amount actually received. Pricing uses this measured amount, including for fee-on-transfer tokens.
3. Obtains a gross quote from the configured quoter, or uses the raw received amount when no quoter is set.
4. Calculates the Pool fee and any additional protocol fee, then checks available output-token liquidity.
5. Sends the protocol fee directly to the configured protocol recipient, transfers the nominal net output to the recipient, and records the Pool fee when a fee address is configured.
6. Emits the legacy `Swap` event and the more detailed `SwapSettlement` event.

`SwapSettlement` records the initiator, both tokens, measured input, gross quoted output, nominal output sent, output actually observed at the recipient, Pool fee, and protocol fee. The nominal and observed outputs can differ when the output token itself charges a transfer fee. The `fee` field in the legacy `Swap` event is only the Pool fee.

The six-argument `withdraw(tokenOut, tokenIn, value, recipient, minAmountOut, deadline)` overload is the bounded execution path. It reverts after the deadline or when the recipient's observed balance increase is below `minAmountOut`. Integrators should prefer it because a displayed quote is temporary: quoter state, fee policy, liquidity, limits, and oracle data may change before execution. The older three- and four-argument overloads do not provide those Pool-level bounds.

### Additive fee calculation

Pool and protocol fees are both deducted from the gross quoted output. The protocol fee is **not carved out of the Pool fee**, and the Pool retains its full calculated fee.

For example, on a gross quote of 100 units:

- a 2% Pool fee accrues 2 units to the Pool;
- a 10% protocol rate applied to that Pool fee sends another 0.2 units directly to the protocol recipient; and
- the user receives 97.8 units.

The protocol calculation uses the greater of the calculated Pool fee and an assumed 1% fee base. This prevents a very small Pool fee from reducing the protocol calculation to nearly zero. Invalid combined rates revert with `FeeTooHigh`, and a quote that would settle at zero reverts with `InsufficientOutput`.

### Owner and upgrade powers

The contract owner can collect accrued Pool fees and can call `withdrawLiquidity` to transfer any available Pool token to a chosen non-zero address. When fees are decoupled, accrued fees are reserved from this liquidity-withdrawal path; otherwise they remain part of the Pool balance. Pool participants should not interpret deposited liquidity as permanently locked unless additional, verifiable governance controls establish that result.

Configuration sealing does not remove this liquidity-withdrawal power. It also does not remove the separate ERC-1967 proxy administrator's upgrade power.


## Valuation modules

All three quoters implement forward and reverse quote functions used by `SwapPool` and `SwapRouter`:

- **`DecimalQuoter`** — Stateless decimal normalization under a 1:1 value-parity assumption.
- **`RelativeQuoter`** — Decimal normalization plus owner-managed relative price indexes. An unset token index defaults to parity.
- **`OracleQuoter`** — Rates each token through a configured oracle, with a global or per-token staleness limit and an optional 0.9-to-1.0 output multiplier.

An `OracleQuoter` is only as reliable as its feed selection and administration. Feed denomination and direction must be consistent, decimals must be correct, updates must be positive and fresh, and governance can replace feeds or change freshness settings. Source manipulation, delayed updates, network outages, incorrect pair configuration, or loss of the oracle-owner key can cause bad quotes or make swaps revert.

`OracleRelay` is an optional single-feed, latest-round relay compatible with the oracle interface. A designated writer republishes source values; there is no cross-chain proof and no stored round history. The relay accepts the writer's values with only a future-timestamp check. `OracleQuoter` independently rejects non-positive or stale answers, while the relay owner can rotate the writer or invalidate the current round. Users must therefore assess the source feed, relay writer, relay owner, and monitoring process.


## Fee policy and limits

`FeePolicy` stores a default fee in parts per million and optional directional pair overrides. Its owner can change those rates unless governance outside the contract restricts that power.

`Limiter` stores a maximum balance for a token at a particular Pool address. The owner or an authorized writer can change that limit. A zero limit blocks deposits when the limiter is active; an unset limiter leaves deposits uncapped.

These limits describe configured **token exposure** at a Pool. They do not, by themselves, classify a token balance as a loan or legal debt, prove an issuer's capacity, or guarantee fulfillment. Those questions depend on issuer terms, Pool rules, the transaction presented to the user, and applicable law.


## Protocol fee controller

`ProtocolFeeController` is an optional deployment-level fee component. Its owner can change the protocol rate and recipient or deactivate the fee. A single controller can be shared by multiple Pools, but the protocol does not require one controller per network.

When active and configured, the recipient is paid directly in the output token during each successful swap. How that recipient uses the funds—for example for operations, monitoring, liquidity support, or another published purpose—is a governance matter, not a guarantee made by the contract.

import { MermaidDiagram } from '../../components/MermaidDiagram'

# Protocol network architecture

A CPP-compatible deployment can connect many Vouchers and Pools through optional registries, indexes, quote modules, and application-level route discovery. Each Pool remains a separate vault with its own liquidity, owner, proxy administrator, configuration, and dependencies.

Grassroots Economics Foundation operates the public App at [cosmolocal.credit](https://cosmolocal.credit). Other interfaces and deployments can use the same public protocol. Operating the App does not automatically make GEF the owner, issuer, Steward, fee recipient, or guarantor for every contract shown below.

See [Concepts and vocabulary](/introduction/concepts) for the separation between accountable roles and technical powers.


## Candidate routes and execution

<MermaidDiagram
  label="Candidate route discovery and wallet-batch execution"
  minWidth={1040}
  chart={`flowchart TB
    VoucherA["Voucher A"] ---|listed and held| PoolA["Pool A"]
    Bridge["Generic bridge asset"] ---|listed and held| PoolA
    Bridge ---|listed and held| PoolB["Pool B"]
    VoucherB["Voucher B"] ---|listed and held| PoolB

    App["PWA or route finder"] -. discovers candidates .-> Index["Registries and indexes"]
    App -. requests a quote .-> Router["SwapRouter: quote only"]
    Router -. reads Pool quotes .-> PoolA
    Router -. reads Pool quotes .-> PoolB

    App -->|builds ordered calls| WalletStart["User smart-account wallet"]
    WalletStart -->|hop 1: Voucher A| PoolA
    PoolA -->|bridge output| WalletBridge["Same wallet between calls"]
    WalletBridge -->|hop 2: bridge asset| PoolB
    PoolB -->|Voucher B output| WalletFinal["Same user wallet"]

    PoolA -->|protocol fee| ProtocolRecipient["Configured protocol recipient"]
    PoolB -->|protocol fee| ProtocolRecipient`}
/>

A shared asset creates a **possible graph path**, not a guaranteed route. In this example, Voucher A could be exchanged for the bridge asset in Pool A, then the bridge asset could be exchanged for Voucher B in Pool B. Every hop still depends on current token admission, Pool limits, available inventory, quote and fee configuration, oracle state, approvals, transaction bounds, and network execution.

`SwapRouter` only calls Pool quote functions across a proposed path. It does not hold funds, approve tokens, or execute swaps. An integrator or compatible app can use those quote results to construct ordered approval and Pool calls in a signed smart-account batch; this does not mean that the current public App offers multi-hop execution. Each hop settles to the Wallet before that Wallet supplies the intermediate asset to the next Pool, and the integrator can configure the batch to revert when a call fails.

Quotes are snapshots. A successful route quote can still fail or settle differently if relevant state changes before execution. The bounded `SwapPool.withdraw` overload adds `minAmountOut` and `deadline` protection for an individual hop; integrators must decide how to apply bounds across the full route.

Pool fees remain with the relevant Pool for later collection. Any protocol fee is additional and is transferred directly from that Pool to its configured protocol recipient during the swap.


## Pool internals

<MermaidDiagram
  label="Commitment Pool dependencies and administrative powers"
  minWidth={820}
  chart={`flowchart TB
    Owner["Contract owner or<br/>Pool Steward"] -->|configure, seal, collect, withdraw| Pool["SwapPool<br/>vault and settlement"]
    ProxyAdmin["ERC-1967<br/>proxy administrator"] -->|upgrade implementation| Pool
    Dependencies["Optional dependencies<br/>registry · limiter · quoter<br/>fee policy · protocol fee controller<br/>each with its own governance"] -. settlement inputs .-> Pool
    Seal["Five sealable address slots<br/>feePolicy · feeAddress · quoter<br/>tokenRegistry · tokenLimiter"] -. locks addresses .-> Pool

    Wallet["User wallet"] -->|deposit or swap input| Pool
    Pool -->|net swap output| Wallet
    Pool -->|collected Pool fees| FeeAddress["Configured<br/>fee address"]
    Pool -->|protocol fee in same swap| ProtocolRecipient["Protocol<br/>recipient"]
    Pool -->|withdrawLiquidity| Destination["Owner-selected<br/>recipient"]`}
/>

The registry, limiter, quoter, fee policy, and protocol-fee controller are optional. With no registry, any token passes the admission check; with no limiter, deposits are uncapped; with no quoter, the Pool uses raw-unit parity; and with no fee modules, the corresponding fees are zero.

The five sealable slots are `feePolicy`, `feeAddress`, `quoter`, `tokenRegistry`, and `tokenLimiter`. A seal prevents the current Pool owner from replacing that address through its setter, but it does not freeze the dependency's internal state. The `protocolFeeController` address and `feesDecoupled` mode are not covered by those five seal bits. The proxy administrator's ability to upgrade the Pool is also separate from sealing.

The contract owner can withdraw available Pool liquidity to a chosen address. In decoupled-fee mode, accrued fees are reserved from that path; the power to withdraw the remaining liquidity still exists. Participants should inspect the owner, proxy administrator, dependency controllers, seal state, fee recipients, and published Pool rules before relying on a Pool.

For the conceptual design behind these contracts—including curation, valuation, limitation, exchange, and governance—see the [White Paper](/white-paper).

# Governance mechanics

Governance in Cosmo-Local Credit (CLC) is divided among distinct roles rather than assigned to one universal authority. This page describes governance options for CLC-compatible networks; it does not prescribe a single legal form, voting system, or organization.

Grassroots Economics Foundation (GEF) operates the public progressive web app at `cosmolocal.credit` and its supporting services. In that role, GEF may maintain interfaces and catalogs, apply minimum listing or safety standards, moderate content, restrict App features, and coordinate technical operations. Unless it expressly accepts another role for a particular arrangement, GEF is not the Issuer of a user-created Voucher, the Steward of a user-created Pool, a guarantor, insurer, custodian, lender, borrower, redeemer, or party to a user-to-user transaction.

The [Terms of Service](/governance/terms) govern use of the public App and explain these responsibilities in detail.

[Concepts and vocabulary](/introduction/concepts) maps these public roles to contract ownership, proxy administration, dependency control, catalog moderation, and fee receipt.

## Responsibility by role

- **Voucher Issuers** govern their own Offerings. They publish accurate identity, capacity, supply, valuation, expiry, presentment, fulfillment, geographic, timing, fee, restriction, and remedy information, and they remain responsible for honoring those commitments.
- **Pool Stewards** govern admission, asset curation, valuation, fees, limits, inventory, reserves, contributions, conflicts, provenance, configuration, pauses, upgrades, and any guarantee or loss-allocation mechanism for their Pools.
- **Registry and service stewards** may govern which Pools or assets appear in a registry and the rules and fees for routing, monitoring, liquidity support, or other shared services.
- **Users** decide whether an Issuer, Voucher, Pool, quote, and transaction are acceptable and lawful for them. A registry entry or App listing is not a guarantee or endorsement.

One person or organization can hold more than one role, but it should disclose each role and the conflicts and obligations that follow from it.

## Accountable governance structures

A CLC-compatible Pool, registry, or service can be governed by a nonprofit foundation, cooperative, community group, federation, company, multisig, public agency, institutional board, on-chain voting system, or another accountable structure. Whatever structure is chosen, participants should be able to determine:

- who has authority to make and execute decisions;
- how assets, Issuers, and participants are admitted, reviewed, suspended, or removed;
- how valuations, fees, limits, reserves, guarantees, and other material settings are established and changed;
- which dependencies or contracts can be upgraded, replaced, paused, or permanently sealed;
- how conflicts of interest are disclosed and handled;
- what records, notices, approvals, and review periods apply;
- what emergency powers exist and how their use is reviewed; and
- how participants can complain, exit, migrate, or address unresolved obligations.

Published rules should match the powers available in the relevant contracts and services. Governance should keep material decisions transparent and auditable and should not describe convertibility, liquidity, returns, insurance, reserves, or guarantees more broadly than the responsible party can actually provide.

## Technical governance options

Where token voting is appropriate, a deployment may use [OpenZeppelin Governor](https://docs.openzeppelin.com/contracts/4.x/api/governance) contracts and an interface such as Tally. Other deployments may rely on multisig approvals, cooperative resolutions, board decisions, public-agency mandates, or hybrid processes.

These tools are optional. Discussion of token voting, shared insurance, network-wide routing, netting, or liquidity programs does not mean that every capability is active in the public App or governed by GEF. Each deployment must identify its actual decision-makers, contracts, service providers, and policies.

## Interface action and on-chain state

An App operator or registry steward may hide, flag, suspend, or remove an item from an interface. That action does not necessarily pause a smart contract, reverse a completed transaction, remove a public-blockchain record, eliminate a balance, or discharge an obligation between users. Governance plans should distinguish interface controls from the authorities that exist on-chain and from legal duties that continue off-chain.

For the broader design, see the White Paper's [Governance Mechanics chapter](/white-paper/chapter-11-governance-mechanics).

# Cosmo-Local Credit Terms of Service

**Version 1.1**

**Publication date: 1 October 2026**

**Effective date: 1 October 2026**

These Terms of Service (the **Terms**) are a binding agreement between you and Grassroots Economics Foundation (**GEF**, **we**, **us**, or **our**) concerning your access to and use of the Cosmo-Local Credit progressive web application made available at `cosmolocal.credit` and the related services that GEF operates (together, the **App**).

These Terms apply to every person or organization that creates or uses an Account, holds or uses a Token or Voucher through the App, creates or operates a Pool, contributes assets to a Pool, or carries out a Swap. Read them carefully before accepting them or using the App.

## Important notices

1. **Users make commitments to one another.** An Issuer is responsible for its Voucher and a Steward is responsible for its Pool rules and any guarantee it advertises. GEF does not automatically guarantee either one.
2. **No value, cash-out, liquidity, or redemption is guaranteed by GEF.** A Token, Voucher, Pool position, or other digital asset may lose value, become illiquid, be impossible to redeem, or be unavailable in a particular jurisdiction.
3. **Blockchain activity carries permanent risks.** Transactions may be public, irreversible, technically defective, delayed, rejected, or lost. GEF may be unable to recover credentials or assets, reverse a transaction, or remove a public record.
4. **No current App action is automatically a loan.** Any future loan or credit product requires separately presented supplemental and transaction terms; these Terms do not create one.
5. **You are responsible for legality in your jurisdiction.** You must determine whether your use, Token, Voucher, Pool, Swap, offering, or other activity is lawful and what registrations, permits, approvals, disclosures, taxes, and safeguards are required.

These notices summarize important points but do not replace the rest of the Terms.

## 1. Definitions

In these Terms:

- **Account** means a user profile, authenticated session, and related access to App features. An Account may be associated with one or more Wallet credentials and a public blockchain address.
- **Content** means information submitted, created, or published through the App, including names, images, descriptions, posts, locations, contact details, Voucher terms, Pool rules, and offering information.
- **Discharge** means the record or action that prevents fulfilled Voucher units from being presented or used again, such as receiving, burning, cancelling, or otherwise disabling them under the applicable terms.
- **Fulfillment** means the Issuer providing the goods, services, benefits, performance, or other value promised by the Voucher terms.
- **Holder** means a person or organization that lawfully controls a Token or Voucher. Control does not itself prove beneficial ownership, issuer fulfillment, cash value, or a guarantee.
- **Issuer** means the person or organization that creates, issues, mints, or is identified as responsible for a Token or Voucher and its associated commitments.
- **Offering** means an App catalog record describing goods or services associated with a Voucher. Publishing an Offering does not mint a Token, prove availability, or establish Fulfillment.
- **Pool** means a smart-contract arrangement or other coordinated system that curates Tokens or Vouchers, holds or accounts for digital-asset inventory, applies valuations, limits or fees, and enables Swaps or other transactions.
- **Pool Contribution** means a transfer of assets into a Pool under separately disclosed terms. It does not automatically create a Pool share, repayment claim, withdrawal right, reward, or governance right.
- **Pool Fee** means a fee charged under a Pool's published rules and configuration.
- **Pool Quote** means a transaction estimate produced by a Pool's configured valuation method. It is not automatically the Offering price, Voucher stated value, redemption value, or cash value.
- **Protocol Fee** means a separate fee, if configured, paid to the disclosed protocol-fee recipient in addition to a Pool Fee.
- **Steward** means the person, organization, group, governance body, or authorized controller responsible for creating, administering, or publishing the rules of a Pool.
- **Technical Controller** means a contract owner, proxy administrator, dependency owner or writer, catalog moderator, fee recipient, or other person with a stated technical power. Technical control does not by itself transfer every Issuer or Steward responsibility.
- **Swap** means an exchange of one supported asset for another through one or more Pools. A Pool contribution or deposit, Pool liquidity withdrawal, fee collection, provider transaction, or cash on-ramp or off-ramp is not a Swap unless it also performs that asset exchange.
- **Token** means a digital token, record, balance, or other digital asset accessible through the App. A Token is not necessarily a Voucher and its legal character depends on its features, representations, use, and applicable law.
- **Transaction Terms** means the parameters and specific rules presented or made available for a transaction, such as the assets, amounts, Pool, route, exchange-rate method, fees, limits, deadline, provider terms, or redemption conditions.
- **Redemption Presentment** means a Holder returning or presenting Voucher units to the Issuer through the stated redemption process. Presentment does not by itself prove Fulfillment or Discharge.
- **Service Fee** means a separately disclosed fee for routing, interface, provider, payment, monitoring, or another identified service.
- **User** or **you** means the individual who accepts these Terms and any organization that individual validly represents.
- **Voucher** means a Token or record that an Issuer represents as a commitment, prepaid claim, or right to receive specified goods, services, benefits, performance, or other value under published redemption terms.
- **Wallet** means the blockchain account, address, signing credentials, passkey, paper-wallet key, smart account, or related mechanism used to authorize transactions.

## 2. Acceptance and scope

The current App does not record an affirmative acceptance of these Terms during Account creation. To the extent applicable law permits, you accept these Terms by creating or using an Account or by continuing to use the App after a notified update takes effect. Where applicable law requires affirmative acceptance or reacceptance, GEF will present an acceptance control before allowing continued use of the affected Account features. Merely viewing these Terms without creating or using an Account does not by itself create an agreement.

If you do not agree, do not create an Account or use the App. If you are accepting for an organization, you represent that you have authority to bind it. In that case, **you** includes both you and the organization where the context permits.

These Terms govern the relationship between you and GEF concerning the App. Pool rules, Voucher terms, and Transaction Terms may create separate obligations between Users. They supplement these Terms for the relevant user-to-user transaction but do not make GEF a party to that transaction, waive protections owed to GEF, or override mandatory law. If Transaction Terms conflict with these Terms, the Transaction Terms control only the specific user-to-user transaction and these Terms continue to govern your use of the App and relationship with GEF.

No later version of these Terms retroactively changes a completed transaction or the agreed economics of a transaction already confirmed.

## 3. Eligibility and authority

You may use the App only if:

- you are at least 18 years old and have reached the age of legal majority in every jurisdiction applicable to you;
- you have legal capacity to enter contracts and perform the obligations you undertake;
- you are not prohibited from using the App by sanctions, court order, regulatory restriction, or other applicable law;
- the information you provide is truthful, current, and complete; and
- if acting for another person or organization, you have continuing authority to do so.

You must stop using the App if you cease to meet these conditions. GEF may request information reasonably necessary to verify eligibility, authority, identity, risk, or compliance and may restrict features where verification is incomplete.

## 4. Accounts, Wallets, and security

You are responsible for your Account, Wallet, devices, passkeys, paper-wallet materials, private keys, recovery information, and all activity authorized through them. You must use reasonable security, protect credentials from disclosure, maintain any backups you need, and promptly notify GEF at `info@grassecon.org` if you suspect unauthorized Account access or misuse of an App-operated service.

The App may help create or connect a Wallet, register a passkey, prepare a transaction, obtain a signature or authorization, and submit a transaction through a relayer or network provider. Those functions do not eliminate your responsibility for the authorization you give. You must inspect transaction details before confirming them.

GEF does not promise that a lost credential, Wallet, Token, Voucher, or transaction can be recovered, replaced, frozen, cancelled, or reversed. A Wallet transaction validly authorized with your credentials may be treated as your instruction unless applicable law or reliable evidence establishes otherwise. A blockchain record is relevant evidence, but it is not necessarily conclusive in cases of fraud, compromise, system error, or a binding legal order.

Your Account is personal to you and may not be sold, transferred, rented, or shared in a way that misrepresents who controls it. Signing out, uninstalling the App, or closing an App profile does not revoke completed blockchain transactions or automatically remove public records, smart contracts, balances, or obligations to other Users.

## 5. GEF's role and limitations

GEF operates the App interface and may operate supporting catalogs, application programming interfaces, storage, relayers, indexing, notifications, moderation, and transaction-submission services. GEF may also help Users discover Tokens, Vouchers, Pools, and other Users.

Unless GEF expressly identifies itself in writing as acting in another capacity for a particular transaction, GEF is not:

- the Issuer of a User-created Token or Voucher;
- the Steward of a User-created Pool;
- a party to a Swap or other user-to-user transaction;
- a lender, borrower, broker, dealer, exchange, bank, money transmitter, insurer, fiduciary, investment manager, escrow agent, or financial adviser;
- the seller, producer, inspector, carrier, or redeemer of an underlying good or service; or
- a guarantor of any User, Token, Voucher, Pool, transaction, obligation, reserve, collateral, price, or outcome.

A Pool smart contract may hold digital assets under its programmed rules. That fact does not by itself mean that GEF owns those assets, owes their value, or can recover them. Similarly, a relayer may broadcast an authorized transaction without becoming the owner or custodian of the assets involved.

Listing, displaying, indexing, reviewing, verifying, or declining to remove an Account, Token, Voucher, Pool, Content item, or transaction does not constitute GEF's endorsement, certification, valuation, legal classification, or promise of quality. Where GEF expressly acts as an Issuer, Steward, or counterparty, it is subject to the same applicable duties these Terms place on other Users in that role.

## 6. Your legal and regulatory responsibility

The App may be accessible across many jurisdictions with different rules. You are solely responsible for obtaining competent advice and determining the laws that apply to your activity, including laws concerning consumer protection, credit, lending, payments, money transmission, banking, e-money, digital assets, securities, commodities, fundraising, charities, employment, wages, taxation, sanctions, anti-money-laundering controls, product safety, trade, privacy, intellectual property, cultural heritage, and electronic transactions.

GEF does not represent that any Token, Voucher, Pool, Swap, Pool Contribution, future credit product, or other arrangement has a particular legal, accounting, regulatory, or tax classification. Labels used by a User or within the App do not override applicable law.

You must obtain and maintain every registration, permit, approval, disclosure, consent, record, and safeguard required for your activities. You must not use these Terms or the availability of an App feature as evidence that GEF or any authority has approved your activity.

GEF may restrict, pause, geofence, condition, or refuse access to an Account, asset, route, or feature to address legal, regulatory, sanctions, fraud, safety, or operational risk. This section does not transfer to you any legal duty that applicable law places directly on GEF.

## 7. Tokens and Vouchers generally

Tokens and Vouchers are created and used by different parties for different purposes. Their value and legal effect depend on their terms and circumstances. Unless expressly stated in binding Transaction Terms by the responsible party:

- they are not deposits with GEF;
- they carry no promise by GEF of interest, profit, principal protection, exchange-rate stability, resale, liquidity, cash conversion, or redemption;
- acceptance by any User is voluntary; and
- availability in the App does not establish a market value or legal classification.

A transfer may be described as a gift or a contribution only when that treatment is clearly disclosed and lawful. These Terms do not convert every Token or Voucher transfer into a gift and do not remove an Issuer's published redemption obligations.

## 8. Creating or issuing a Token or Voucher

By creating, issuing, minting, distributing, or publishing a Token or Voucher through the App, you represent and agree that:

1. **Authority.** You have authority over the Token or Voucher, the underlying offering, the Content you publish, and every right or commitment you purport to grant.
2. **Lawfulness and safety.** The offering and its issuance, transfer, marketing, and redemption are lawful and reasonably safe in every jurisdiction where you make them available.
3. **Accurate identity.** You clearly identify the responsible Issuer and provide accurate, usable contact and dispute information.
4. **Complete disclosure.** Before distribution, you clearly state the offering; supply or issuance policy; unit of account and valuation method; material provenance or origin; quality and quantity; capacity or backing; geographic and time limits; accepted venues; expiry; fees, taxes, or charges; transfer restrictions; redemption process; expected performance time; evidence required; remedies; and every other fact material to a recipient's decision.
5. **Capacity.** You do not issue more than you can reasonably expect to honor under the published terms, and you promptly disclose a material reduction in capacity.
6. **Ongoing transparency.** You keep information current, preserve an intelligible record of material changes, and do not conceal a change behind an unchanged name, symbol, image, or listing.
7. **Defined recipient rights.** You state what a recipient may and may not do with the underlying offering, information, documentation, derivatives, or redistribution. No permission to copy, adapt, reproduce, or redistribute is implied beyond your published terms and applicable law.
8. **No misleading claims.** You do not describe a Token or Voucher as guaranteed, cash-equivalent, fully backed, insured, risk-free, or redeemable unless the statement is accurate, supportable, and accompanied by all material conditions.

You must not retroactively reduce the rights attached to an outstanding Voucher unless the terms accepted before acquisition clearly permit the change, the affected Holder gives any consent required by law, and the change is otherwise lawful. Where an on-chain field cannot be updated, you must make any permitted correction or change conspicuous in the current off-chain listing and preserve the prior record where reasonably necessary.

## 9. Redemption presentment, fulfillment, and discharge

In the current App, the UI label **“Redeem”** prepares an ordinary Token transfer to the Token owner as Redemption Presentment. That transfer does not by itself prove Fulfillment or Discharge.

An Issuer, not GEF, is responsible for fulfilling its Voucher according to the terms published when the Holder acquired it and any valid later agreement. Subject to disclosed lawful conditions, the Issuer must:

- accept a properly presented Voucher for the stated goods, services, benefits, performance, or other value;
- provide the promised quality and quantity within the stated period;
- not refuse, unreasonably delay, or apply an undisclosed discount merely because the Voucher was transferred or passed through a Pool;
- provide a practical process for presentment, verification, delivery, complaints, and remedies; and
- record completed Fulfillment and Discharge by receiving, burning, cancelling, or otherwise disabling the fulfilled Voucher units where necessary to prevent reuse.

An Issuer may apply restrictions based on legality, safety, location, capacity, scheduling, expiry, identity, or other conditions only if they are lawful and were clearly disclosed before acquisition, except where a later restriction is required by law or necessary to prevent imminent harm.

A Holder must read the Voucher terms, assess the Issuer and offering, follow the stated redemption process, provide lawful evidence of control, inspect delivered goods or services where appropriate, and avoid presenting the same Voucher more than once. Acquiring a Voucher does not make GEF responsible for the Issuer's performance.

If a recipient modifies, repackages, or redistributes an offering where the Issuer's terms permit it, that recipient must accurately identify material changes, preserve required provenance and source acknowledgments, pass on applicable conditions, and avoid implying that the original Issuer or GEF approved the modified offering.

The App label **“Retire voucher”** means reversible catalog unlisting. It does not burn or cancel balances, complete Fulfillment or Discharge, or extinguish the Issuer's outstanding commitments.

## 10. Creating and operating a Pool

A Steward is responsible for the design, administration, representations, and lawful operation of its Pool. Before accepting assets or enabling participation, the Steward must publish clear and accessible Pool rules that address, as applicable:

- the Pool's purpose, operating model, identity, contact details, and accountable decision-makers;
- admission, verification, participation, and exit rules;
- accepted Tokens, Vouchers, Issuers, and routes, including the process for adding, suspending, or removing them;
- valuation methods, units of account, price sources, oracle dependencies, update authority, and treatment of valuation errors;
- default and pair-specific fees, fee recipients, network or service charges, and when fees may change;
- deposit, withdrawal, Swap, exposure, concentration, time, and other limits;
- available inventory, reserves, liquidity, collateral, and the circumstances in which assets may be unavailable;
- every guarantee, reserve, guarantor, insurance arrangement, redemption support, or loss-allocation rule, and the exact limits of each;
- governance procedures, conflicts of interest, emergency powers, pause authority, upgrade authority, sealed or immutable settings, and notice of changes;
- the rights attached to a contribution, deposit, liquidity position, gift, or endowment and whether withdrawal or repayment is available;
- recordkeeping, asset provenance, transaction evidence, reporting, complaints, default, enforcement, and dispute procedures; and
- termination, migration, and treatment of remaining obligations.

The Steward must keep these disclosures accurate, enforce them consistently, document material decisions and transactions, and honor every guarantee it advertises. Where a Pool connects or routes to another Pool, the Steward must respect the other Pool's disclosed governance, limits, and trust boundaries and must disclose material additional dependencies.

A Steward must not use a Pool to make deceptive return claims, disguise unlawful financial services, evade wage or employment protections, manipulate prices or activity, conceal the source or use of assets, enable prohibited conduct, or promise public cash-out, convertibility, liquidity, or loss protection that it cannot deliver.

GEF may set minimum listing, safety, disclosure, or technical standards and may decline, suspend, flag, or remove a Pool from an App-operated registry. Registry status is conditional and is not a GEF guarantee.

The Steward, Pool owner, proxy administrator, dependency controllers, catalog moderator, and fee recipients may be different parties. Pool disclosures must identify each material authority. A Technical Controller's power does not by itself make that party the Steward or transfer the Steward's obligations.

## 11. Using or contributing to a Pool

Before using or contributing to a Pool, you must assess its Steward, rules, contracts, accepted assets, valuations, fees, limits, inventory, reserves, governance, upgrade powers, guarantees, and legal status. You accept the risk that:

- an Issuer may reject a valid Redemption Presentment or fail to provide Fulfillment;
- a Steward, administrator, oracle, guarantor, or other dependency may fail or act improperly;
- prices, reference values, fees, limits, routes, or future availability may change where the governing rules permit;
- a setting may become immutable or may remain changeable by an administrator;
- reserves or inventory may be insufficient;
- a Pool or route may pause, reject, revert, become inaccessible, or cease operation; and
- a smart contract may contain defects or behave unexpectedly.

A contribution is an irrevocable gift or endowment, with no ownership, profit, interest, governance, repayment, or withdrawal right, only when it is expressly presented and accepted on that basis. Otherwise, the contributor's rights are determined by the disclosed Pool and Transaction Terms and applicable law.

## 12. Swaps, quotes, fees, and routing

A quote is an estimate based on conditions at a particular time, not a guarantee of execution or future value. Before confirming a Swap, you must review the assets, amounts, Pool or route, valuation, fees, limits, expiry or deadline, and other Transaction Terms made available to you.

By confirming a Swap and authorizing the related Wallet transaction, you instruct the relevant contracts and service providers to attempt the transaction on those parameters. The quote may need to be refreshed. A Swap may fail, revert, expire, execute only after delay, or become unavailable because of inventory, limits, price movement, fees, network conditions, contract state, routing, authorization, or legal restrictions.

A routed Swap may interact with multiple Pools, contracts, or providers. Each additional component introduces its own rules and risks. GEF does not promise the availability, best price, accuracy, completion, reversibility, or legal character of a Swap.

The direction of assets does not by itself decide the transaction's legal character. For example, receiving a stablecoin in exchange for a Voucher is not automatically a loan, and delivering a stablecoin in exchange for a Voucher is not automatically repayment. The express Transaction Terms, Pool rules, parties' conduct, and applicable law control.

## 13. Future credit or loan products

The current App Terms do not create or govern a loan product. An ordinary Send, Pool Contribution, Pool deposit, Pool Swap, Pool liquidity withdrawal, fee collection, provider transaction, Redemption Presentment, Fulfillment, or Discharge is not automatically a loan, advance, repayment, security interest, or credit facility.

Any future loan, repayable advance, secured transaction, or other credit product must be separately identified before a User enters it and must be governed by counsel-approved supplemental terms and transaction-specific terms. Those terms must identify the parties and every material feature required by applicable law, including amounts, due dates, fees or interest, collateral treatment, assignment, default, remedies, disclosures, consent, and evidence of repayment or discharge. No such product is offered merely because this section describes that requirement.

## 14. Fees, taxes, and third-party payment services

You are responsible for reviewing and paying the fees and charges disclosed for an App service, Pool, transaction, network, relayer, or third-party provider. Fees may be deducted from transferred amounts or paid separately as disclosed. A completed or irreversibly submitted transaction is non-refundable except where the applicable terms or law require otherwise.

Pool Fees, Protocol Fees, Service Fees, blockchain network fees, and third-party provider charges are distinct. Before authorization, the responsible party must disclose the fee type, calculation basis, amount or rate, payer, recipient, timing, refund treatment, and material conditions. A current Protocol Fee may be additional to a Pool Fee; it is not the proposed network-rake model discussed in the White Paper.

You are solely responsible for identifying, reporting, withholding, collecting, and paying taxes, duties, levies, and assessments arising from your activity. GEF does not calculate or pay your taxes and does not provide tax advice.

The App may make available services operated by third parties for stablecoins, fiat payments, on-ramps, off-ramps, identity checks, communications, mapping, storage, or other functions. Those providers may impose separate terms, eligibility rules, fees, and data practices. Unless expressly stated, GEF does not custody fiat, operate third-party payment rails, or guarantee a conversion, payout, exchange rate, provider, or regulatory outcome.

## 15. Prohibited conduct

You must not use the App, an Account, Token, Voucher, Pool, Swap, Content, or related service to:

- violate law, sanctions, a court order, or another person's rights;
- commit fraud, theft, bribery, corruption, money laundering, terrorist financing, tax evasion, or deceptive fundraising;
- create or use counterfeit, unauthorized, falsely backed, or double-pledged assets or claims;
- misrepresent identity, authority, ownership, provenance, supply, value, redemption, reserves, liquidity, guarantees, activity, or transaction purpose;
- manipulate prices, volumes, ratings, routes, governance, or other measurements;
- offer or facilitate unlawful weapons, drugs, trafficking, exploitation, sexual services, explicit material, controlled goods, or unsafe products;
- evade consumer, borrower, wage, employment, charity, financial-services, or data-protection obligations;
- impersonate, harass, threaten, discriminate against, exploit, or expose the private information of another person;
- infringe intellectual property, privacy, publicity, confidentiality, cultural heritage, traditional knowledge, or community rights;
- introduce malware, steal credentials, probe or bypass security, disrupt infrastructure, overload a service, scrape without authorization, or interfere with another User;
- spam, send unsolicited promotions, or use contact information for an undisclosed purpose;
- conceal a material conflict of interest or misuse non-public information; or
- help another person do any of the above.

GEF may investigate suspected violations, preserve relevant records, restrict features, and cooperate with lawful requests from authorities. GEF is not required to adjudicate every user-to-user allegation and may take proportionate precautionary action while a risk is assessed.

## 16. Content and public listings

You retain any rights you hold in your Content. For Content that you intentionally submit for public display or publication, you authorize GEF, its contractors, and service providers to host, store, reproduce, format, translate, display, transmit, and distribute it worldwide without a royalty, solely as reasonably necessary to operate, secure, improve, and explain the App and to display or promote the offering or public listing for which you submitted it. This authorization continues for public records, transaction evidence, reasonable backups, and material already shared with others, even after you remove Content or close an Account.

This public-Content authorization does not apply to private Account, support, complaint, security, or compliance information. GEF may process that information only as described in Section 17 and applicable law. GEF will obtain any separate permission required by law before using identifiable Content to advertise GEF beyond displaying or promoting the public listing for which you supplied it.

You represent that you have authority to submit the Content and grant this authorization. You must respect privacy and obtain any consent needed before publishing another person's information, image, location, contact details, traditional knowledge, or community information.

GEF may edit formatting, translate Content, add risk notices, restrict visibility, or remove Content that violates these Terms or creates legal, safety, fraud, technical, or reputational risk. GEF is not responsible for copies retained by other Users, public networks, archives, or third parties.

The App, its design, branding, and GEF-created materials remain the property of GEF or the relevant owner. Access to the App does not transfer ownership of them or permit use of GEF's name or marks to imply endorsement.

## 17. Data and electronic records

For off-chain personal data whose purposes and means GEF determines, GEF acts as the data controller or equivalent responsible organization under applicable law. GEF may process information reasonably necessary to operate, secure, support, and comply with law in connection with the App. Depending on the features you use, this may include:

- identity, contact, profile, location, preferred currency, and uploaded image information;
- Wallet addresses, Token holdings, transaction history, signatures, authorizations, and public blockchain records;
- device, browser, session, security, notification, support, and service-use information; and
- Content, Voucher terms, Pool rules, transaction parameters, complaints, and compliance records.

GEF may process this information to create and administer Accounts, provide requested features, submit and index transactions, display public listings, communicate with you, prevent abuse, secure systems, maintain records, resolve disputes, improve the App, and meet legal obligations. Depending on the context and applicable law, processing may be necessary to perform this agreement, comply with law, protect legitimate interests, establish or defend legal claims, protect vital interests, or act on separate consent.

Information marked as required during Account creation or a transaction is necessary to provide that Account or feature, meet a legal duty, or manage material risk. If you do not provide it, GEF may be unable to create the Account or provide the feature. Optional profile fields, location access, notifications, and similar optional functions are not required for general Account use and may be declined or disabled, subject to the technical limits of a transaction or feature already requested.

Acceptance of these Terms is not blanket consent to optional data processing. Where law requires specific consent, GEF will request it separately and provide any required choice.

GEF may share information with contractors and providers supporting hosting, storage, communications, mapping, authentication, relaying, blockchain access, security, support, compliance, and professional advice; with other Users when you publish or transact; and with authorities or other parties where lawfully required or necessary to protect rights and safety. Providers and public networks may operate in other countries, so information may be processed across borders subject to applicable safeguards.

Public blockchain activity may expose a Wallet address, assets, amounts, timestamps, transaction data, and related metadata worldwide. It may be copied, indexed, combined with other information, and practically impossible for GEF to erase or correct. Do not place private, sensitive, or unnecessary personal information in transaction data or public metadata.

GEF retains information for as long as reasonably needed for the purposes above, including security, fraud prevention, transaction evidence, legal duties, limitation periods, backups, and dispute resolution. Retention does not make GEF able to delete information held by a public network or third party.

Subject to applicable law, you may request access, correction, deletion, restriction, objection, portability, or other available data rights by contacting `info@grassecon.org`. GEF uses reasonable safeguards but cannot promise absolute security or confidentiality, particularly for public blockchain activity and information you publish.

## 18. Service changes, suspension, and termination

GEF may add, change, pause, restrict, or discontinue App features, supported networks, assets, catalogs, routes, fees, technical requirements, or eligibility. GEF will give reasonable notice where practicable, but may act immediately to address law, sanctions, fraud, security, safety, network failure, third-party dependency, or imminent harm.

GEF may warn, flag, limit, delist, suspend, or terminate an Account, Content item, Token, Voucher, Pool, route, or App-operated service if GEF reasonably believes that:

- these Terms, applicable rules, or law have been violated;
- information is false, incomplete, unsafe, or materially misleading;
- an obligation, redemption, guarantee, or fee has not been honored;
- an Account or credential is compromised;
- continued availability creates legal, regulatory, security, fraud, technical, community, or reputational risk; or
- action is required by an authority or service provider.

Where appropriate and lawful, GEF may provide notice, an opportunity to correct a violation, or a way to request review. Emergency action may occur without advance notice.

You may stop using the App at any time and may request closure of data or access that GEF controls. Suspension, delisting, termination, or closure does not undo completed transactions, remove public blockchain records, return assets automatically, or extinguish obligations to Issuers, Holders, Pools, Stewards, lenders, borrowers, or other Users.

## 19. Risks; no professional advice

You understand and accept the risk of loss arising from:

- credential loss, phishing, theft, unauthorized access, device failure, or user error;
- software defects, malicious code, smart-contract vulnerabilities, upgrades, administrator powers, or immutable settings;
- network congestion, chain reorganization, forks, outages, failed relayers, bridges, nodes, indexers, or other infrastructure;
- inaccurate quotes, oracle failure, valuation changes, volatility, depegging, insufficient inventory, slippage, fees, or illiquidity;
- Issuer default, non-redemption, poor quality, delayed delivery, Steward misconduct, inadequate reserves, or failed guarantees;
- changing law, enforcement, taxation, sanctions, geofencing, or legal classification; and
- the failure, insolvency, suspension, or misconduct of a third party.

Information in the App is general information, not legal, tax, accounting, financial, investment, credit, insurance, or other professional advice. You must make your own assessment and obtain qualified advice where appropriate.

## 20. Warranties and disclaimers

GEF will not exclude any warranty, duty, or remedy that applicable law does not permit it to exclude. Subject to that rule and to the maximum extent permitted by law, the App is provided on an as-available basis. GEF does not warrant that the App or any User-created Content, Token, Voucher, Pool, route, quote, transaction, good, service, or third-party provider will be uninterrupted, error-free, secure, accurate, lawful, available, fit for a particular purpose, of satisfactory quality, redeemable, liquid, or profitable.

GEF does not warrant another User's identity, authority, solvency, capacity, honesty, performance, goods, services, reserves, collateral, or compliance. You are responsible for appropriate due diligence and for the commitments you make.

Nothing in this section reduces an Issuer's duty to honor its Voucher, a Steward's duty to honor its Pool rules and advertised guarantees, or another party's obligations under valid Transaction Terms.

## 21. Limitation of liability

Nothing in these Terms excludes or limits liability for fraud, wilful misconduct, gross negligence, death or personal injury where such liability cannot lawfully be limited, violation of mandatory data-protection duties, mandatory consumer remedies, or any other liability that applicable law does not permit GEF to exclude or limit.

Subject to those exceptions and to the maximum extent permitted by law, GEF and its officers, directors, staff, contractors, agents, and affiliated entities are not liable for:

- an Issuer's, Steward's, Holder's, counterparty's, or other User's conduct or failure;
- the quality, safety, legality, delivery, redemption, pricing, or availability of goods, services, Tokens, Vouchers, Pools, or collateral;
- loss of credentials, assets, data, opportunities, goodwill, profit, revenue, business, or anticipated savings;
- indirect, incidental, special, exemplary, punitive, or consequential loss;
- a smart contract, blockchain, Wallet, device, network, oracle, bridge, relayer, third-party service, force-majeure event, or public record outside GEF's reasonable control; or
- a restriction or good-faith action taken to address law, sanctions, fraud, safety, or security.

Subject to the same exceptions, GEF's total aggregate liability arising out of or relating to the App or these Terms will not exceed the total fees you paid directly to GEF for use of the App during the 12 months immediately before the event giving rise to the claim. Pool fees, network fees, third-party charges, contributions, and assets transferred to another User or contract are not fees paid directly to GEF unless GEF was expressly identified as their recipient.

If applicable law does not allow a particular exclusion or limit, that exclusion or limit applies only to the greatest extent the law permits. This section allocates risk between you and GEF; it does not limit claims you may have directly against an Issuer, Steward, borrower, lender, Holder, or other responsible party.

## 22. Indemnity

To the maximum extent permitted by law, you will indemnify and hold harmless GEF and its officers, directors, staff, contractors, agents, and affiliated entities from third-party claims, losses, liabilities, penalties, judgments, and reasonable costs arising from:

- your breach of these Terms or applicable law;
- your Account, Content, Token, Voucher, Pool, Swap, Pool Contribution, goods, services, or other commitments;
- your infringement or misuse of another person's rights, information, assets, or credentials; or
- a tax, regulatory, consumer, employment, redemption, payment, or other obligation for which you are responsible.

This indemnity does not apply to the extent a claim was caused by the protected party's fraud, wilful misconduct, gross negligence, or breach of a non-excludable duty. GEF will give reasonable notice of a covered claim where practicable and will not require you to accept a settlement that unlawfully admits wrongdoing on your behalf.

## 23. Disputes

If you have a dispute with another User, you should first use the complaint, redemption, or dispute process disclosed for the relevant Voucher, Pool, or transaction. GEF may choose to provide records, communication tools, moderation, or informal assistance but is not obliged to decide the dispute and does not become liable for the underlying obligation by assisting.

Before filing a claim against GEF, you should send a written description of the issue and requested remedy to `info@grassecon.org` and allow a reasonable opportunity for a good-faith response. This does not shorten a statutory limitation period or prevent urgent relief.

These Terms and disputes between you and GEF are governed by the laws of Kenya, without regard to conflict-of-law rules. Courts of competent jurisdiction in Kenya may hear such disputes. This choice does not deprive you of mandatory consumer protections or access to a forum that applicable law does not permit these Terms to exclude.

## 24. Changes to these Terms

GEF may update these Terms to reflect changes in the App, law, risk, security, or operations. GEF will identify the new version and effective date.

GEF will give at least 30 days' notice before a material change takes effect through the notice method approved for that update. Version 1.1 was published and took effect on 1 October 2026 as the initial Terms for public use of the App. A change may take effect sooner where reasonably necessary to comply with law, address an urgent security or safety risk, prevent fraud, or respond to an event outside GEF's reasonable control.

Where applicable law permits, continued use after the effective date constitutes acceptance of the updated Terms. Where law requires affirmative consent, GEF will request reacceptance before allowing continued use of affected Account features. If you do not agree, you must stop using the affected features. Changes apply prospectively and do not alter a completed transaction or previously agreed Transaction Terms.

## 25. General terms

**Entire agreement.** These Terms are the entire agreement between you and GEF concerning the App, except for a separate written agreement signed by an authorized GEF representative. Voucher terms, Pool rules, and Transaction Terms govern the relevant obligations between their parties as described in Section 2.

**No partnership or agency.** Using the App does not create employment, partnership, joint venture, agency, fiduciary, franchise, or representative authority between you and GEF or between Users.

**Assignment.** You may not assign your Account or this agreement without GEF's written consent. GEF may assign this agreement as part of a reorganization, transfer of the App, or succession of operations, subject to applicable law and reasonable notice.

**Severability.** If a provision is unlawful or unenforceable, it will be limited to the minimum extent necessary and the remaining provisions will continue in effect.

**No waiver.** Failure or delay in enforcing a provision is not a waiver. A waiver applies only if made in writing by an authorized party and only to the specific matter stated.

**Force majeure.** GEF is not responsible for delay or failure caused by events beyond its reasonable control, subject to any non-excludable duty to take reasonable precautions or mitigate harm.

**Survival.** Provisions concerning outstanding commitments, transaction evidence, public records, Content authorization, data retention, risk allocation, liability, indemnity, disputes, and general interpretation survive suspension, termination, or Account closure to the extent necessary to give them effect.

**Authorized statements.** Only a written statement by a duly authorized GEF representative can create a commitment on behalf of GEF. A volunteer, contractor, community member, broker, or other User cannot bind GEF without that authority.

**Headings and language.** Headings are for convenience. The English version controls unless applicable law requires otherwise.

## 26. Contact

Questions, complaints, legal notices, and data requests concerning these Terms or the App may be sent to:

- Grassroots Economics Foundation
- Email: `info@grassecon.org`
- Postal address: P.O. Box 1659-80108, Kilifi, Kenya

# **Cosmo-Local Credit (CLC)**

## A network for routing credit, coordinating commitments, and financing a healthy cosmo-local economy

**Version:** 0.8

**Date:** 30 September 2026

**Authors:** William O. Ruddick and Mohamed Sohail

**Contact:** [info@grassecon.org](mailto:info@grassecon.org)

**Download:** <a href="/white-paper/Cosmo-Local-Credit-CLC-White-Paper-v8.pdf">CLC White Paper v0.8 PDF</a>

**Publication:** Final versioned public publication. This paper is not investment advice and does not constitute an offer to sell or a solicitation to buy any security or financial instrument. Later versions may revise the designs described here.

## How to read this paper

This paper combines four kinds of material. The status applies throughout, even where a chapter does not repeat it.

| Status | Meaning |
| --- | --- |
| **Current** | Behavior verified in the CLC App or the public Protocol v1.1.0 contracts. The [Protocol reference](/protocol/overview) is the factual source for those contracts. |
| **Deployment-dependent** | A capability that exists only where a particular Pool, provider, jurisdiction, governance body, or published policy enables it. |
| **Historical** | Evidence or functionality from the earlier Sarafu Network service. It is not current CLC adoption or proof that a user, asset, record, or obligation migrated. |
| **Proposed** | A design, economic model, governance mechanism, or roadmap item that is not represented as deployed. |

Current Protocol v1.1.0 includes direct `SwapPool` execution, optional curation, valuation, Pool token-balance caps, Pool fees, an additional protocol fee, and a quote-only `SwapRouter`. Multi-hop execution, HTLC or escrow routing, batch netting, shared insurance, the proposed CLC governance token, the proposed CLC Network Pool, fee-credit mechanisms, and network liquidity programs are proposed or deployment-dependent.

**Intended audience:** Pool builders and Stewards, protocol engineers and auditors, liquidity and mandate funders, governance designers, and legal or compliance reviewers.

## Abstract

Cosmo-Local Credit is a product family built around the **Commitment Pooling Protocol (CPP)**. CPP describes how independently governed Commitment Pools can curate redeemable commitments, publish exchange-rate methods and limits, hold inventory, and enable accountable exchange.

A **Commitment Pool** is the governed arrangement. A current Protocol v1.1.0 **`SwapPool`** is one contract component: a token vault and direct-swap engine. A deployment can connect that contract to registries, quoters, Pool token-balance caps, fee policies, and other services.

Cosmo-local means sharing open standards, software, and knowledge globally while keeping issuance, fulfillment, governance, and real-world accountability local. An issuer remains responsible for its voucher. A Pool Steward remains responsible for Pool rules and any guarantee it expressly assumes. Neither the CLC App nor GEF automatically guarantees a voucher, Pool, value, route, liquidity position, or outcome.

## Current deployment

GEF operates the CLC App at [cosmolocal.credit](https://cosmolocal.credit). It provides account and wallet access, a public Market catalog, and supported interfaces for tokens, vouchers, Offerings, Commitment Pools, transfers, and direct Pool swaps. Availability depends on the interface, contracts, inventory, configured limits and fees, network state, eligibility, providers, jurisdiction, and published issuer or Pool terms.

Operating the interface does not by itself make GEF an issuer, Pool Steward, custodian, lender, borrower, broker, guarantor, redeemer, adviser, insurer, or party to obligations between participants. Use of the App is governed by the [Terms of Service](/governance/terms).

Protocol v1.1.0 separates accountable roles from technical control. A Pool Steward, `SwapPool` owner, proxy administrator, dependency controller, catalog moderator, and fee recipient may be different parties. See [Concepts and vocabulary](/introduction/concepts) for the shared terminology.

## Historical lineage

The historic Sarafu Network preceded the CLC App and provided evidence about community currencies and commitment pooling. Its service transition to Cosmo-Local Credit did not transfer every historic account, wallet, token, voucher, Pool, balance, report, participant, or obligation.

Historical metrics in this paper use a dated, internally coherent Sarafu dataset. They are not current CLC usage figures. See the [Executive Summary](/white-paper/executive-summary) for the source and measurement period.

## Design model

CPP uses four broad functions:

- **Curation:** decide which vouchers or other assets are admitted.
- **Valuation:** publish the method used to produce Pool exchange rates or quotes.
- **Limitation:** apply current Pool token-balance caps or other separately implemented risk controls.
- **Exchange:** hold inventory and execute Pool swaps under disclosed fees and bounds.

A deployment may add routing, monitoring, liquidity support, guarantees, reserves, insurance, or governance services only under separately published policies. Listing, curation, a limit, a reserve, or a blockchain record does not by itself establish issuer capacity, fulfillment, endorsement, a guarantee, or insurance.

## Values and design principles

- **Care for people:** support individual and collective well-being.
- **Care for the environment:** reduce ecological harm and support regenerative practice.
- **Fairness:** promote secure and equitable access to resources, knowledge, and care.
- **Reciprocity:** share risk, cost, responsibility, and surplus under disclosed rules.
- **Non-dominance:** resist concentrated control over people, data, finance, knowledge, and material resources.
- **Resilience:** help communities prepare for and adapt to economic, political, and climate disruptions.
- **Local accountability:** keep real-world fulfillment and legal responsibility with identified parties.
- **Forkability:** allow compatible communities and deployments to leave shared registries or services without erasing valid balances or obligations.

The digital layer is shared memory and coordination infrastructure. It is not a substitute for relationships, issuer performance, local governance, or legal accountability.

## Current and proposed flows

### Current direct Pool flow

1. A holder reviews a voucher, its issuer, its terms, and associated Offerings.
2. A Pool admits supported assets and publishes its configuration and responsible authorities.
3. The holder obtains a quote and authorizes a direct Pool swap.
4. `SwapPool` performs on-chain swap settlement and accounts for Pool and protocol fees.
5. If the holder later chooses **“Redeem”** in the App, the App prepares a transfer to the token owner as redemption presentment.
6. The issuer separately performs the promised fulfillment and records discharge so fulfilled units cannot be reused.

Taking inventory from a Pool is a swap. It is redemption only if that Pool has separately assumed the issuer role and fulfills the applicable voucher terms.

### Wider proposed design

The proposed design explores execution routing, netting, shared services, network liquidity programs, insurance policies, and governance assets. Each would require implementation, responsible parties, adopted rules, funding, controls, and public disclosures before it could apply.

The proposed fee model may use a network rake taken from Pool fees and separate routing or service fees. That proposal is distinct from Protocol v1.1.0, where an optional protocol fee is additional to the Pool fee.

Supporters or liquidity providers receive no automatic Pool shares, repayment, withdrawal, reward, or governance rights from the current `SwapPool`. Any current or future program must separately disclose the transfer type, responsible party, control, recovery or withdrawal rights, losses, rewards, fees, and governance rights.

## Reader map

- Current terminology and action lifecycle: [Concepts and vocabulary](/introduction/concepts)
- Verified deployed contracts: [Protocol v1.1.0](/protocol/overview)
- Historical evidence: [Executive Summary](/white-paper/executive-summary)
- Confederation and interoperability: Chapters 5, 8, and 11
- Proposed guarantees and insurance boundaries: Chapters 10 and 11
- Proposed liquidity and fee models: Chapters 7, 9, and 12
- Proposed measurement framework: Chapter 14 and Appendices A–C
- Proposed roadmap: Chapter 15
- Legal and compliance considerations: Chapter 17

[Previous White Paper versions](/white-paper/archive) are retained only as clearly superseded historical publications.

## **Executive summary**

The **Commitment Pooling Protocol (CPP)** describes how independently governed Commitment Pools can curate redeemable commitments, publish exchange-rate methods and limits, hold inventory, and enable accountable exchange. Issuers remain responsible for their voucher commitments. Pool Stewards remain responsible for Pool rules and any guarantee they expressly assume. Neither the CLC App nor GEF is a universal guarantor.

Protocol v1.1.0 provides current direct-swap building blocks: `GiftableToken`, `SwapPool`, optional registries and valuation modules, Pool token-balance caps, Pool fees, an additional protocol fee, and a quote-only `SwapRouter`. The current contracts do not record real-world fulfillment, create automatic liquidity-provider shares, execute multi-hop routes, or provide universal reserves, guarantees, or insurance.

The historic **Sarafu Network** used commitment-pooling concepts across community currencies, savings groups, mutual-aid systems, and production commitments. Its service later transitioned to the CLC App. This was not a representation that every historic account, wallet, token, voucher, Pool, balance, report, participant, or obligation migrated.

**Historical Sarafu Network snapshot — Celo activity from 5 July 2023 through 20 July 2025**

**Source:** [Dune Analytics dashboard](https://dune.com/grassrootseconomics/sarafu-network)

- 26,367 users
- 285,197 peer-to-peer exchanges
- 188 unique active Commitment Pools
- 745 unique active vouchers
- $320,692 Pool swap volume
- 899 reports published ([historical reports archive](https://sarafu.network/reports))

These figures are historical evidence, not current CLC usage figures.

The wider proposed CLC design explores how compatible networks could:

1. discover and quote paths across independently governed Pools;
2. coordinate accountable network services without overriding local responsibility;
3. support separately funded liquidity mandates, guarantees, reserves, or insurance policies;
4. measure Pool swaps separately from voucher presentment, fulfillment, and discharge; and
5. use a proposed network rake and service fees to fund adopted shared services.

The proposal includes a **proposed CLC governance token** and a **proposed CLC Network Pool**. Neither is part of the current App or Protocol v1.1.0.

Under the proposed model, liquidity and governance participants could act only through separately adopted programs with published eligibility, risks, controls, transfer rights, recovery terms, and fee rules. Ordinary Pool deposits create no automatic share, repayment, withdrawal, reward, or governance right.

The shared objective is:

> Increase accountable exchange and the fulfillment of real-world commitments while preserving care, fairness, local responsibility, and resilience.

Anti-capture and credible exit remain core design goals. Proposed controls include time-delayed governance, multiple approval thresholds, transparent delegation, conflict rules, incident review, and a documented fork-and-migrate process. These controls would reduce selected governance risks but could not eliminate loss or guarantee outcomes.

## **1. Commitment Pooling Protocol (CPP): the core primitive**

**Mental model:** A Commitment Pool is a governed arrangement for admitting vouchers or other assets, publishing exchange rules, holding inventory, and enabling swaps. Holders later present vouchers to their issuers for real-world fulfillment. Pool exchange and issuer fulfillment are separate lifecycles.

CPP coordinates value through clearly described commitments. The model is discussed in [Grassroots Economics: Reflection and Practice](https://willruddick.substack.com/p/grassroots-economics-the-book-is).

### **1.1 What is a commitment?**

A commitment is an identified party's promise of future delivery—for example food, transport, labor, storage, or another lawful good, service, benefit, or performance. A **voucher** is a token or record represented as that commitment under published terms.

The token contract records digital mechanics. Voucher terms identify the issuer, Offering, capacity, place, timing, restrictions, presentment, fulfillment, complaints, and discharge process.

### **1.2 What is a Commitment Pool?**

A Commitment Pool is the governed arrangement. It can be stewarded by an individual, cooperative, community group, public agency, federation, multisig, service operator, or another accountable structure.

Relevant roles and authorities include:

- **Pool Steward:** publishes and administers Pool rules and any expressly assumed guarantee;
- **Pool owner:** holds current `SwapPool` owner powers;
- **proxy administrator:** can upgrade a proxied implementation;
- **dependency controllers:** govern configured registries, quoters, limiters, or fee components;
- **route finder or operator:** may discover quotes or, in a future implementation, execute a separately authorized route; and
- **guarantor:** assumes a defined obligation only through published, funded terms.

CPP groups Pool functions into four concepts:

- **Curation:** admit supported tokens or vouchers.
- **Valuation:** publish the method used for an exchange rate or quote.
- **Limitation:** apply current Pool token-balance caps or other separately implemented controls.
- **Exchange:** hold inventory, execute swaps, account for fees, and emit transaction records.

Protocol v1.1.0 implements these functions through `SwapPool` and optional dependencies. Its current `Limiter` caps a token balance at a Pool; it does not provide rolling, per-account, or network-wide swap limits. Its current `SwapRouter` calculates multi-Pool quotes; it does not execute swaps.

The wider proposed CPP design may add rolling limits, account controls, execution routers, HTLC or escrow paths, and batch netting. Those are proposed components, not descriptions of the current limiter or router.

### **1.3 Current direct-swap logic**

A current direct Pool swap:

1. checks the optional registry for the input and output tokens;
2. measures the input received;
3. obtains a quote from the configured quoter or applies raw-unit parity;
4. checks the resulting Pool token balance against the optional limiter;
5. calculates the Pool fee and any additional protocol fee;
6. checks available output inventory;
7. transfers the protocol fee and output and accounts for the Pool fee; and
8. emits swap events.

The quote is a transaction parameter, not proof of issuer capacity, redemption value, fair value, cash convertibility, or a guarantee.

### **1.4 Wider use**

Commitment Pools can support community exchange, production, mutual aid, public programs, and other accountable structures. A separately documented credit product could use a voucher as collateral or a repayment instrument, but it would require supplemental and transaction-specific terms. An ordinary send, Pool deposit, Pool swap, redemption presentment, fulfillment, or discharge is not automatically a loan or repayment.

CPP is intended for accountable exchange and auditable transaction records, not speculative churn. On-chain records still do not prove real-world fulfillment or social impact.

## **2. The accounting shift: from assets to trust**

Traditional finance begins with **Assets − Liabilities = Equity**. CPP reframes this for a commitment economy:



- **Acceptance capacity:** how much of an issuer's commitments a Pool or network is still willing to accept.
- **Outstanding commitments:** issued promises that remain unfulfilled and are held by others.
- **Fulfillment capacity:** the issuer's evidenced ability to perform those promises.

**Illustrative commitment-capacity relationship:**

Acceptance capacity − outstanding commitments = remaining acceptance capacity

This conceptual identity can inform Pool risk limits: unlimited issuance does not imply unlimited acceptance. It is not a balance-sheet identity or a statement that every Voucher is legally a debt or loan.

**Example:** A transporter issues “100 rides” in Vouchers. A Pool accepts at most 40 rides worth at a time. If 15 accepted rides remain outstanding, the Pool has capacity to accept up to 25 additional rides under that policy. The calculation does not itself create a loan or guarantee fulfillment.


---

## **3. Fulfillment, discharge, and exchange activity**

A Pool swap changes which addresses hold assets. Voucher fulfillment occurs when the issuer performs the published commitment. Discharge records the fulfilled units so they cannot be presented again. These events must not be collapsed into one use of “settlement.”

The proposed measurement framework uses separate records for:

- completed Pool swap volume;
- valid redemption presentments;
- confirmed issuer fulfillment;
- discharge;
- outstanding eligible commitments; and
- measured Pool inventory.

A proposed commitment-discharge velocity can compare fulfilled value during a period with average outstanding eligible commitment value, but only where both use the same disclosed valuation method. Token supply is not a sufficient denominator: it can include issuer inventory, expired or inaccessible units, tests, and balances that do not represent an outstanding third-party commitment.

A separate Pool swap-activity ratio can compare completed Pool swap value with measured Pool inventory. It describes exchange activity, not issuer fulfillment.

Liquidity may improve inventory availability and make exchanges easier. It does not guarantee that issuers will perform, that contributors will recover assets, or that a Pool quote represents redemption or cash value. Any liquidity-provider rights require separate published terms.

See [Appendix A](/white-paper/appendix-a-math-box) for definitions and [Appendix C](/white-paper/appendix-c-kpi-definitions) for the proposed measurement specification.

## **4. Reusable forward-style collateral**

A separately documented credit facility might accept fungible, transferable vouchers as collateral or as a repayment instrument. If it did:

- Pool admission could make the collateral more discoverable;
- additional lawful presentment and fulfillment options could support repayment;
- limits, inventory, valuation, liquidity, issuer-performance, and default risks would remain; and
- no route, fulfillment, repayment, value, or recovery would be guaranteed.

### 4.1 Producer credit loop

A future CLC-compatible service could support producer credit only when the parties establish a distinct facility and expressly present the transaction as a repayable advance. Its transaction terms would identify the creditor and debtor and state:

- the advance and repayment amounts;
- due dates, interest, fees, and permitted collateral use;
- assignment and any change in the creditor or claim holder;
- how voucher fulfillment is valued and evidenced for repayment accounting;
- partial repayment, remaining amounts, default, and discharge; and
- available remedies under applicable law.

An illustrative flow is:

1. A producer or service provider issues a voucher representing a commitment to future output, such as ten taxi rides, 50 kilograms of maize, or ten labor-hours.
2. A Pool Steward admits that voucher and publishes the Pool's exchange-rate method, limits, fees, inventory rules, and any expressly assumed protection.
3. A lender or liquidity program separately provides an advance under written transaction terms and accepts the producer's vouchers as collateral or an agreed repayment instrument.
4. Holders may transfer the vouchers, swap them through compatible Pools, or present them to the issuer.
5. The issuer's confirmed fulfillment satisfies the voucher commitment. It reduces the separate credit balance only to the extent, at the value, and upon the evidence specified in the credit terms.
6. Records distinguish voucher fulfillment from credit accounting and identify any partial repayment, remaining amount, assignment, default, or discharge.

This structure could permit agreed in-kind repayment while preserving separate records for the voucher and credit obligations. It does not arise from an ordinary transfer, deposit, Pool swap, redemption presentment, fulfillment, or discharge.

**Illustrative example:** A producer receives a $1,000 advance under terms stating that confirmed fulfillment of specified maize vouchers is credited against the repayment amount using a stated valuation method. The lender applies a credit only after receiving the evidence required by those terms. If the credit terms do not make that connection, acquiring, transferring, swapping, presenting, or fulfilling the voucher does not affect the advance.

## **5. From isolated Pools to a federated network**

Current Protocol v1.1.0 supports direct execution through one `SwapPool` and provides a quote-only `SwapRouter`. It does not execute multi-hop routes, HTLCs, escrow routes, batch netting, or cross-network clearing.

This chapter proposes how independently governed Pools could coordinate without giving up their own admission, valuation, limit, fee, inventory, authorization, and governance rules.

### **5.1 Separate exchange and fulfillment measures**

Federation might improve access to inventory, but it would not merge the voucher and exchange lifecycles. Any implementation would measure these events separately:

1. a route is quoted;
2. one or more Pool swaps execute and settle on-chain;
3. a holder presents voucher units to the issuer;
4. the issuer fulfills the commitment; and
5. fulfilled units are discharged.

More quoted or executed routes do not prove more fulfillment. Reports would state the cohort, period, assets, valuation method and timestamp, exclusions, corrections, and off-chain evidence required by Appendix C.

**Illustrative route:** A school holds maize vouchers but needs transport vouchers. A route service identifies compatible Pool inventories. Execution would succeed only if every separately authorized hop remained within its quote bounds, limits, fees, inventory, and policy. The resulting swaps would not prove that either issuer later fulfilled its voucher commitments.

### **5.2 Proposed routing and rebalancing services**

A future route service could support two distinct activities.

**Participant-initiated execution.** Given input and output assets, an amount, and user constraints, the service could identify a path and prepare execution. Each hop would have its own responsible Pool, quote, authorization, fees, limits, inventory, and receipt. Atomic batches, HTLCs, and escrow are possible future execution choices, not current Protocol behavior.

**Opt-in Pool rebalancing.** Pool Stewards could publish inventory targets, allowed counterparties, asset classes, quote-deviation bounds, and per-period limits. An accountable service could search for compatible cycles or chains and execute only the authorized intents.

Rebalancing would be opt-in. A Pool could allow participant routes while refusing outbound rebalancing, or it could enable only selected assets, counterparties, and amounts. Every executed hop would produce a receipt, and any service fee would be disclosed separately from Pool and Protocol fees.

#### **5.2.1 Confederation and interoperability**

Independent deployments could operate their own registries, interfaces, route services, and policy profiles while choosing compatible data and receipt standards. Cross-profile execution would remain deployment-dependent.

A compatible profile would:

- identify its registry roots, service operators, controllers, and applicable terms;
- disclose allowed and denied counterparties, assets, adapters, and routes;
- apply every participating Pool's authorization, limits, fees, and inventory constraints;
- preserve per-hop quote-to-receipt evidence; and
- allow otherwise functional Pools to leave or select another registry without erasing balances or issuer obligations.

Compatibility can increase available exchange paths and reduce dependency on one registry or operator. It does not make the network, CLC App, GEF, or another Pool responsible for an issuer's fulfillment.

### **5.3 Proposed network-rake and service-fee model**

Current Protocol v1.1.0 charges a Pool fee and, when configured, an additional Protocol fee on a direct Pool swap. Those current fees remain distinct.

A future program could separately receive:

1. a **network rake**, defined as a stated share of participating Pools' collected Pool fees; and
2. a **routing or service fee**, charged for an identified future service.

The proposed network rake is not an additional percentage applied to the full swap amount after already counting the Pool fee. For Pool `p`:

τ_p = f_p · r_p

where `f_p` is the Pool-fee rate and `r_p` is the proposed share of that Pool fee allocated to the network program.

For a measured period:

- **gross Pool fees** are the sum of each Pool's actual collected Pool fees;
- **network-rake receipts** are the stated shares of those collected fees;
- **service-fee receipts** are separately collected routing or service fees; and
- **program fee receipts** equal network-rake receipts plus service-fee receipts.

No category is counted twice. Current Protocol fees are not included unless a separately adopted policy lawfully redirects actual Protocol-fee receipts into the future program.

For an aggregate approximation, let:

- `Q_swap` be the value of executed Pool swaps for the defined cohort and period; and
- `τ` be the effective rate of the proposed network rake and separately identified service fees over that executed swap value.

Then:

F ≈ τ · Q_swap

This is an analytical approximation, not a promise of revenue. Every input requires a stated cohort, period, unit, valuation timestamp, exclusions, and correction policy.

#### **5.3.1 Cash-eligible and in-kind receipts**

Fees may arrive in cash-eligible fungible assets or in vouchers and other in-kind assets. In-kind receipts cannot automatically pay cash expenses or coverage claims. Any exchange or conversion would require authority, available inventory, disclosed venues, bounds, and actual execution.

Let `χ` be the realized share of fee receipts that is cash-eligible after policy restrictions, failed conversions, and slippage. Cash-usable receipts are:

F_cash ≈ χ · F

Budget and break-even analysis would use realized `F_cash`, not gross quoted fees or the face value of in-kind inventory. A future program would report gross Pool fees, network-rake receipts, service fees, asset composition, conversion results, and cash-usable receipts separately.

### **5.4 Proposed liquidity programs**

A future, separately documented liquidity program could allocate assets to designated Pools or routing services. Current `SwapPool` contracts do not mint Pool shares or automatically create repayment, withdrawal, reward, governance, or profit rights.

Any program would publish:

- the responsible entity and participating Pool Stewards;
- contributed assets and whether the transfer is repayable, withdrawable, donated, or endowed;
- custody and technical-control arrangements;
- permitted uses, limits, lockups, withdrawal gates, and loss allocation;
- fee or incentive eligibility and whether the amount may be zero;
- reporting, conflicts, complaints, and remedies; and
- migration, termination, and treatment of remaining assets and obligations.

Material risks include inventory that is difficult to exchange or fulfill, low cash eligibility, issuer non-performance, contract or provider failures, governance changes, and restrictions on exit. Limits, reserves, receipts, and dashboards may reduce or reveal some risks; they do not eliminate loss.

For an ex-post analytical metric, let:

- `ϕ` be the realized fraction of program fee receipts allocated under the program's adopted terms; and
- `K` be the measured value of assets covered by the program under one stated method.

Then:

FeeFlow_LP ≈ (ϕ · F) / K = (ϕ · τ · Q_swap) / K

This metric describes realized fee flow per measured program asset. It is not APY, a forecast, a dividend, or a guaranteed return. Reports would keep swap volume, redemption presentment, issuer fulfillment, discharge, holding duration, losses, withdrawals, and fee receipts separate.

## **6. Proposed network-level liquidity and governance**

Experience from the historic Sarafu Network motivated research into two wider design questions:

1. how independently governed Pools could coordinate liquidity and routing services; and
2. how shared services could remain accountable as participation grows.

One proposed CLC design introduces a **proposed CLC Network Pool** as a network-level clearing and budget-coordination arrangement and a **proposed CLC governance token**. Neither exists in the current App or Protocol v1.1.0. Other deployments could use cooperatives, public agencies, federations, multisigs, service operators, or other accountable structures without adopting either proposal.

### **6.1 Downside controls and optionality**

Current Protocol v1.1.0 can apply Pool token-balance caps and inventory checks. These controls constrain selected contract actions; they do not prevent issuer non-performance, loss of value, key loss, contract failure, or every other loss.

A future deployment could add circuit breakers, timelocks, reserves, guarantees, or insurance. Any protection would need an identified responsible party, covered event, funding, cap, exclusions, duration, evidence, claims process, and applicable terms.

Proposed governance should keep registry and service powers narrow and reviewable. Ordinary actions can use notice, delay, reason publication, appeal, and correction processes. Emergency actions should produce incident records and expire or receive review under an adopted policy.

Compatible route discovery could make more exchanges possible across Pools. Multi-hop execution and netting would require additional software, authorization, bounds, failure handling, and governance. More quoted or executed swaps would not by itself prove voucher fulfillment or social impact.

## **7. Proposed CLC stewardship and governance assets**

This chapter presents one optional future governance and liquidity-coordination design. The proposed CLC governance token, stCLC, sCLC, governance vault, insurance fund, Waterfall, gauges, mandates, fee-credit windows, and external-market programs are not part of the current CLC App or Protocol v1.1.0. Each would require an implementation, accountable operator, published policy and terms, security review, and applicable legal approval.

CPP does not require this token model. Compatible deployments could instead use cooperatives, public agencies, federations, multisigs, services, or other accountable structures.

### **7.1 Purpose**

If adopted, the proposed governance layer could:

- coordinate shared registries and route services;
- allocate approved liquidity mandates across independently governed Pools;
- administer an optional, expressly scoped, funded coverage program;
- maintain common infrastructure and observability;
- recognize contributors under published eligibility and anti-gaming rules; and
- preserve review, appeal, transparency, and credible exit as participation grows.

### **7.2 Proposed governance-asset model**

The design contains three distinct proposed assets:

1. **Proposed CLC governance token:** a transferable base governance asset under adopted issuance, custody, voting, and compliance rules.
2. **stCLC:** a non-transferable vote-escrow receipt minted when the proposed CLC governance token is locked. It would represent time-bounded governance power and could permit disclosed delegation.
3. **sCLC:** an epoch-scoped authorization or incentive asset issued under policy. It could support capped fee-credit access or approved liquidity and routing incentives and could expire or be burned at epoch end.

Neither stCLC nor sCLC would be equity, a dividend, a residual claim, a promise of return, or a community voucher. An adopted policy could set sCLC issuance and fee-credit access to zero in any epoch.

Governance lockups, minimum durations, cooldowns, delegation, concentration caps, and critical-action thresholds would be published before use. Unlocked proposed CLC governance tokens would not vote under this design.

#### **7.2.1 Illustrative supply and allocation**

The illustrative total proposed CLC governance-token supply is **500,000,000**. This is a design parameter, not a current issuance, offer, valuation, or promise of liquidity.

An illustrative allocation is:

- **15% — Grassroots Economics Foundation:** permanently staked, non-transferable, and bound to an identified GEF multisig under published signer and rotation rules.
- **15% — core team and early partners:** staked during a policy-set cliff and linear vesting period of 24 months, with voting and transfer rules disclosed in advance.
- **30% — private endowments:** recognition for early contributors providing approved network liquidity, with policy-set vesting of 24 months.
- **40% — public-liquidity reserve:** held in a timelocked governance vault for optional external-market and accessibility programs.

Under the illustrative public-liquidity controls:

- no more than 10% of total supply would be active across external venues at one time;
- each deployment would expire after 90 days unless renewed through the adopted process;
- liquidity positions and any position tokens would remain under disclosed governance control; and
- proposed CLC governance tokens used in liquidity positions would not vote unless locked under the same rules as other voting tokens.

A future launch could begin with a disclosed multisig and transition only after separately approved hardening milestones, such as independent audits, monitoring, incident runbooks, and tested pause and fork procedures. Every adopted parameter and change process would be published separately.

#### **7.2.2 Availability and endowment stages**

A future endowment program could use staged contribution windows and a published reference value for intake and budgeting. That reference would not be a promise of market price, appreciation, repayment, or exit.

Contribution terms would state whether assets are donated, endowed, withdrawable, or repayable; who controls them; their permitted use; lockups; loss allocation; reporting; and exit conditions. Large contributions could face voting caps or diminishing governance weight.

Any external-market liquidity would require a separate decision identifying venues, responsible operators, assets, caps, timing, conflicts, risk controls, reporting, and termination. The policy would not target or guarantee a price.

#### **7.2.3 Proposed impact-seeding program**

A future program could allocate part of the governance vault to contributors who place assets into designated Commitment Pools and measurably improve exchange access and confirmed issuer fulfillment.

An adopted eligibility policy would:

1. identify approved Pools, assets, minimum duration, and lockup terms;
2. define productive contribution using executed-swap evidence and separately evidenced presentment, fulfillment, and discharge;
3. measure marginal contribution rather than total value locked alone;
4. exclude self-dealing and circular wash activity;
5. apply per-entity caps and diminishing returns; and
6. provide an observation, dispute, and correction window before final allocation.

Any grant would remain subject to the program's published terms, vesting, eligibility, compliance, and loss rules.

### **7.3 Proposed voting, incentives, and fee access**

Under this design, stCLC holders could vote on eligible Pools, route-service mandates, shared budgets, or other adopted proposals. A curated gauge system could translate votes into bounded sCLC incentives for eligible liquidity or routing operators.

The measurement policy would keep executed swaps and issuer fulfillment separate. It would not reward quoted but unexecuted routes, unresolved presentments, self-dealing, or total value locked without evidence of useful activity.

An adopted governance process could also publish an epoch fee-credit budget. Eligible stCLC holders might receive sCLC authorizing capped, time-limited swaps from designated fee-holding Pools into allowlisted assets or programs. This would be policy-gated access to available inventory, not passive income or ownership of the fee-holding Pool.

#### **7.3.1 Service-fee enforcement and profile choice**

A future registry profile could require participating Pools or route services to use a compatible fee adapter or hook. The profile might refuse discovery, routing, or program support when the required receipt does not prove fee collection.

Names such as **PoolFactory** or **FeeHook** describe possible future modules; they are not Protocol v1.1.0 contracts. Any implementation would disclose the code, addresses, controllers, recipients, rates, eligible transactions, failure handling, and audit status.

Enforcement would be profile-specific. A Pool excluded by one profile could continue operating locally or join another compatible registry if its contracts and dependencies remained functional. Clients should expose available profiles and show applicable fees before authorization.

#### **7.3.2 sCLC budget and optional external-float controls**

After funding adopted higher-priority budgets, a future process could publish an epoch fee-credit budget `F_epoch`, including zero. A policy might assign a participant limit in proportion to stCLC voting power:

limit_user_epoch = F_epoch × (stCLC_user / stCLC_total).

Every window would remain subject to allowlists, caps, inventory, eligibility, incident rules, and applicable law.

A separate policy could authorize a capped, time-weighted acquisition of the proposed CLC governance token only to reduce a measured external governance-attack surface. It would require:

- a published trigger based on external float over a stated period;
- a maximum share of realized, eligible fees and venue volume;
- time-weighted execution with no exact timing announcement;
- an automatic stop when adopted coverage or operating thresholds are not met;
- retirement or placement of acquired tokens in a disclosed non-voting account; and
- an explicit statement that the program does not target or guarantee a price and does not affect issuer fulfillment.

The policy could remain disabled indefinitely.

#### **7.3.3 Portfolio Pools and attestations**

A **portfolio Pool** would be an ordinary Commitment Pool curated around a mission or service domain. Its Pool Steward could be an individual, cooperative, community group, public agency, federation, multisig, service operator, or another accountable structure.

Support could occur through:

1. direct contributions under the Pool's published terms;
2. time-bounded liquidity mandates approved through the adopted governance process; or
3. sCLC-directed access to a bounded post-Waterfall budget when that mechanism is enabled.

Portfolio Pools would remain independently governed and could use shared or independent registries.

Certifications could inform admission or risk treatment but would not create entitlement to fees, profit, or residual assets. A deployment might use:

- **registry-bound attestations** from an identified verifier applying a published method; or
- **verification-service vouchers** representing a redeemable commitment to perform a stated audit or assessment.

The Pool would disclose how an attestation affects admission, exchange-rate methods, limits, or eligibility and how errors, expiry, conflicts, and appeals are handled.

### **7.4 Proposed Waterfall and budgets**

The proposed Waterfall would allocate only realized, eligible receipts under an adopted governance process. It would distinguish:

- **cash-eligible assets (`E_cash`):** allowlisted fungible assets that may be used or converted under policy for cash-denominated obligations; and
- **in-kind assets (`E_kind`):** vouchers or other assets that may support in-network exchange but do not count toward cash-denominated coverage or operating obligations unless actually converted.

A conversion policy would identify authorized operators, assets, venues, price sources, time windows, slippage bounds, caps, conflicts, records, and incident procedures. Treasury conversion would not determine an issuer's voucher obligation or a Pool's exchange-rate method.

An illustrative priority order is:

1. **Funded coverage target:** build any adopted reserve or proposed insurance fund to its disclosed target for defined covered events.
2. **Core operations:** fund a capped, disclosed budget for legal work, education, communications, infrastructure, audits, and observability.
3. **Liquidity mandates:** allocate approved assets to stated Pool or route-service purposes under caps and sunset review.
4. **Optional external-float control:** fund only when its published trigger and higher-priority thresholds are satisfied; otherwise allocate zero.
5. **Proposed fee-credit budget:** allocate any approved remainder to designated fee-holding Pools and publish `F_epoch`, which may be zero.

Budget decisions could consider confirmed fulfillment, covered exposure, eligible reserves, limit utilization, executed routes, concentration, incidents, and guarantor performance. Each metric would follow the evidence and cohort rules in Appendix C.

A possible contributor flow would be:

1. contributors transfer eligible assets under separately adopted endowment or program terms;
2. eligible participants receive and, where permitted, lock proposed CLC governance tokens to obtain stCLC;
3. realized eligible rake or service-fee receipts enter the Waterfall;
4. the Waterfall funds adopted priorities in order; and
5. only an enabled post-Waterfall policy issues sCLC or opens a capped fee-credit window.

No step creates ownership, repayment, withdrawal, coverage, reward, or governance rights beyond those expressly stated in the applicable terms.

## **8. Technical scope and growth**

This chapter describes optional or proposed work. It is not a list of features guaranteed to be present in the current CLC App or Protocol v1.1.0.

Possible work areas include:

- execution routing across compatible Pools, with registry, quote, limit, fee, and inventory discovery;
- timelocked escrow or HTLC adapters for cross-domain execution where atomic settlement is unavailable;
- interfaces and policy tools for small or personal Pools;
- auditable registries for vouchers, Pools, exchange-rate methods, limits, controllers, and fees;
- deployment-specific payment-provider connectors, checkout flows, and eligibility controls;
- fungible-asset connections to external liquidity venues for rebalancing and payment liquidity; and
- policy-capped treasury conversion for adopted coverage, operating costs, or liquidity mandates.

External-market prices would not determine what an issuer owes under voucher terms. A Pool could use a guarded external reference for a fungible asset, but its published exchange-rate method, limits, fees, and inventory would govern its quotes.

### **8.1 Proposed route-service and SDK norms**

**Discovery.** A proposed route service would query identified registries for asset admission, exchange-rate methods, limits, fees, inventory, incidents, and controller information. Cached records would include freshness bounds and source identifiers.

**Network profiles.** A client could support more than one registry root or policy profile. It would tell the participant which profile, counterparties, adapters, constraints, and responsible service operators a quote uses. A cross-profile route would need to satisfy every applicable hop's conditions.

**Path policy.** An accountable operator could exclude unsafe dependencies or counterparties and apply route-level caps, freshness requirements, and health criteria. These signals would support a decision; they would not guarantee fulfillment or protection from loss.

**Fees and limits.** A quote would itemize Pool fees, any additional current Protocol fee, and any separately proposed routing or service fee. Execution would reject expired quotes or breached bounds.

**Atomicity and recovery.** Multi-hop execution would be atomic where possible. Where it used HTLCs or escrow, the service would disclose timeouts, abort paths, responsible controllers, incident procedures, and residual risks.

**Proposed batch netting and rebalancing.** An opt-in service might collect rebalance intents and search for compatible cycles or chains. It would:

1. publish a machine-readable receipt identifying executed cycles, assets, amounts, valuation timestamps, and fees;
2. enforce adopted per-period caps and counterparty policies;
3. reject activity that breaches any participating Pool's authorization, limits, or available inventory; and
4. preserve deterministic inputs and receipts for review and dispute handling.

**SDK requirements.** An SDK for executed routes would provide deterministic quote-to-receipt mapping, per-hop invariant checks, understandable failure codes, and audit-friendly logs. The current Protocol v1.1.0 `SwapRouter` provides quotes only; it does not execute these proposed routes.

#### **8.1.1 Minimum confederation compatibility specification**

A Pool ecosystem seeking cross-profile routing would publish machine-readable information for:

1. **Registry roots:** identifiers for assets, Pools, exchange-rate methods, limits, and fee policies, or one root that deterministically resolves them.
2. **Receipts:** the profile, assets in and out, amounts, quote source and timestamp, limit snapshot, fees, inventory result, and execution outcome for every hop.
3. **Operational signals:** freshness-bounded information about inventory, limit utilization, incidents, and any separately evidenced fulfillment or funded protection.
4. **Policy constraints:** allowed or denied counterparties, asset classes, adapters, and any escrow requirements.
5. **Failure codes:** deterministic explanations for rejection, expiry, limit, inventory, policy, dependency, or incident failures.

A profile could add coverage, compliance, arbitration, or other services without making them requirements for basic CPP compatibility. Each optional service would identify its responsible party, authority, scope, and terms.

### **8.2 Licensing, verification, and exit**

Protocol v1.1.0 contracts are EVM-compatible. Contracts in the Protocol repository's `src` directory are published under AGPL-3.0 except for identified unmodified third-party components that retain their own terms. Published source, ABIs, and deployment instructions support independent review but do not by themselves prove an audit, safe deployment, or legal compliance.

Each deployment would separately disclose its code version, build provenance, addresses, controller and upgrade powers, audit status, registry mirrors, and any timelock or pause protections.

A proposed **fork kit** could include:

1. deterministic deployment scripts;
2. registry snapshot and export tools;
3. a documented process for repointing route services, SDKs, and interfaces to a new registry root;
4. a Pool Steward checklist for leaving a shared registry safely; and
5. a migration checklist for outstanding vouchers, including issuer notices, presentment and fulfillment deadlines, continued access to records, and remedies.

Compatible forks can improve resilience when communities, cooperatives, public agencies, federations, multisigs, or service operators need different governance. Actual continuity still depends on contract ownership, keys, dependencies, interfaces, infrastructure, legal obligations, and third-party services.

## **9. Proposed economics for liquidity programs**

This chapter describes a future, separately adopted model. It is not a current App feature, an offer, a promised return, or a right created by depositing into `SwapPool`.

### **9.1 Proposed revenue sources**

A future network budget could receive:

1. a disclosed **network rake** taken as a share of participating Pools' collected fees;
2. separate routing or service fees from implemented shared services; and
3. other expressly adopted, received revenue.

Gross Pool fees retained by Pools are not network revenue. Current Protocol v1.1.0 uses a different model: an optional protocol fee is additional to the Pool fee and is sent directly to its configured recipient.

### **9.2 Illustrative rake math**

If a participating Pool charges a 2.00% Pool fee and an adopted network rake receives 20% of that Pool fee, the proposed effective network-rake rate on routed value is:

`rake_rate = 2.00% × 20% = 0.40% = 40 bps`

If 25% of received rake and service-fee assets are eligible and convertible for a stated cash-denominated use after costs, the cash-usable share of the 40-bps rake is approximately 10 bps.

Proposed network revenue is:

`network_rake_received + routing_or_service_fees_received`

Do not add gross Pool fees to the network rake: the rake is a transfer from those fees and would otherwise be counted twice.

### **9.3 Liquidity-program rights**

A separately adopted program could fund Pool inventory, routing services, monitoring, or other mandates. Its terms would need to disclose:

- whether a transfer is a gift, endowment, loan, recoverable contribution, or purchase;
- custody and control;
- withdrawal, repayment, loss, and priority rules;
- fee and reward eligibility;
- governance rights;
- valuation and reporting methods; and
- suspension, termination, and remedies.

The current `SwapPool` creates no Pool-share token or automatic contributor entitlement. Any ex-post metric must be based on realized receipts and losses, must not be presented as promised yield, and may be zero or negative.

## **10. Comprehensive risk framework**

This proposed framework separates ten risk categories. For each category it identifies possible indicators, controls, stress tests, and an indicative risk appetite. These are design recommendations, not claims that every control is deployed, effective, or sufficient. Limits, reserves, guarantees, monitoring, coverage, and governance cannot eliminate loss.

### **10.1 Protocol and smart-contract risk**

- **Threats:** contract bugs, upgrade errors, dependency failures, and misconfigured limits or fees.
- **Indicators:** audit findings, unexplained inventory movements, invariant failures, and unusual reverts.
- **Possible controls:** independent audits; minimal privileged roles; disclosed proxy and dependency controllers; timelocked upgrades; on-chain monitoring; incident pauses with published authority and criteria; and a tested migration path.
- **Stress tests:** unavailable quote or limit dependencies, inventory shortfalls, paused contracts, and burst traffic.
- **Risk appetite:** low before scaling outstanding obligations or swap volume.

### **10.2 Economic and market risk**

- **Threats:** thin inventory, one-sided flows, rapid withdrawals, and manipulated or stale price references.
- **Indicators:** high Pool token-balance-cap utilization, widening quote differences, frequent limit rejections, and concentrated inventory.
- **Possible controls:** current Pool token-balance caps; proposed rolling or account limits; separately adopted reserves; guarded price references; route exclusions; and time-limited incident fees or limits.
- **Stress tests:** large reference-price moves, presentment surges, withdrawal requests, and data-source outages.
- **Risk appetite:** moderate only within published parameters and funded loss-bearing capacity.

### **10.3 Issuer and voucher risk**

- **Threats:** issuance beyond fulfillment capacity, issuer default, misleading terms, and poorly specified availability or presentment windows.
- **Indicators:** declining confirmed-fulfillment rates, aging outstanding vouchers, unresolved complaints, and concentrated exposure to one issuer.
- **Possible controls:** issuer due diligence; clear voucher and Offering terms; issuance or admission limits; independently funded bonds or guarantees; cohort reporting; and accountable registry review.
- **Stress tests:** issuer insolvency, regional production shocks, counterfeit claims, and prolonged fulfillment delays.
- **Risk appetite:** lower as issuer or Offering concentration increases.

### **10.4 Redemption-presentment and fulfillment risk**

- **Threats:** invalid or duplicate presentment, insufficient issuer capacity, stockouts, logistics failures, and missing discharge records.
- **Indicators:** request-to-fulfillment latency, failed or disputed presentments, stockouts, ticket backlogs, and fulfilled units lacking discharge.
- **Possible controls:** published presentment and fulfillment procedures; capacity disclosures; multiple fulfillment venues where lawful; evidence standards; complaint and remedy paths; and records separating presentment, fulfillment, and discharge.
- **Stress tests:** two-to-four-times presentment volume, facility outages, supplier failures, and duplicate-use attempts.
- **Risk appetite:** low where essential goods, vulnerable participants, or long fulfillment windows are involved.

### **10.5 Governance risk**

- **Threats:** Steward or controller capture, rushed parameter changes, conflicts of interest, hidden technical powers, and weak appeals.
- **Indicators:** concentrated authority, frequent emergency actions, unexplained policy changes, and repeated overrides.
- **Possible controls:** role-and-power disclosures; proportional approval thresholds; timelocks; conflicts and recusal rules; public change records; appeals; automatic emergency-power sunsets; and forkability.
- **Stress tests:** adversarial proposals, signer loss, bribery attempts, and capture through accumulation or delegated control.
- **Risk appetite:** low for actions affecting value methods, withdrawals, registry roots, coverage, or emergency powers.

For a future deployment of the proposed CLC governance token, the capture test would include accumulation followed by attempts to redirect budgets, weaken registry standards, approve related-party mandates, or drain funded coverage. Possible safeguards include governance lockups, higher thresholds for critical actions, delayed execution, transparent delegation and concentration monitoring, an incident process, and a credible fork-and-exit procedure. None is represented as deployed merely by appearing here.

### **10.6 Legal and compliance risk**

- **Threats:** a voucher, service, promotion, or governance asset receiving unexpected regulatory treatment; consumer-protection failures; money-laundering or sanctions exposure; and cross-border restrictions.
- **Indicators:** jurisdiction flags, regulator inquiries, complaints, restricted-party matches, and divergence between advertised and actual behavior.
- **Possible controls:** review by class and jurisdiction; accurate disclosures; geofenced interfaces; proportionate eligibility or attestation checks; promotion controls; records of authority and acceptance; and clear responsible parties.
- **Stress tests:** a jurisdictional restriction, provider termination, mandatory reclassification, and an order to pause a feature or asset class.
- **Risk appetite:** low; restrict or pause unsupported activity.

#### 10.6.1 Legal positioning and proposed-token treatment

1. **Verifiable infrastructure:** Protocol v1.1.0 contracts are EVM-compatible and their source is published under the licences and third-party exceptions identified in the Protocol repository. Publication enables review but does not itself prove an audit, safe deployment, or legal compliance. Each deployment should disclose its code version, build provenance, addresses, controller powers, and audit status.
2. **Proposed-token posture:** in this design, the proposed CLC governance token would coordinate governance and policy-gated access. It would not create dividends, profit sharing, residual rights, or a guarantee of value or liquidity.
3. **Related proposed assets:** a separately implemented policy might allow locking the proposed CLC governance token to mint stCLC and might authorize epoch-scoped sCLC. The adopted terms would need to define their exact rights, limits, expiry, transferability, and treatment.
4. **Communications:** materials for any proposed CLC governance-token, stCLC, or sCLC deployment should not promise profit, appreciation, passive income, or guaranteed access.
5. **Jurisdiction controls:** a deployment might require interface geofencing, attestations for restricted classes, promotion limits, asset-specific review, or controls that pause a proposed feature.
6. **Participant notice:** adopted terms would explain when access can be reduced or disabled for legal, operational, or risk reasons and whether any compensation or remedy applies.

### **10.7 Routing and cross-domain risk**

- **Threats:** partial execution, stuck hops, bridge or escrow exploits, stale quotes, path inflation, and front-running of announced value changes.
- **Indicators:** route-expiry rates, escrow backlogs, quote-to-execution differences, repeated unnecessary hops, and bridge incidents.
- **Possible controls:** atomic execution where available; conservative HTLC or escrow timeouts; path and counterparty policies; route-level caps; deterministic quote-to-receipt mapping; and accountable service operators.
- **Stress tests:** a bridge halt, chain reorganization, dependency outage, and one failed hop in a proposed multi-hop route.
- **Risk appetite:** low to moderate only for identified and monitored dependencies.

### **10.8 Custody and key-management risk**

- **Threats:** lost or compromised keys, signer collusion, and unclear recovery or administrator authority.
- **Indicators:** anomalous signatures, controller changes, failed rotations, and unusual withdrawals.
- **Possible controls:** multisig or threshold authorization; hardware-backed keys; role separation; signer rotation; public controller inventories; monitored withdrawal limits; and tested recovery procedures.
- **Risk appetite:** low.

### **10.9 Reputation and social risk**

- **Threats:** misleading claims, harmful incentives, inaccessible complaints, poor fulfillment experiences, privacy failures, and protections that favor insiders.
- **Indicators:** complaints by cohort, unresolved disputes, issuer-performance trends, concentration of benefits or losses, and community feedback.
- **Possible controls:** plain-language disclosures; grievance and correction paths; accessible evidence; transparent reporting; incident review; and proportionate sanctions for misrepresentation.
- **Risk appetite:** low, with particular care for affected communities and vulnerable participants.

### **10.10 Concentration and fragmentation risk**

- **Threats:** dependence on a small number of issuers, Pools, controllers, providers, networks, or incompatible forks.
- **Indicators:** concentration measures by issuer, Pool, inventory, controller, or service provider; route failures between clusters; and critical single dependencies.
- **Possible controls:** published concentration thresholds; multiple accountable operators; compatible standards; independent registries; tested exit procedures; and safe interoperability.
- **Stress tests:** loss of the largest issuer, Pool, operator, provider, or registry root.
- **Risk appetite:** deployment-specific and disclosed, with stricter limits for essential services or irreplaceable dependencies.

## **11. Governance mechanics**

This chapter proposes a governance template. It does not represent that the current CLC App uses governance-token voting, timelocks, shared insurance, a claims process, or every control described below. Each deployment would need to identify its actual decision-makers, authorities, contracts, processes, and policies.

- **Constitutional values:** care for people, care for the environment, fairness, reciprocity, non-dominance, and resilience.
- **Proposal types:** fee, limit, and index changes; liquidity mandates; Pool listings and removals; optional coverage decisions; and parameter guardrails.
- **Accountable process:** intake → evaluation → risk review → approval → timelock where appropriate → execution. Approval may come from stewards, cooperatives, public agencies, federations, multisigs, on-chain voting, or another disclosed and accountable structure.
- **Approval thresholds:** parameterized by action class, with higher thresholds for value-index changes, emergency powers, and other critical actions.
- **Delegation:** optional delegation with public mandates, conflicts disclosures, and recall.
- **Circuit breakers:** emergency pauses with stated criteria, authorized operators, resume conditions, and required post-mortems.
- **Transparency:** published changes and flows, with separate evidence for swap settlement, issuer fulfillment, reserves, limit utilization, routing, and guarantors.

**Registry governance.** A CPP-compatible deployment may maintain discovery registries for vouchers, tokens, and Pools. Authorized controls may add, update, suspend, or remove registry entries through the deployment's disclosed governance process. Registry removal affects discovery and routing through that registry; it does not by itself erase a token, alter a holder's balance, discharge an issuer's obligation, or disable an otherwise functional contract.

Published registry rules should make status conditional and may identify repeated non-fulfillment, fraud or misrepresentation, unsafe contract behavior, or persistent violation of published principles as grounds for suspension or removal. Where feasible, the process should provide notice, an opportunity to remedy, and an appeal path. Emergency removal should require a public incident report and automatic review or sunset.

**Prohibited listings.** Under this template, a registry would not admit:

1. instruments that directly fund or incentivize ecological destruction beyond agreed boundaries, violence or weaponization, coercive extraction, or systemic abuse; or
2. a voucher class that lacks clear presentment and fulfillment terms, accountability, and remedy paths.

The prohibited list would be versioned, publicly auditable, and changeable only through the adopted critical-action threshold and timelock, illustrated as Q3 + T3 in Appendix D.

### **11.1 Exchange-rate and limit governance**

**Timelocked changes.** A deployment following this template would change exchange-rate methods and separately implemented limit parameters only after a public timelock. An emergency path would use a separately disclosed authorization process and include an automatic sunset or review.

**Approval thresholds.** The template proposes higher approval thresholds for value-index base changes and global limit-tier changes, intermediate thresholds for Pool-specific third-party changes, and standard thresholds for routine fee changes.

**Published feeds.** A participating deployment would publish, for each Pool, the on-chain index variables, oracle sources or medians, update cadence, limit windows and caps, and failure modes or safe constants.

**Emergency-pause criteria.** A participating deployment would predeclare conditions such as an oracle outage, high limit utilization combined with fulfillment failures, or an invariant failure, together with resume checks and post-incident review requirements.

**Example public index feed for one Pool and voucher**

- **Symbol:** for example, `Maize_50kg@IssuerY`.
- **Reference unit:** Index Unit (IUX).
- **Published value:** 30.000 IUX.
- **Source:** median of identified sources, such as a local market survey, ministry bulletin, and deployment baseline.
- **Update cadence:** daily at 18:00 EAT, with a 24-hour timelock.
- **Failure mode:** freeze at the last valid value, apply a disclosed limit policy, and pause after a 72-hour outage.
- **Rationale:** published notes and a change record from the prior update.
- **Signers:** disclosed multisig addresses and approval threshold.

### **11.2 Proposed insurance-fund runbook**

**Optional design only.** This runbook applies only to a deployment that has expressly adopted and funded an insurance fund and published the covered events, eligible claimants, responsible entity, assets, limits, exclusions, evidence requirements, process, and governing terms. Neither the current CLC App nor GEF provides coverage merely because this design appears in the White Paper.

**Possible triggers.** An adopted policy could cover defined issuer non-fulfillment, a Pool reserve shortfall, or a bridge or escrow loss. A technical incident does not qualify automatically; the applicable policy would control.

**Assessment.** The responsible body would reconcile transaction receipts, inventory balances, guarantor bonds, redemption-presentment records, issuer responses, and other required evidence, then publish an incident record consistent with privacy and law.

**Illustrative loss waterfall.** Where each layer exists and lawfully applies, a policy could use: (1) responsible issuer bonds or guarantor stakes → (2) Pool-level reserves → (3) a proposed network insurance fund → (4) a temporary reduction to an optional coverage claim, only where pre-existing terms and applicable law expressly authorize it → (5) lawful recovery for proven fraud or abuse.

A coverage adjustment does not reduce an issuer's underlying voucher commitment or alter an on-chain balance unless valid pre-existing terms and applicable law expressly permit that result and any required holder consent is obtained.

**Limits and exclusions.** Published coverage would define caps, eligible presentments, evidence, claim windows, excluded routes or events, geographic restrictions, and the treatment of exhausted reserves. A payout could be zero after applicable limits are reached.

**Illustrative recovery schedule.** If adopted and published:

1. claims would draw first from the responsible issuer or guarantor bond, then from applicable Pool reserves, then from the proposed network insurance fund;
2. any reduction to an optional coverage claim would be limited to what pre-existing coverage terms and applicable law authorize, up to the published incident cap;
3. a recovery plan could apply a stated share of recovered value for a stated period, after which any remaining covered shortfall would become a recorded loss with a public post-mortem; and
4. each decision would produce a receipt with the incident ID, affected claim and vouchers, decision, recovery plan, and appeal window.

### **11.3 Guarantor framework**

This section distinguishes issuer responsibility, optional Pool protections, and third-party guarantees. Pools can compete on curation, terms, and expressly offered protections without implying that the CLC App, CPP, GEF, or any wider network automatically guarantees a voucher.

**Baseline issuer responsibility**

- Each voucher is first and foremost its issuer's responsibility. The issuer commits to provide the stated good, service, or lawful cash-equivalent under its published terms.
- Issuers would publish who may present the voucher, what fulfillment means, where and when it is available, what evidence is required, and what remedies apply.
- If an issuer fails to fulfill, the issuer is the primary responsible party. Pool or network protections apply only when separately adopted, funded, and disclosed.

**Optional Pool protections**

A Pool Steward may choose to add a narrowly defined protection to admitted vouchers. It is not automatic and would need to identify the responsible party, funding, eligible events, caps, windows, evidence, exclusions, and remedies in Pool metadata and applicable terms.

Illustrative protection types include:

1. **Reserve-asset coverage:** after verified issuer non-fulfillment, the responsible Pool entity pays a defined amount in a designated reserve asset, subject to its published cap and available funded reserves.
2. **Swap-back window:** after a qualifying event, the Pool offers a time-limited swap path into the prior or another approved asset, subject to caps and inventory. This is an inventory-dependent liquidity protection, not a promise that every swap is reversible.
3. **Alternative fulfillment:** the responsible party arranges an approved substitute provider within a published quantity or value cap.
4. **Exchange-rate-band protection:** for selected voucher classes, a Pool offers only the coverage adjustment or swap-back remedy stated in its pre-existing terms. This does not reduce the issuer's underlying voucher obligation.

**Possible funding sources**

- **Issuer bond:** collateral posted by the issuer or held in a disclosed reserve and available after a verified covered event.
- **Pool reserve:** assets controlled by the responsible Pool entity and allocated to the protections it advertises.
- **Third-party guarantor bond:** collateral posted by an identified external guarantor for stated issuers, voucher classes, or events.

Guarantor participation would follow published eligibility criteria, bond sizing, concentration limits, decision authority, and lawful enforcement rules.

**Claims process**

An adopted policy would define auditable triggers, such as a fulfillment deadline missed after valid redemption presentment, verified issuer insolvency, a covered bridge or escrow failure, or a formally declared incident state. It would also define:

- how a participant opens a claim and supplies the required presentment and fulfillment evidence;
- who verifies voucher terms, issuer responses, and technical records;
- the decision and appeal windows; and
- the authorized payout path, assets, caps, and receipt.

Recovery proceeds from issuers, arbitration, or lawful enforcement would refill the applicable bonds or reserves according to the published policy before being used for proposed CLC Network Pool swap access.

**Required disclosures**

For every covered Pool and voucher class, the responsible party would publish:

- whether a guarantor is absent, optional, or required;
- bond or reserve sizing and concentration caps;
- the protection types, assets, caps, windows, and exclusions;
- presentment, fulfillment, claim, and appeal deadlines; and
- a plain-language statement of who guarantees what and what is not guaranteed.

**Curation principle.** Pool Stewards and the responsible legal or governance structures are accountable for the protections they advertise. A CPP-compatible deployment may provide standards, registries, or optional shared policies, but neither CLC nor GEF automatically guarantees vouchers or Pools.

### **11.4 Anti-capture guardrails**

Under this template, the following would be critical actions requiring the adopted highest approval tier and a long timelock:

1. changing the proposed fee waterfall, including its coverage and core-operations priorities;
2. changing canonical registry roots;
3. changing coverage scope, claim caps, or decision authority;
4. expanding emergency-pause powers; or
5. weakening forkability, transparency, or Pool sovereignty commitments stated in this paper.

### **11.5 Fork and exit procedure**

If governance were captured or values drifted materially, communities, Pool Stewards, and operators could seek to exit by forking the network governance layer. Continuity of underlying Pools and vouchers would depend on the deployed contracts, keys, interfaces, infrastructure, third-party services, and applicable obligations.

An exit process could:

1. **Publish a snapshot:** export the selected registries, vouchers, values, limits, and fee policies, then publish a signed snapshot hash.
2. **Redeploy governance services:** deploy new registry roots, route services, and any adopted fee or coverage modules under a new accountable structure.
3. **Re-register:** allow Pool Stewards to opt in by registering their Pool addresses under the new root without requiring holders to migrate otherwise functional vouchers.
4. **Repoint clients:** add the new root as a selectable network profile in SDKs and interfaces, with any default change made through the disclosed governance process.
5. **Manage a bridge period:** maintain compatible routes where safe and deny routes that violate the new profile's rules.

The design objective is that leaving a canonical registry does not disable otherwise functional local Pools. Actual continuity remains deployment-dependent; federation is an opt-in discovery and coordination layer.

## **12. Proposed liquidity-program term sheet (non-binding outline)**

This is an illustrative checklist for a future, separately documented program. It is not an offer, a current App feature, or a promise of liquidity, access, insurance, return, value, or exit.



- **Eligible contributions:** stablecoins, reserve tokens, or approved community vouchers, as stated by the program.
- **Placement:** designated Commitment Pools or the proposed CLC Network Pool under a separately adopted mandate.
- **Lockup and exit:** program-specific terms, such as rolling 30–90 day periods and disclosed gates under stress.
- **Policy-gated fee credit:** an optional ex-post mechanism under published caps and windows, not a promised return.
- **Risk sharing:** any reduction to an optional coverage claim must be expressly authorized by pre-existing terms and applicable law. It does not itself change an issuer's voucher commitment or an on-chain balance.
- **Reporting:** periodic dashboards and attestations covering Pool health, inventory, limits, fees, and any funded coverage reserves.
- **Covenants:** use-of-proceeds constraints, oracle controls, limit tiers, conflicts rules, and remedies.
- **Possible proposed-token eligibility:** contributors who seed designated Pools might qualify for vested proposed CLC governance-token grants based on measured Pool-swap access and confirmed issuer fulfillment, subject to adopted terms, anti-gaming rules, and policy caps.


---

## **13. Plain-language glossary**

- **Cosmo-Local Credit (CLC):** The product family, including the CLC App, documentation, and wider commitment-pooling work.
- **CLC App:** The progressive web app operated by GEF at `cosmolocal.credit`.
- **Commitment Pooling Protocol (CPP):** The reusable model of curation, valuation, limitation, exchange, and accountable governance.
- **Protocol v1.1.0:** The verified public smart-contract release.
- **Commitment Pool:** A governed arrangement that admits supported assets and publishes exchange rules.
- **`SwapPool`:** The current token vault and direct-swap contract.
- **Token:** An on-chain balance or digital asset. Token mechanics alone do not create a redeemable promise.
- **Voucher:** A token or record represented by an issuer as a redeemable commitment under published terms.
- **Offering:** A catalog record for goods or services associated with a voucher.
- **Issuer:** The party responsible for publishing and fulfilling a voucher commitment.
- **Pool Steward:** The accountable structure that publishes and administers Pool rules.
- **Pool exchange rate or quote:** A transaction parameter produced by a configured quoter; not proof of cash or redemption value.
- **Pool token-balance cap:** The current `Limiter` maximum for a token held by a Pool. The App may label it **“Credit limit.”**
- **Pool swap:** A direct asset exchange through one `SwapPool`.
- **Swap settlement:** The on-chain transfers and fee accounting completing a Pool swap.
- **Redemption presentment:** Returning or otherwise presenting voucher units to the issuer.
- **Fulfillment:** The issuer provides the promised good, service, benefit, or other performance.
- **Discharge:** A record preventing fulfilled units from being presented again.
- **Proposed execution router:** Future software that would authorize and execute routes. The current `SwapRouter` quotes only.
- **Proposed CLC Network Pool:** A future network-level clearing and budget-coordination arrangement.
- **Proposed CLC governance token:** A future governance design, not a current App or Protocol v1.1.0 asset.
- **Network rake:** A proposed share of Pool fees transferred to a future network budget.
- **Guarantee or insurance:** A protection that applies only when an identified party expressly assumes, funds, and publishes it.

## **14. Proposed KPIs and health indicators**

A deployment should publish a KPI only when it can define the event, source, cohort or period, unit, valuation method and timestamp, exclusions, correction policy, off-chain evidence, and data-quality limitations.

Proposed measures include:

- valid redemption presentments;
- cohort-based fulfillment rate;
- discharge completeness;
- presentment-to-fulfillment latency;
- acquisition-to-presentment holding duration;
- outstanding eligible commitments under a stated methodology;
- completed Pool swap volume;
- measured Pool inventory;
- Pool token-balance-cap utilization;
- quote pass rate, kept separate from route execution rate;
- eligible reserves divided by expressly covered exposure;
- guarantor claims and recoveries under an identified policy;
- proposed network rake and service fees actually received, without double-counting gross Pool fees;
- governance detection, decision, pause, repair, and closure times;
- complaints, disputes, corrections, and remedies; and
- separately evidenced social or ecological outcomes.

On-chain transaction data does not by itself prove identity, issuer performance, satisfaction, causality, community health, or social impact. Those claims require their own methodology and evidence.

See [Appendix C](/white-paper/appendix-c-kpi-definitions) for the proposed measurement specification.

## **15. Roadmap (indicative)**

### **15.1 Current foundation**

GEF operates the CLC App at `cosmolocal.credit` on Gnosis Chain. The App provides supported account and wallet access, a public Market catalog, and interfaces for tokens, vouchers, Offerings, Commitment Pools, transfers, and direct Pool swaps.

Protocol v1.1.0 provides the current contract foundation: `GiftableToken`, direct `SwapPool` execution, optional registries, valuation modules, Pool token-balance caps, Pool fees, an additional protocol fee, and a quote-only `SwapRouter`. Availability still depends on the interface, deployed contracts, inventory, configuration, network state, eligibility, providers, jurisdiction, and published issuer or Pool terms.

### **15.2 Proposed milestones**

These named milestones are design directions, not release numbers, delivery dates, or commitments that a feature will launch.

- **Governance Foundation:** proposed CLC governance token; proposed CLC Network Pool; fee adapters; quorum, timelock, and governance foundations.
- **Routing & Observability:** Router SDK and registry APIs; health dashboards; a proposed insurance-policy framework; opt-in rebalance intents; batch-netting prototype.
- **Cross-Domain Risk Tools:** HTLC or escrow routing; separately governed guarantor modules; rolling, account, and tiered limit presets.
- **Regulated Access:** deployment-specific third-party payment services; personal micro-pools; compliance-service discovery; third-party audits of voucher classes.

Any payment service would be provided by separately identified third parties under the applicable jurisdiction, eligibility, fees, limits, and terms. The CLC App and Protocol v1.1.0 contracts do not themselves operate fiat rails.

Multi-hop execution, shared insurance, the proposed CLC governance token and proposed CLC Network Pool, batch netting, personal micro-pools, and regulated payment services remain proposed or deployment-dependent until an implementation and its governing terms identify them as active.

## **16. Proposed evaluation template**

A registry, Pool, or future liquidity program can adapt this template. It is not a current universal listing standard or guarantee.

1. **Observed facts:** issuer identity and history, voucher terms, Offerings, capacity evidence, Pool configuration, controllers, inventory, limits, reserves, guarantors, incidents, and unresolved obligations.
2. **Purpose and affected parties:** intended benefit, risks, conflicts, ecological and social effects, and who bears loss or responsibility.
3. **Valuation:** Offering price, voucher stated value, Pool exchange-rate method, oracle reference, units, timestamps, and reasons for any divergence.
4. **Boundaries:** eligibility, prohibited uses, concentration, token-balance caps, pauses, geographic or legal restrictions, and review triggers.
5. **Protections:** identified obligated party, covered event, funding, cap, exclusions, duration, evidence, claim process, and remedies.
6. **Decision:** approve, revise, reject, pause, or escalate for human review; identify the decision-maker, reasons, conditions, review date, and appeal or correction process.

The output should not describe curation, limits, reserves, or verification as endorsement, issuer capacity, insurance, or guaranteed fulfillment unless the responsible party has expressly established that protection.

## **17. Legal and compliance note**

CPP can coordinate tokens, vouchers, Pools, and swaps whose legal treatment depends on their design, marketing, use, responsible parties, and jurisdiction. Nothing in this White Paper is legal, tax, investment, credit, or financial advice.

Use of the CLC App is governed by the [Terms of Service](/governance/terms). GEF operates the App and supporting infrastructure. Unless GEF expressly assumes another role, it is not an issuer, Pool Steward, custodian, lender, borrower, broker, guarantor, redeemer, adviser, insurer, or party to obligations between participants.

Deployment-dependent payment services must identify their responsible provider, jurisdictions, eligibility, fees, limits, custody model, and terms. The presence of a connector does not mean that GEF or a Pool operates the underlying regulated service.

### **17.1 Voucher and Offering disclosures**

An issuer should publish and keep current:

- responsible identity and contact information;
- the associated Offering, unit, supply, stated value, and capacity;
- presentment locations and procedures;
- fulfillment timing and evidence;
- expiry, fees, taxes, restrictions, and material-change rules;
- complaints, substitutions, refunds, or other remedies; and
- the discharge method preventing reuse after fulfillment.

A token contract does not establish these terms or prove performance.

### **17.2 Pool disclosures**

A Pool Steward should publish:

- the Pool's purpose and accountable decision-makers;
- the `SwapPool` owner, proxy administrator, dependency controllers, and fee recipients;
- admitted assets and suspension or removal rules;
- valuation methods, quote sources, fees, token-balance caps, inventory, and owner-withdrawal powers;
- contribution and exit rights;
- every reserve, guarantee, guarantor, insurance policy, and loss-allocation rule; and
- governance, upgrade, emergency, complaint, migration, and termination processes.

Listing is not endorsement, valuation, insurance, or a guarantee by GEF.

### **17.3 Actions and obligations**

An ordinary **Pool swap** exchanges supported assets under a displayed quote and transaction bounds. Asset direction does not make it a loan, repayment, issuer redemption, or real-world fulfillment.

**Redemption presentment** returns or presents voucher units to an issuer. **Fulfillment** is the issuer's promised performance. **Discharge** records fulfilled units so they cannot be reused. The App's **“Redeem”** action currently prepares a transfer to the token owner; that transfer alone does not prove fulfillment.

The App's **“Retire voucher”** action is reversible catalog unlisting. It does not burn balances, cancel claims, or discharge obligations.

A future loan or other credit product would require separately presented supplemental and transaction terms before use. No ordinary send, contribution, Pool deposit, Pool swap, presentment, fulfillment, or discharge creates a loan merely because of its direction or asset type.

### **17.4 Protections, evidence, and local law**

A limit, reserve, registry entry, App listing, or blockchain transaction is not automatically a guarantee or insurance policy. Any protection must identify its responsible party, covered event, funding, cap, exclusions, duration, evidence, claim process, and applicable terms.

Public-chain evidence can show addresses, assets, amounts, timestamps, and contract events. It does not by itself prove identity, issuer capacity, fulfillment, satisfaction, governance deliberation, legal discharge, or social impact.

Features may be restricted or unavailable because of law, sanctions, eligibility, contract state, inventory, limits, security, jurisdiction, or third-party services. Issuers, Pool Stewards, providers, and participants remain responsible for determining and complying with applicable law.

## **18. Conclusion**

Cosmo-Local Credit connects a current application and Protocol v1.1.0 foundation with a wider proposed design for independently governed Commitment Pools. Current direct Pool swaps, quote and limit components, and public transaction records can support accountable exchange, but they do not prove issuer fulfillment, create contributor rights, or guarantee value, liquidity, redemption, insurance, legal status, or protection from loss.

The proposed execution routing, netting, governance assets, network clearing, liquidity programs, and shared protections described in this paper would require separate implementation, funding, governance, and published terms. The design aims to expand interoperability while keeping issuer performance, Pool governance, and real-world accountability with identified parties.

## A. Proposed measurement and fee model

This appendix defines a proposed measurement framework. Protocol v1.1.0 does not record issuer fulfillment, real-world discharge, or every data field required below.

### Event and stock definitions

For voucher class *j*, cohort or period *t*, and a disclosed valuation method *m*:

- `O_{j,t,m}`: value of outstanding eligible commitments at the measurement boundary.
- `X_{j,t,m}`: value of completed Pool swaps during the period.
- `P_{j,t}`: units validly presented to the issuer for redemption.
- `F_{j,t}`: presented units with separately evidenced issuer fulfillment.
- `G_{j,t}`: fulfilled units with a discharge record preventing reuse.

`O` cannot be inferred from token supply alone. A measurement policy must identify the responsible issuer and exclude, as applicable, issuer-held inventory, burned units, expired units, discharged units, test balances, inaccessible balances, and tokens whose terms do not create an outstanding third-party commitment.

Each valued measure must publish the unit, source, valuation method, timestamp, and treatment of divergent Pool exchange rates. An on-chain transfer can support `X` or presentment evidence; it does not by itself establish `F` or `G`.

### Cohort-based fulfillment measures

For a cohort of valid redemption presentments:

`FulfillmentRate = FulfilledPresentments / ValidPresentments`

`DischargeCompleteness = DischargedFulfillments / FulfilledPresentments`

Use the same closed or mature cohort in each numerator and denominator. Report rejected, withdrawn, expired, disputed, partially fulfilled, corrected, and still-open presentments separately.

`FulfillmentLatency = median(t_fulfilled - t_presented)`

`HoldingDuration = median(t_presented - t_acquired)`

Fulfillment latency measures issuer service after presentment. Holding duration is a separate measure and must not be labelled redemption latency.

### Distinct velocity measures

A proposed commitment-discharge velocity may be calculated only where `O` and fulfilled value use the same valuation method:

`V_commit,t = FulfilledValue_t / AverageOutstandingEligibleCommitmentValue_t`

A Pool swap-activity measure is separate:

`V_swap,t = PoolSwapValue_t / AverageMeasuredPoolInventoryValue_t`

Neither value proves social impact, issuer capacity, profitability, or cash convertibility.

### Proposed network revenue

Let:

- `PF_t` be gross Pool fees generated during the period;
- `NR_t` be the proposed network rake actually received as a disclosed share of those Pool fees;
- `RF_t` be separate proposed routing or service fees actually received; and
- `χ_t` be the measured share of received revenue that is eligible and convertible for a stated cash-denominated use after costs and policy constraints.

From the proposed network-budget perspective:

`ProposedNetworkRevenue_t = NR_t + RF_t`

`CashUsableNetworkRevenue_t = χ_t × (NR_t + RF_t)`

Do not add `PF_t` to `NR_t`: the rake is a transfer from gross Pool fees and would otherwise be counted twice. Current Protocol v1.1.0 instead supports an additional protocol fee; its receipts must be reported separately from this proposed rake model.

## B. Illustrative future fee waterfall

This is a proposed design for a future deployment. It applies only if implemented, funded, and adopted through published governance and participant terms. It does not describe a current Protocol v1.1.0 fee, contributor right, reserve, guarantee, or insurance arrangement.

Let `F_in` be revenue actually received by the proposed network budget during an epoch: the proposed network rake, separate routing or service fees, and any other expressly designated revenue. Gross Pool fees that remain with Pools are not included.

Revenue assets must be classified as:

- `E_cash`: assets eligible for a stated cash-denominated use under the adopted policy; or
- `E_kind`: in-kind vouchers or other assets that are not treated as cash-convertible.

Any conversion policy would need asset and venue allowlists, responsible authorities, price sources, slippage limits, reporting, and applicable legal controls.

A proposed waterfall could apply received revenue in this order:

1. **Covered reserve target:** fund an adopted reserve or insurance target based only on defined covered exposure, eligible assets, exclusions, and claim rules.
2. **Core operations:** fund a disclosed, capped operating budget.
3. **Liquidity mandates:** fund approved, separately governed Pool or routing programs.
4. **Remaining budget:** allocate any remaining amount among operations, liquidity programs, and an additional buffer under published caps.

A reserve target is not itself a guarantee. Any insurance or guarantee must identify the obligated party, covered event, funding, cap, exclusions, duration, evidence, claim process, and loss allocation.

**Guardrail:** Waterfall allocations are intended for adopted coverage, operations, and liquidity services. They must not be framed or executed as price-support operations.

Under the proposed model, any proposed CLC governance tokens acquired through a separately enabled external-liquidity program would be retired or placed in a disclosed non-voting sink. This mechanism is not deployed.

## C. Proposed KPI definitions

These KPIs form a proposed measurement specification, not a statement that the current App or Protocol records every required event.

Every published KPI must include:

- responsible publisher and data source;
- event or state definition;
- cohort or measurement period;
- unit and valuation method;
- valuation timestamp;
- inclusion and exclusion rules;
- treatment of partial, disputed, expired, inaccessible, and corrected records;
- required off-chain evidence or attestation;
- revision history and data-quality limitations; and
- whether the result is on-chain, reported, attested, independently verified, or estimated.

| KPI | Proposed definition | Required evidence and exclusions |
| --- | --- | --- |
| **Valid presentments** | Count or units accepted into the issuer's redemption process during a period | Presentment identifier, issuer, holder authorization, amount, time, status; exclude duplicates and invalid requests |
| **Fulfillment rate** | Fulfilled valid presentments divided by valid presentments for the same mature cohort | Separate issuer-performance evidence; report open, rejected, disputed, partial, and corrected cases |
| **Discharge completeness** | Fulfilled presentments with a discharge record divided by fulfilled presentments | Burn, cancellation, disabling record, or other non-reuse evidence tied to the fulfillment |
| **Fulfillment latency** | Median and 90th percentile of presentment-to-fulfillment time | Do not substitute issue-to-presentment or acquisition-to-presentment holding time |
| **Holding duration** | Median and distribution of acquisition-to-presentment time | Identify the acquisition event and exclude unknown acquisition times |
| **Outstanding eligible commitments** | Eligible third-party commitments remaining after defined exclusions | Issuer identity and terms; exclude applicable issuer inventory, expiry, burn, discharge, tests, and non-commitment tokens |
| **Pool swap volume** | Value of completed direct Pool swaps under one disclosed valuation method | On-chain settlement events, token units, rate source, time; do not classify as issuer fulfillment |
| **Pool inventory** | Measured supported assets held by a Pool at a stated time | Contract balances, fee reservations, inaccessible assets, valuation method, and owner-withdrawal powers |
| **Reserve adequacy** | Eligible, available reserve assets divided by expressly covered exposure | Coverage policy, asset eligibility, custody/control, liabilities, exclusions, and valuation; not total token supply by default |
| **Limit utilization** | Measured Pool token balance divided by its current configured cap | Limiter address, token, Pool, timestamp, changes, and periods without a limiter |
| **Quote pass rate** | Successful quote responses divided by valid quote attempts | Quote-only result; not route execution |
| **Route execution rate** | Completed multi-hop executions divided by valid execution attempts | Applicable only to an implemented execution system; report per-hop and atomicity rules |
| **Guarantor recovery** | Eligible recovery received divided by covered claims paid | Identified guarantor, claim policy, timing, costs, disputes, and write-offs |
| **Proposed network revenue** | Proposed network rake received plus separate routing/service fees received | Exclude gross Pool fees retained by Pools and avoid counting the rake twice |
| **Governance timeliness** | Time to detect, decide, pause, repair, and close an incident | Defined clocks, responsible bodies, emergency powers, appeals, and missing events |

Social-impact claims require a separate methodology. Blockchain activity alone does not establish identity, issuer performance, satisfaction, community health, causality, or impact.

## D. Proposed launch parameters

Every value below is illustrative. It is not a current App default, Protocol v1.1.0 setting, guarantee, offer, or delivery commitment. A future deployment would need to adopt, enforce, monitor, and publish its actual parameters.

- **Quorum tiers for the proposed CLC governance token:**
  - Q1 routine: at least 4% quorum and more than 50% approval.
  - Q2 sensitive: at least 10% quorum and at least 60% approval.
  - Q3 critical: at least 20% quorum and at least 66.7% approval.
- **Proposed timelocks:**
  - T1: 48 hours for Q1 actions.
  - T2: 7 days for Q2 actions.
  - T3: 30 days for Q3 actions.
- **Epoch cadence:** 7 days, including any adopted voting, budget publication, and proposed sCLC windows.
- **Emergency pause:** immediate through an identified emergency authority, expiring after 72 hours unless ratified under the adopted process.
- **Proposed network rake:** 20% of participating Pool fees by default, bounded by policy.
- **Illustrative Pool fee range:** 0%–20%, published by each participating Pool.
- **Proposed routing or service fee cap:** 20 bps per route.
- **Proposed network-rake rate:** `rake_rate_p = pool_fee_p × rake_share_p`.
- **Revenue eligibility:** classify received assets as cash-eligible `E_cash` or in-kind `E_kind` under a published method.
- **Conversion controls:** asset and venue allowlists, responsible authorities, price sources, time windows, slippage limits, caps, and reporting.
- **Budget enablement:** publish a proposed fee-access budget only after adopted covered-reserve and operating targets are satisfied; the budget may be zero.
- **Risk lanes:** do not expose one asset class to another class's risk without explicit, informed opt-in under applicable law.
- **Proposed rolling and account limits:** deny unapproved cross-class activity and apply adopted caps.
- **Optional coverage reduction:** only where pre-existing coverage terms, required consent, and applicable law authorize it; it does not by itself reduce an issuer's voucher commitment or an on-chain balance.
- **External-liquidity controls, if separately enabled:** publish venue scope, measurement method, triggers, spend and volume caps, execution controls, emergency stops, and receipts. Do not present the program as token-price support.

Current Protocol v1.1.0 Pool fees, additional protocol fees, and Pool token-balance caps remain governed by the deployed contracts and configuration, not these proposed values.

## E. Worked example — proposed network rake

This example illustrates the proposed rake model. It is not the additional protocol-fee calculation used by Protocol v1.1.0.

Assume:

- a participating Pool charges a 2.00% Pool fee;
- the proposed network rake receives 20% of that Pool fee; and
- 25% of the received rake is eligible and convertible for a stated cash-denominated use after costs.

The effective proposed network-rake rate on routed value is:

`rake_rate = 2.00% × 20% = 0.40% = 40 bps`

The cash-usable portion under the assumed 25% eligibility factor is:

`cash_usable_rate = 40 bps × 25% = 10 bps`

If a proposed network budget has a monthly cash-denominated requirement of $150,000 and no other revenue, the illustrative routed value required at a 10-bps cash-usable rate is:

`required_routed_value = $150,000 / 0.001 = $150,000,000 per month`

This calculation does not include gross Pool fees retained by Pools. Adding those fees to the network rake would double-count the rake source.

A real budget analysis would also need to publish:

- actual rake and service-fee receipts;
- asset eligibility and conversion costs;
- Pool participation and route scope;
- adopted reserve and operating targets;
- losses, disputes, corrections, and unavailable assets; and
- sensitivity scenarios rather than promised growth or returns.

Any proposed fee-access or liquidity-program budget would remain downstream of its adopted priorities and could be zero.

## F. Dataroom checklist

1. **Historical Sarafu Network evidence**
   - Archive dated swap volume, active-user and asset definitions, incidents, redemption presentments, aging vouchers, confirmed fulfillment, discharge, holding-duration measures, periods, exclusions, and methodology separately from current Cosmo-Local Credit metrics.
   - Preserve the [historical Dune Analytics dashboard](https://dune.com/grassrootseconomics/sarafu-network).

2. **Proposed fee-enforcement evidence, if implemented**
   - Show that any fee hook and registry gating are integrated into the executed transaction path rather than enforced only by an interface.
   - Provide tests showing that the applicable execution service rejects a hop whose receipt does not prove fee collection under the adopted policy.
   - Publish test vectors, failure cases, eligible assets, and compliant Pools tied to an identified registry version.
   - Link the applicable [software description](https://software.grassecon.org).

3. **Guarantor and coverage pack**
   - Publish eligibility, responsible parties, funding, caps, premiums where applicable, triggers, evidence, exclusions, decision authority, and dispute and appeal examples.
   - Include sample voucher and Pool disclosures that distinguish issuer responsibility from any expressly offered Pool protection or third-party guarantee.
   - Preserve the [historical Sarafu Network reports archive](https://sarafu.network/reports) and [historical year-in-review presentation](https://youtu.be/5yGaP31bvs0?si=fZ-AMTEXsmVR8Ulv) as lineage evidence, not proof of current CLC coverage or adoption.

4. **Legal and compliance pack**
   - Document jurisdiction strategy, voucher classes, cash-equivalent policies, KYC or attestation options, geofencing, consumer disclosures, mis-selling controls, and the distinction between an ordinary Pool swap and an express credit product.
   - Link the effective [Cosmo-Local Credit Terms of Service](/governance/terms) and preserve superseded versions through controlled records.

5. **Governance hardening**
   - Provide conflict-of-interest and recusal procedures, decision and appeal records, sanctions, registry-removal due process, emergency-power limits, and examples of timelocked exchange-rate and limit changes.

6. **Source and assurance pack**
   - Publish the source and licence inventory, deployed addresses and versions, available audit reports, invariants, build provenance, administrator powers, incident contacts, and monitoring dashboards.
   - Link the applicable [Grassroots Economics repositories](https://github.com/grassrootseconomics).

# White Paper archive

The current publication is [Cosmo-Local Credit White Paper v0.8](/white-paper), dated 30 September 2026.

## Superseded version

- <a href="/white-paper/Cosmo-Local-Credit-CLC-White-Paper-v7.pdf">Version 0.7 PDF</a>, dated 24 September 2026

Version 0.7 is preserved for historical reference. Its vocabulary, status descriptions, formulas, and proposals are superseded by v0.8 and should not be used as the current description of the CLC App, Protocol v1.1.0, participant rights, or proposed network economics.

Version 0.6 has been removed from the public site. Its history remains available through the documentation repository.