OnLoan Case Study · Design & Development
We build OnLoan for people who already trust each other. It meters kilometres, days, or hours, then settles in cash or mutual credit on the FOAF ledger.
Lending a car or a drill to a friend usually means guessing the amount, or using a rental platform that treats the two of you as strangers. Neighbours need a meter and a settlement that does not require a marketplace.
A loan needs an existing FOAF trustline. OnLoan meters what was actually used, then settles in cash or as mutual credit. No deposits, no interest, and never strangers.
The public site is live at onloan.net. The app is at app.onloan.net. A Rails API owns the loans table, the meter, and the settle orchestration. An Expo app is the client. Identity and contacts come from FOAF auth. Money does not.
OnLoan computes (end minus start) times rate, in BigDecimal, to the network's decimals. Settlement reuses FOAF's pending-transfer flow: the borrower creates it, the lender confirms it. The loan is marked settled only on a 2xx confirm with an operation id. OnLoan settles on the same FOAF ledger as GrowOperative.
How it's built
Trustlines, capacity, and transfers stay in the protocol.
Balances, trustlines, capacity, and transfers are FOAF's job, over HTTP. OnLoan never holds a ledger of its own. That split is the architecture, not a slogan on the marketing site.
The borrower creates a pending transfer, sender-signed. The lender confirms it, receiver-signed. A retry guard stops a replay from settling twice. The loan is not marked settled until the confirm returns an operation id.
Rate, readings, and amount stay BigDecimal. Half-up rounding to the network decimals. Units are kilometres, calendar days that survive DST, or hours. Zero, negative, and rounds-to-zero results are rejected.
OnLoan reads FOAF trustline capacity before a transfer opens. A loan cannot open a transfer that would exceed the borrower's available credit. Addresses come from the FOAF session and the contacts envelope. Nobody types a wallet.
DRAFT, OPEN, AWAITING CONFIRMATION, SETTLED. The lender starts the meter. Either side logs the return. Both sides confirm. Cash is always an option. Credit uses the trustline you already have. There is no stranger matching.
Next.js 16 for the public page. Rails 8 and Postgres for loans. Expo 54 for the client. Three repos, one product. The public site and the app both say never strangers.
BigDecimal metering · bilateral pending-transfer · capacity pre-check · FOAF identity · Next.js 16 · Rails 8 · Expo 54.
What this shows
We build the loan in the product and leave the ledger in the protocol. Client work that needs a payment protocol, not a payment processor, looks like this.
We design the product and the protocol boundary from one studio.
