Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

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.

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