At Grassroots Economics Foundation, we spend a lot of time doing health checks on commitment pools: from university student loan pools and village savings-and-loan circles, to refugee camp mutual aid programs and neighborhood regenerative funds.

To make sense of all these different sorts of pools, it helps to start with something familiar: credit unions and village savings and loan associations (VSLAs).

From there, we can peel away the branding (SACCO, Mweria, ROLA, “impact fund”) and look at the common functional mechanisms. That functional view leads us directly into the commitment pooling protocol and its four minimal interfaces. Once we share that language, it becomes much easier to talk about evaluation frameworks in a grounded way.

Familiar cousins: credit unions and VSLAs

Credit unions and VSLAs are member-owned financial cooperatives. People bring in savings, the union extends credit back out to members, and any surplus is shared or reinvested. What matters structurally is:

• Members are both the source of funds and the main beneficiaries.

• There is some form of governance (board, bylaws, audits).

• Members contribute small, regular savings (“shares”) into a common pot.

• The group extends loans to members with agreed caps and terms.

• There are limits and rules for borrowing and repayment.

• At the end of a cycle, there is a share-out based on how much each member has contributed and how the loans performed.

• Health is tracked through core metrics: reserves, loan performance, member participation, and capital adequacy.

From a commitment pool perspective, we can see both as ways of pooling promises:

• “I promise to save regularly.”

• “I promise to repay when I borrow.”

• “We promise to govern this pool in a fair, transparent way.”

Commitment pools generalize this pattern and extends it beyond only pooling only national currencies while making it explicit and programmable.

From instruments to functions: the four stewardship roles

Instead of thinking in terms of “SACCO”, “VSLA”, “Mweria” or “credit union”, we can pull these instruments apart into four basic functions that any healthy pool needs:

1. Curation – What promises are we willing to host? “We accept this kind of voucher; we don’t accept that one.”

2. Valuation – How do we compare and price different promises? “One hour of tutoring equals X, one sack of maize equals Y.”

3. Limitation – How much is safe to issue or access, and over what windows? “Maximum per member is…, per month is…, per voucher is…”

4. Exchange – How do we actually move vouchers in and out of the pool, and keep records coherent? “You can seed this voucher into the pool and swap for that one, under these conditions.

In technical terms, these become interfaces that any digital or non-digital system can expose. A commitment pool is just these four stewardship functions turned into clear, auditable interfaces:

1. Curation → Commitment Registry

• What it is: A registry of which vouchers (can be any ERC20 standard token) are allowed in the pool.

• What it does:

  • List / delist vouchers.

  • Attach clear redemption terms (who, what, where, when, how much).

  • Store metadata (sectors, risk level, guarantors, fulfillment evidence).

This is where stewards say: “These commitments live here; these ones don’t.”

2. Valuation → Value Index Registry

• What it is: A value index that tells the pool how to compare vouchers against a reference unit (or vector of units).

• What it does:

  • Defines pricing rules: static table, oracle feed, or governance-defined formulas.

  • Allows different pools to value the same voucher differently.

  • Makes swaps computable: “If you seed X of your voucher, you can safely draw Y of another.”

This is where stewards say: “This is how much this promise is worth in our context.”

3. Limitation → Swap Limiter

• What it is: A limiter that caps how much can move, and how fast.

• What it does:

  • Can provide a credit line - this is how much a person holding approved vouchers can swap for other assets in a pool.

  • Sets per-voucher, per-account, and global caps.

  • Applies time windows (per day, week, cycle).

  • Prevents runs and arbitrage.

  • Shapes credit expansion and keeps the pool within ecological, social, and financial limits.

This is where stewards say: “Even if we trust you, this is how much we can safely flow right now.”

4 Exchange → Treasury (seed / swap executor)

• What it is: A treasury or vault that holds inventory and enforces the rules.

• What it does:

  • Custodies vouchers and other reserve assets.

  • Executes seed (moving a voucher into the pool) and swap (exchanging one voucher for another).

  • Optionally applies fees

  • Only executes if:

    • The voucher is curated (listed),

    • The value index clears,

    • The limits allow it,

    • The inventory is actually available.

  • Emits immutable receipts for every action.

This is where stewards say: “The pool will only move if all conditions are met, and we’ll keep a permanent memory of that movement.”

Human and technical together

For commitment pools, these interfaces are both human and technical:

• Humans (stewards, councils, boards) exercise:

  • Curation, Valuation, Limitation, Exchange as decisions and policies.

• Systems (ledgers, apps, blockchains, paper books) expose:

  • A Commitment Registry, a Value Index, a Swap Limiter, and a Treasury that enforce those decisions.

Hold this map in your head.
We’ll use this shared language when we talk about evaluation and health checks.

What we’re evaluating

Not every pool has the same risk profile.

A simple “vending machine” pool might just be one issuer offering their own vouchers in exchange for a stablecoin:

• “Send 100 of stable token, receive 100 of my service vouchers.”

This can be useful, but here the analysis is mostly about:

• That one issuer’s reliability.

• The off-ramp and backing of the stablecoin.

For Grassroots Economics and Sarafu.Network (our implementation of these protocols), we are usually more interested in:

• Networks of pools

• Aggregate pools that route between many micro-pools

• Mutual credit-like structures where multiple issuers seed and swap promises with each other.

• Thematic pools where credit access is based on specific kinds of vouchers and activities - like bioregional ecosystem restoration.

These are the pools where the four interfaces really matter, and where over-exposure to any one voucher or even a stablecoin is a critical risk signal. That’s the context for our evaluation frameworks.

Evaluation frameworks for Sarafu.Network

Sarafu.Network is a specific (and quite general) implementation of the commitment pooling protocol. It makes the four interfaces visible in software and gives communities tools to:

• Tokenize commitments as vouchers (like gift cards with specific offers),

• Seed those vouchers into pools,

• Swap across a value index,

• Apply limits and fees,

• And track fulfillment over time.

Within Sarafu.Network, we can look at evaluation from two key angles:

1. Pool Stewards – evaluating who gets access and which vouchers are allowed into a pool.

2. Pool Supporters – evaluating where to add liquidity, i.e., which pools are healthy enough to back with further support or reserves without creating dependency or imbalances.

Here’s the basic shape of those evaluations:

For Pool Stewards: evaluating applicants wanting pool access

Stewards are the guardians of the Commitment Registry, Value Index, and Swap Limiter. When someone wants their voucher listed or wants deeper access to a pool, stewards can ask:

Curation questions

• Is the commitment clear? (who/what/where/when/how much/fallback)

• Does this type of voucher belong in this pool’s purpose and ecosystem?

• Is it valuable to this network - are the specific offers of goods or services backing this voucher valuable to the network?

• Is there any evidence of past fulfillment or relevant track record?

Valuation questions

• How will this voucher be valued in the pool’s index?

• Is that value backed by realistic capacity (labor, goods, reserves)?

• How volatile is the underlying commitment? Do we need safety margins?

Limitation questions

• What per-voucher caps are appropriate?

  • As a rule of thumb we generally don’t grant a credit line for more than 3-5x the amount seeded of that voucher.

  • Note that vouchers can be listed and aded tot he pool for some time before granting credit limits - to see if there are pool members that are interested.

• What time windows (per day/week/cycle) keep flows healthy?

• How does this new voucher affect concentration risk?

Exchange & behavior questions

• How will this agent swapping these vouchers likely use those resources? Mostly to support others, for consumption, to grow their offerings, or mostly to extract?

• Are there safeguards against circular swapping and artificial volume (like swap fees)?

In short: Does admitting this voucher and its issuer make the pool stronger, more diverse, and more resilient - or more fragile?

For Pool Supporters: evaluating where to add liquidity

Pool supporters (donors, solidarity funds, aligned DAOs, development agencies, community treasuries) are asking a different question:

“If we seed liquidity here, is this pool using commitment pooling in a way that warrants and grows trust?”

Their evaluation focuses on pool-level health:

Curation health

• Are voucher types curated with care, or is “anything goes”?

• Are redemption terms transparent and realistic?

Valuation health

• Is the value index documented and understandable? (e.g. are that using USD as their unit of account?)

• Are there visible distortions (e.g., one voucher valued unrealistically high)?

Limitation health

• Do limit settings look prudent, or are they wide open?

• Is there evidence of over-extension or repeated limit adjustments to chase more flow?

Exchange / treasury health

• Are there clear, auditable receipts for seed/swap activity?

• Are there validated reports / posts on the quality of vouchers in the pool?

• Is the inventory diversified, or dangerously concentrated in a single voucher or stablecoin?

  • We are hesitant to seed stable coins if their holdings in the pool represent more than 25% of the total assets there.

  • See gridlock conditions:
    

• Are fees (if any) routed to community-beneficial destinations (e.g., a social fund)?

Relational & fulfillment health

• What is the redemption history and fulfillment rate?

• Are there social structures (circles, councils, elders, committees) dealing with disputes and delays?

• Does the pool align with Ubuntu, mutual aid, and ecological care, or is it trending toward extraction?

• Is the pool fulfilling it’s specific purpose - such ecosystem regeneration?

From a supporter’s perspective, a pool is a candidate for backing if:

• Its four interfaces are visible and coherent,

• Its concentration risk is managed,

• Its fulfillment record is strong,

• And its governance and culture lean toward reciprocity, not dominance.

*Note that we as well look keenly at whether a pool is suitable for adding to a registry of pools for discover-ability, routing and credit clearing.

Holding the map

Credit unions and VSLAs give us a familiar starting point: people pooling resources and promises to support one another.

Commitment pools, and Sarafu.Network in particular, make the underlying functions and interfaces explicit:

• Curation → Commitment Registry

• Valuation → Value Index Registry

• Limitation → Swap Limiter

• Exchange → Treasury

Once we’re talking in that shared language, it becomes much easier to:

• Design new mutual aid and regenerative finance structures,

• Compare very different pools using the same basic evaluation lenses,

• And support the pools that are truly routing trust, not extraction.