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

Mechanism design for micro-credit

In Redesigning Microcredit, 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. 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.

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 (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. Capers raise capital through perpetual bonding-curve markets and disburse treasury funds under token-holder governance; because both run on low-fee programmable settlement, the minimum economic ticket size is small. That makes micro-contributions to a raise viable — a backer can buy into a curve with a modest amount without fees consuming the position — and it allows treasuries to make granular payouts to many recipients rather than batching value into a few large transfers. In this sense, small-ticket participation in raising funds on Caper is a working instance of the pattern above: settlement-layer design shrinking the fixed costs that would otherwise crush small transactions. For the practical steps, see Getting started.

References

1. Ashok Rai and Tomas Sjöström (2013). Redesigning Microcredit. 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. The Review of Economic Studies 71(1): 217–234.
3. Ghada Almashaqbeh, Allison Bishop and Justin Cappos (2020). MicroCash: Practical Concurrent Processing of Micropayments. Financial Cryptography and Data Security (FC 2020), Springer LNCS.