Theseus—Humanitarian Aid

Inspiration

Theseus comes from a very specific pain point in humanitarian work: money often doesn’t move when and where it’s needed most, and when “innovation” shows up, it sometimes does so by turning refugees into on‑chain users whose every purchase is recorded forever. I wanted to explore whether XRPL could fix the institution‑to‑institution rail—HQ to local partners—without building yet another “wallet‑per‑refugee” system.

I was also inspired by how much institutional DeFi is starting to emerge on XRPL (vaults, lending, token escrow) and by the reality that small local NGOs struggle with working‑capital gaps even when grants are approved.

What it does

Theseus implements a two‑layer rail for humanitarian cash. At the program rail layer, HQ issues an aid stable token AIDUSD as an XRPL issued currency, local partners opt in via trustlines, and AIDUSD moves between HQ and partners using native XRPL Payments, while partners report aggregate payouts off‑chain so beneficiaries never appear on the ledger. At the capital pool rail layer, a Single Asset Vault (XLS‑65) holds RLUSD or another stable asset from HQ and/or external depositors, and the Lending Protocol (XLS‑66) lets a Loan Broker create fixed‑term loans from that pool to HQ or vetted local NGOs so they can pre‑finance activities before donor funds arrive; everything is surfaced through a Next.js console with role‑based views for Public, Auditor, Partner, and HQ.

How I built it

The project runs on XRPL Testnet using the official xrpl.js SDK for account creation, token issuance, trustlines, and Payments, and conceptually targets XLS‑65/66/85 for vaults, loans, and token escrows. A small TypeScript “AidRails” layer wraps XRPL calls into higher‑level functions like createProgram, mintProgramFunds, registerPartner, and disburseToPartner, plus createVault, depositToVault, createLoan, drawLoan, and repayLoan for the capital pool. A simple store (in‑memory or SQLite) holds programs, partners, and payout reports as aggregates only. On top of that, a Next.js/React frontend provides a role selector, a program dashboard, partner views, and an HQ panel that can mint funds, disburse to partners, and exercise a demo vault/loan flow via API routes that talk to the AidRails SDK.

Challenges I ran into

The first challenge was modeling real humanitarian flows honestly without over‑promising: the real world involves bank de‑risking, sanctions, correspondent chains, mobile money, and sometimes hawala, and a weekend project can’t fix all of that, but it can at least draw the boundaries correctly. The second challenge was using XRPL primitives correctly instead of reinventing them; mapping who should be issuer, vault owner, loan broker, and borrower took more thought than deploying a generic ERC‑20. A third challenge was resisting the gravitational pull toward “wallet for every beneficiary” and designing around institutional rails instead, even though much of the humanitarian blockchain literature assumes on‑chain IDs and per‑person wallets. Finally, scoping the capital pool rail to a single clear demo flow—one vault, one broker, one loan—was necessary so it would support, rather than overshadow, the program rail.

Accomplishments that I'm proud of

I’m proud of achieving a clean separation between the aid rail and the DeFi rail: the program rail focuses on fast, auditable AIDUSD flows between HQ and partners, while the capital pool rail offers an optional, transparent funding engine that can pre‑finance those flows when donor cash is delayed. I’m also happy that the design uses XRPL’s native features instead of custom contracts, leaning on issued currencies and trustlines for whitelisted institutional token flows, Payments and (conceptually) Token Escrows for scheduled tranches, and XLS‑65/66 for institutional‑style lending. Finally, I consider it a key accomplishment that the privacy stance is architectural—no beneficiary wallets, only aggregated payout reporting off‑chain, and transparency centered on programs and partners, not on individuals trying to survive.

What I learned

I learned that XRPL is genuinely well‑suited for institution‑to‑institution rails: issued currencies and trustlines make it natural to model “HQ issues a program token, vetted partners hold it,” and Payments plus escrow are easier to reason about than many custom smart contract flows on general‑purpose chains. I also saw that de‑risking and sanctions are as much about process and incentives as they are about technology; even if the rails are perfect, banks and regulators’ fear of penalties can still cause funds to be delayed or rerouted, which means technical transparency and control have to be paired with legal and policy work. Most importantly, I learned that it is possible to build a “blockchain for aid” prototype that addresses real pain points in HQ‑to‑partner flows without constructing an invasive data exhaust around beneficiaries, as long as the chain stays in the pipes between organizations rather than in people’s pockets.

What's next for Theseus—Humanitarian Aid

Next, I want to harden the AidRails SDK into a documented, reusable package, likely split into a program module for AIDUSD issuance and HQ‑to‑partner flows and a capital module for vaults, lending, and simple risk views, and publish it on npm with strong TypeScript types and examples. I also want to plug into at least one real payout partner—such as a mobile money or card provider—so one demo path can move real (test) money to test accounts while keeping beneficiaries off XRPL. On the governance side, I’d like to use multi‑signing and token escrow more deeply to encode approval and tranche logic, and explore XRPL credentials and permissioned DEX domains to represent KYC’d participants and restricted markets. Finally, I see future work in supporting different ownership models for the capital pool (HQ‑owned, external impact fund, mixed) and in doing user research with NGOs and donors to adapt terminology, metrics, and workflows so Theseus maps directly onto real donor reporting and audit practices.

Built With

• claude
• python