---
title: "Microfinance and micropayments"
url: "https://caper.network/wiki/economics/microfinance"
updated: 2026-08-07
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Microfinance and micropayments

|  |  |
| --- | --- |
| **Topic** | Economics of very small loans and payments |
| **Core problem** | Fixed transaction costs that fall disproportionately on small transactions |
| **Key approaches** | Group lending with cross-reporting; probabilistic micropayment lotteries |
| **Evidence base** | Six randomized evaluations across four continents: effects “modestly positive, but not transformative” |
| **Related** | [Transaction costs and property rights](/wiki/economics/transaction-costs) · [Raising funds](/wiki/markets/raising-funds) · [Getting started](/wiki/foundations/getting-started) |

Microfinance and micropayments are, respectively, small-scale financial services — chiefly credit — for people underserved by conventional banks, and digital payment schemes for amounts so small that ordinary processing fees would swallow them. Though the two grew up in different disciplines, development economics and computer science, they confront the same underlying obstacle: the costs of executing a transaction are largely fixed, so they fall disproportionately on small transactions. A payment network's fee schedule and a bank's need to verify a borrower's circumstances both set a floor below which transacting stops being worthwhile.

Both fields treat the remedy as a design problem rather than a subsidy problem. Microcredit research redesigns the loan contract so that borrowers' own local knowledge substitutes for costly bank monitoring; micropayment research redesigns the settlement protocol so that many tiny payments are amortized into a few larger ones. This article outlines one influential line of work in each.

## The fixed-cost problem

Every exchange carries overheads that attach to the transaction rather than to the amount transacted — the classic subject matter of [transaction-cost economics](/wiki/economics/transaction-costs). In retail payments these overheads are measurable: processing an average United States debit card transaction has a base cost of roughly 21–24 cents (23–42 cents for credit cards), and fees on the Bitcoin network can exceed one dollar, so for genuinely tiny payments [the fee often exceeds the payment itself](https://arxiv.org/abs/1911.08520). Processing each micropayment individually is therefore uneconomic, which motivates aggregating many small payments into fewer larger ones.

Small-scale credit faces an informational analogue. The facts a lender needs — whether a borrower's project succeeded, whether a missed payment reflects genuine hardship — are held locally, among the borrower's peers, and cannot be observed directly by the bank. For loans measured in tens or hundreds of dollars, the sums at stake cannot support intensive verification by the lender, so the design question becomes how to elicit that local information cheaply and honestly.

| Domain | Binding fixed cost | Design response |
| --- | --- | --- |
| Micro-credit | Verifying borrower outcomes the bank cannot observe | Group lending mechanisms that harvest borrowers' local information |
| Micropayments | Per-transaction processing and settlement fees | Probabilistic aggregation of many payments into one settlement |

## Mechanism design for micro-credit

In [Redesigning Microcredit](https://academic.oup.com/book/26714/chapter/195542893), Ashok Rai and Tomas Sjöström treat the microloan contract as a mechanism design problem: how should a bank structure lending to poor borrowers who hold local information about one another that the bank itself cannot observe? In their companion model, borrowers observe each other's project outcomes but have only a limited ability to side-contract, so they [cannot write complete informal insurance contracts among themselves](https://academic.oup.com/restud/article-abstract/71/1/217/1590688). A well-designed bank mechanism can close that gap: the authors derive a lending scheme that efficiently induces mutual insurance, formalizing the Grameen Bank practice of encouraging borrowers to help one another through hard times.

Two results are central. First, joint liability — holding group members answerable for one another's loans — is by itself insufficient to induce efficient mutual assistance. Second, efficiency requires _cross-reporting_: each borrower submits reports to the bank about the others' outcomes. Cross-reports induce truthful revelation of project states, increase the bargaining power of unsuccessful borrowers, minimize deadweight punishment relative to contracts that lack them, and remain robust to borrower collusion against the bank. The chapter's broader prescription, taken up in later work on microfinance product design, is that efficient loan and savings contracts should blend discipline with flexibility — promoting timely repayment while permitting rescheduling in exceptional circumstances.

## What the randomized evidence found

The mechanism-design literature above asks how a microloan contract _should_ be built. A separate, later body of work asked whether expanding access to the resulting product changed borrowers' lives, and it is the reason the field's tone shifted between the 2000s and the 2010s.

The best-known study is the Hyderabad experiment of Abhijit Banerjee, Esther Duflo, Rachel Glennerster and Cynthia Kinnan, in which a lender opened branches in 52 randomly selected neighbourhoods. Access raised microcredit takeup by [8.4 percentage points](https://www.aeaweb.org/articles?id=10.1257/app.20130533). Investment and profits in businesses that already existed rose; overall consumption did not rise significantly; spending on durable goods rose while spending on what the authors call “temptation goods” fell. The study found no significant change in health, education or women's empowerment, and when the control neighbourhoods later gained access too, very few differences between the groups persisted.

Hyderabad was one of six randomized evaluations published together, run across six countries on four continents in urban and rural settings, with different lenders, loan terms and borrower populations. The volume's editors summarise the pattern as [“modestly positive, but not transformative”](https://www.aeaweb.org/articles?id=10.1257/app.20140287) effects.

That result does not undo the design work; it relocates it. If lowering the fixed cost of lending mostly enlarges the market rather than transforming the borrower, then the value of a cheaper transaction is the transaction itself — more people able to borrow, invest and repay at all — and not a downstream miracle. It is a useful discipline to carry into any argument that reducing on-chain fees will, by itself, produce a different kind of participant.

## Protocol design for micropayments

The payments literature attacks its fixed cost by amortization. In a probabilistic micropayment scheme, the payer locks the total payment value in an escrow and issues each micropayment as a lottery ticket that wins with probability _p_ and pays β currency units; on average only one on-chain transaction is settled per 1/_p_ tickets, cutting both fees and the data written to the blockchain. As surveyed in the MicroCash paper, early schemes by Wheeler (1996) and Rivest (1997) relied on a trusted central bank to audit the lottery, while decentralized successors such as MICROPAY and DAM replaced the bank with miners but forced tickets to be issued sequentially from each escrow — sustaining a high payment rate then requires creating over a thousand escrows per second, bloating the chain — and depended on heavy cryptography such as public-key operations and non-interactive zero-knowledge proofs across multiple communication rounds.

[MicroCash](https://arxiv.org/abs/1911.08520) (Almashaqbeh, Bishop and Cappos, 2020) is the first decentralized probabilistic framework to support concurrent micropayments. A novel escrow setup lets a customer declare the total number of tickets and post a balance covering all possible winning tickets, after which tickets can be issued in parallel, at high rates, from a single escrow. The lottery is non-interactive, requires only secure hashing and one communication round, and selects an exact number of winning tickets per round using a draw value derived from a future blockchain block — eliminating the variance risk that all tickets win or lose, and lowering the collateral the customer must post. Security against escrow overdraft, duplicate ticket issuance, lottery manipulation and invalid payments combines cryptographic checks with financial deterrents: customers post an additional penalty escrow that miners revoke upon detected cheating, with the minimum penalty derived from a game-theoretic model of rational participants.

In evaluation, a modest merchant machine processed 2,240–10,500 tickets per second — roughly 1.7–4.2 times the MICROPAY baseline — with aggregated payments about 60% smaller, while a customer could concurrently issue more than 33,000 tickets per second from one escrow; in simulated video-delivery and online-gaming workloads, MicroCash reduced blockchain transaction fees and stored data by about half. The paper also contrasts probabilistic lotteries with payment channels: channels require an escrow between each pair of parties along a payment path, and routing hubs charge relay fees that can exceed the micropayment being carried, a pressure that indirectly pushes channel networks toward centralization — whereas a single lottery escrow can pay many merchants directly with no per-ticket exchange fees.

## Relevance to Caper

The same arithmetic governs who can afford to participate in on-chain fundraising and governance, and Caper is a good test case precisely because it does not answer the question the same way on both sides.

**Trading is proportional.** A [caper](/wiki/foundations/what-is-a-caper) raises through a bonding-curve market, and the protocol's trade fee is charged as a fraction of the trade — 0.5% at instantiation. A fractional fee scales with the ticket, so a small buy pays a small fee and the fixed-cost floor this article describes does not appear. Small-ticket participation in [raising funds](/wiki/markets/raising-funds) is genuinely viable, and [treasuries](/wiki/dao-governance/concepts/treasury/dao-treasury-management) can make granular payouts to many recipients rather than batching into a few large transfers.

**Governance is not.** Creating a [proposal](/wiki/governance/proposals) costs a flat fee in XRD — 500 at instantiation — and casting a [vote](/wiki/governance/voting) costs a flat fee of its own, 100 at instantiation, paid in XRD by the voter and checked for the exact amount. Neither scales with the size of the holding behind it, and a voter must additionally hold at least one governance token. That is the fixed cost of this article, reproduced on-chain: the fee is the same whether the ballot carries a large stake or a trivial one, so it falls hardest on the smallest participant, and below some holding size voting stops being worth doing.

Two points of accuracy are worth stating rather than glossing. The fee schedule is _platform-wide_, not per-caper: every caper trades and votes through one shared logic component that holds all four parameters, so no individual caper's governance can set or waive its own fees. And the numbers above are the values the component is instantiated with, not constants — one method rewrites all four, under the protocol admin badge. The design choice being made is deliberate: a flat fee is what prices spam, and pricing spam is what a fractional fee cannot do. The cost of that choice is the one microfinance has documented for fifty years, and it is paid by the smallest participant.

## References

1. Ashok Rai and Tomas Sjöström (2013). [Redesigning Microcredit](https://academic.oup.com/book/26714/chapter/195542893). In Nir Vulkan, Alvin E. Roth and Zvika Neeman (eds.), _The Handbook of Market Design_, Oxford University Press, ch. 9, pp. 249–265.
2. Ashok Rai and Tomas Sjöström (2004). [Is Grameen Lending Efficient? Repayment Incentives and Insurance in Village Economies](https://academic.oup.com/restud/article-abstract/71/1/217/1590688). _The Review of Economic Studies_ 71(1): 217–234.
3. Ghada Almashaqbeh, Allison Bishop and Justin Cappos (2020). [MicroCash: Practical Concurrent Processing of Micropayments](https://arxiv.org/abs/1911.08520). _Financial Cryptography and Data Security_ (FC 2020), Springer LNCS.
4. Abhijit V. Banerjee, Esther Duflo, Rachel Glennerster and Cynthia Kinnan (2015). [The Miracle of Microfinance? Evidence from a Randomized Evaluation](https://www.aeaweb.org/articles?id=10.1257/app.20130533). _American Economic Journal: Applied Economics_ 7(1): 22–53.
5. Abhijit Banerjee, Dean Karlan and Jonathan Zinman (2015). [Six Randomized Evaluations of Microcredit: Introduction and Further Steps](https://www.aeaweb.org/articles?id=10.1257/app.20140287). _American Economic Journal: Applied Economics_ 7(1): 1–21.