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

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 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. 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.

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 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 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

A holder reviews a voucher, its issuer, its terms, and associated Offerings.
A Pool admits supported assets and publishes its configuration and responsible authorities.
The holder obtains a quote and authorizes a direct Pool swap.
SwapPool performs on-chain swap settlement and accounts for Pool and protocol fees.
If the holder later chooses “Redeem” in the App, the App prepares a transfer to the token owner as redemption presentment.
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
Verified deployed contracts: Protocol v1.1.0
Historical evidence: 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 are retained only as clearly superseded historical publications.