Protocol overview

Conceptual overview. For field names and wire formats see Data model & spec.

1. The one-sentence version

Everything below unpacks one clause of that.

2. Attestations: binding a claim to a key

Today a certificate names an operation in prose: a business name, an RUC, a farm, a scope. It is addressed to auditors and buyers. Nothing in it can be mechanically checked by software.

An attestation is the same decision expressed as a signed statement about a key:

// Attestation, abbreviated. Full schema: spec.html#attestation
{
  "standard":    "pe.rtpo.organico.sgp",
  "issuer":      "sgp-arequipa",
  "subject_pub": "J7QK...producer EdDSA public key...",
  "scope": {
    "crops":   ["papa-nativa", "oca"],
    "parcels": ["UC-04812-A"],
    "market":  "domestic"          // Ley 30983 limit, stated not hidden
  },
  "valid_from":  "2026-03-01",
  "valid_until": "2027-02-28",
  "issuer_sig":  "...EdDSA over the canonical form..."
}

Three properties follow. The attestation is self-authenticating: anyone with the issuer's public key can check it, offline. It is scoped: crops, parcels, validity window, and market are machine-readable, so a wallet can say "this covers papa nativa but you are holding oca" instead of showing a green tick. And it is bound to a key the producer controls, so possession of the document is not the same as entitlement to the claim — the way a photocopied PDF works today.

3. Kilo-tokens and mass balance

An attestation alone still permits the characteristic fraud described in The problem § 2: a valid certificate stretched over volume it never covered. Fixing that needs a quantity the system can enforce.

When a certifier attests a producer, it also opens a token family and issues a bounded quantity of blind-signed tokens, each standing for one kilogram — or one unit, or one crate — certified under that standard for that season:

token_family_slug: "pe.rtpo.organico.sgp/papa-nativa/2026-A/sgp-arequipa"
issued:            4200   // kg, against the audited yield estimate
valid_after:       "2026-04-15"
critical:          true   // a wallet that can't parse this must refuse, not ignore

Each certified sale consumes tokens as a contract input: selling 3 kg spends 3 tokens. They are blind-signed, so they cannot be forged; they are checked against the exchange's double-spend database, so they cannot be spent twice. When the 4,200 are gone, the producer can still sell potatoes — but not as certified organic, not until the next audit.

And because the signatures are blind, the certifier that issued the 4,200 tokens cannot see where they were spent. It learns that its quota was consumed. It does not learn which market, which retailer, or which shopper. Enforcement without surveillance is the specific thing this construction buys, and it is why the design is worth the complexity.

Setting the ceiling

The obvious weak point: who decides that 4,200 is the right number, and what happens in a good year? This is a genuine limitation, not a solved problem. Current thinking:

• The ceiling is an audited yield estimate — already part of what an inspection or a peer visit produces, expressed as a number instead of prose.
• Estimates are wrong in both directions, so the family supports supplementary issuance on a shorter, cheaper re-audit. A good harvest must not become a reason to sell outside the system.
• Under-issuing is the safe failure and over-issuing is the dangerous one, so the default posture is conservative with a fast top-up path. If the top-up path is slow in practice, producers route around the whole scheme and we have built nothing. OQ-4.

4. The producer is the merchant

Here is the inversion the project is named for.

In an ordinary retail payment the shop is the Taler merchant: the shop's backend creates the order, the shop's key signs the contract, the shop makes the representation to the buyer. Put a certification claim in that contract and you have re-created the existing arrangement in a better font — the retailer is still the one asserting, and therefore still the one who owns the premium.

Instead: the producer runs the merchant instance for the certified line items. Taler supports this directly — a merchant backend hosts multiple instances and each instance can use its own signing keys^[1], so an association, a cooperative, or a market-day host can operate backend infrastructure for many producers without ever holding their signing keys. Infrastructure is shared; authority is not.

5. The retailer countersigns, and the split is on the contract

Step 4 deserves its own section, because "the farmer signs" alone would just move a signature around. The economic change comes from what the countersignature requires.

Since the producer's contract is signed and hashed before the retailer touches it, the retailer cannot restate the farmgate price or absorb it into a single opaque shelf price without invalidating the thing that makes the product sellable at a premium. The retailer's margin is therefore a declared line item in a signed document that the shopper can read.

// What the shopper's wallet renders from the contract

  Papa nativa — 3.0 kg
  Orgánico (SGP Arequipa)              verified

  Al productor        Rosa Q. (Chacra Alta)   S/  18.60
  Transporte          Corredor Sur            S/   2.10
  Comisión puesto     Mercado #4, puesto 112  S/   4.30
                                            —————————
  Total                                       S/  25.00
                                              74% to the producer

We are not setting the split. A retailer that takes 40% and declares it is operating exactly as the protocol intends — and is now competing, visibly, against one that takes 15%. The mechanism is disclosure at the moment of payment, which is the only moment a shopper's preference has any leverage.

6. What happens at the point of sale

The constraint that shapes everything: a wallet in a market must verify without a working data connection, in the few seconds a purchase takes.

It can, because verification is signature checking against keys the wallet already holds. The wallet ships with a mirror of SENASA's published registry of certification bodies and SGPs^[2], refreshed opportunistically whenever it does have signal. At the stall it needs nothing from the network:

1. Scan the QR; receive the contract terms.
2. Hash the contract, verify merchant_sig against merchant_pub. The producer really signed this.
3. Read the attestation from extra; verify issuer_sig; check that subject_pub equals merchant_pub. The certifier really attested this key.
4. Check the issuer against the registry mirror and the revocation list. The certifier is entitled to make this claim, and has not been suspended.
5. Check scope: is today inside the validity window, is this crop in crops, is this market inside market?
6. Check that the contract's token inputs belong to a family that matches the attestation, and that the quantity matches the weight sold.
7. Render the result. Not a tick — a sentence: "Papa nativa, orgánico under SGP Arequipa, valid to Feb 2027, 3 kg of a 4,200 kg certified season."

Steps 1–6 are local. Only settlement — the actual double-spend check on the tokens and coins — needs the exchange, which is the same network dependency any card payment has. Verification degrades gracefully; payment does not, and that gap is OQ-2.

7. What this stops, and what it does not

The last three rows are the honest boundary of the system. This protocol makes claims about a farm impossible to forge, reuse, or stretch. It does not make them true. Truth is still produced by people walking onto other people's land and looking — which is what an SGP already does well, and what this design is trying to make worth doing.

See also: Data model & spec · Who does what · Where the money goes

References

1. GNU Taler, Merchant Backend RESTful API — instances and per-instance signing keys. docs.taler.net
2. SENASA registry of organic certification bodies and SGPs. gob.pe