Fermah Pay — Stellar

Overview

Fermah Pay is a billing system for services that charge per request. A buyer funds a prepaid balance once, in USDC. The seller draws it down as the buyer uses the service. The buyer holds no XLM and signs once. The operator submits every transaction and pays the fees.

It runs in production today on an EVM-compatible chain, where it settles real USDC charges for Fermah’s proof marketplace. This grant ports it to Soroban and turns it from an internal tool into a component other Stellar sellers can run.

What it adds to Stellar. Stellar already has what one buyer needs: a contract account can hold funds and enforce spending rules, a relayer can pay fees, and SAC allowances bound a recurring pull. What it does not have is the seller’s side. A service billing a thousand buyers with contract accounts alone has a thousand accounts to charge, reconcile, and retry. Fermah Pay is one ledger instead. One contract holds every buyer’s balance. One call charges up to a hundred buyers at once. The seller reconciles one contract, not a thousand accounts. It sits behind an x402 facilitator — it is the account layer a facilitator settles against, not a facilitator itself.

What this grant builds. A good portion of the system is ported and adapted from the EVM production version, which de-risks delivery — the daemon, workers, reconciler logic, and SDK carry over. The new work is the contracts and the Soroban-specific chain code: the genuinely new engineering this grant funds.

The EVM system is live; the Soroban contracts are designed and tested against their suites but not yet deployed. Deploying them to testnet, then mainnet, is what the tranches fund.

How to read this document. This overview is the scope. Everything below is the detailed design, and the properties the system enforces even when its own software is wrong. To assess scope, this section is enough. To check the engineering, read on.

The rest of this document is the full design, written for a technically literate reader with no prior exposure to the system. Where a standard or a term is needed it is named and explained — a claim you cannot check is not worth much — and every one is collected in terms.

Read it in order. Money you cannot move is the problem, and it is not the one people expect: paying a user’s fees is easy, and paying them without taking authority over their funds or their payment’s terms is not. Authorising and submitting are different acts is the mechanism, one payment end to end, and the chapter to read if you read one. Two ways money moves covers the prepaid and direct arrangements, which differ in whether Fermah ever holds the funds. The software around the signature is where most of the engineering actually went, none of it cryptographic. The two programs on the blockchain describes what each contract enforces and which is live today, and what the system cannot do states the properties and names what enforces each.

This document describes Fermah Pay as designed for Stellar, ported from a system that runs in production on an EVM-compatible chain. Every behaviour in the gateway, the workers, the reconciler, the webhooks, and the daemon structure is read from the running EVM code. The Soroban contract designs are proven against their test suites but not yet deployed. Where something is designed but not deployed, the text says which.