Sayola

Aid and remittances reach Syria in seconds. Sayola makes sure the cash is there too, funded by halal income from families' savings.

Comment

Inspiration

It started with a simple question from friends whose families live in Syria: the money arrived, so why can't they spend it?

Sending money to Syria over Stellar is already fast and cheap. A health-worker payroll in northwest Syria cut fees from roughly 20% to 2%, and delivery from months to days. But Syria runs on cash, and the last step (turning digital dollars into Syrian pounds) still depends on hawala agents who run out of banknotes exactly when an aid payday sends everyone to collect at once. The transfer succeeds. Then the family walks to an agent with an empty drawer.

Our first idea was narrow: hold the funds until the recipient confirms they got the cash. That's useful for donors, but it only records the failure. We wanted to prevent it.

What it does

Sayola extends the Stellar Disbursement Platform with three pieces:

  1. Booked cash-out with proof of delivery. Funds are held for the recipient in a Soroban contract and can be claimed by any approved agent. The recipient can book a cash-out so the agent sets cash aside, or walk in. When both sides confirm the amount handed over, the agent is paid within seconds. The recipient can raise a private dispute afterwards.
  2. A halal liquidity vault. Savers (retirees, or families who receive remittances meant as recurring income rather than to be spent at once) fund agents' cash drawers under a musharakah (profit-and-loss-sharing) contract. They earn a share of real cash-out fees, never a guaranteed return.
  3. Payday forecasting. NGOs already upload their payout schedules to Stellar. The vault uses them to place cash with agents near recipients before each payday.

Recipients can collect with a smartphone (a QR code that keeps changing), a basic phone (a one-time code by text message), or a printed card and PIN. A registered proxy can collect on their behalf, and the recipient is notified every time. No personal data goes on-chain.

How we built it

We had three days, so we kept the stack small and used AI coding agents working in parallel against one agreed interface.

  • One Soroban contract (Rust, soroban-sdk) holds both the cash-out escrow and the liquidity vault, with separate accounting. Cash-out requires both the agent's and the recipient's authorization in the same transaction.
  • Mock USDC is a Stellar classic asset with its Stellar Asset Contract.
  • Fee sponsorship: a server operator account submits every transaction and pays the fees, so agents and recipients never touch XLM.
  • Next.js + TypeScript mobile web app with NGO, agent, recipient and investor views; agent and recipient screens in Arabic.
  • Stellar RPC for simulation, submission and contract events; contract bindings generated by the Stellar CLI.
  • No personal data on-chain: names and phone numbers stay server-side.
  • Simulated for the demo: the licensed Syrian partner's currency conversion and SMS delivery.

Each cash-out fee is split 40% agent / 50% vault / 10% platform. The vault's share value is:

Share value = (idle funds + float with agents) ÷ total shares

Fee income raises it, and losses not covered by an agent's collateral lower it, so each investor earns in proportion to their capital and how long it stays in.

Challenges we ran into

  • Not becoming a bank. Paying returns on savings is regulated almost everywhere. The vault is run by a licensed partner, the money stays on Stellar, and investors take a real share of profit and loss rather than making a deposit.
  • Keeping it halal. Currency exchange has to be spot, with both sides handed over in the same sitting. The cash-out contract settles at the moment of handover, so the halal requirement and the technical design turned out to be the same thing. Losses fall in a fixed order: first the agent's pledged collateral, then the agent if they were negligent, then a reserve fund built from profits, and only then investors.
  • What happens when everyone wants cash. No system can promise banknotes that don't exist. We set a priority order. Booked aid cash-outs come first, everyday cash-outs second, and vault capital withdrawals last, on 30 days' notice. Profit payouts are made in USDC, so they never draw on drawer cash and keep flowing.
  • Verification without surveillance. Strict identity checks exclude displaced people who have lost their documents. Aid recipients are vouched for by the NGO that registered them, with lower limits where documents are missing.
  • Syria's 2026 rule that aid be paid in Syrian pounds. Transfers are valued in pounds and the cash is paid out in pounds at the partner's legal exchange rate, while USDC moves underneath.

What we learned

  • The last mile fails on timing more than distance. Agents run dry because paydays arrive all at once. Forecasting demand is worth more than adding agents.
  • Savers abroad don't add local cash. Only people inside the country hold Syrian pounds. Cash supply comes from netting trade flows, the way hawala has always worked, plus local savers who want dollars.
  • The pieces already exist. UNHCR, GIZ, and the Near East Foundation with KfW have proven USDC-on-Stellar delivery in crisis settings, including Syria. What was missing is liquidity at the counter.

What's next

Pilot with Digibank's network of cash-out agents, an anchor licensed by the Central Bank of Syria, and one NGO partner. After that: basic-phone access over USSD, takaful (Islamic cooperative insurance) for cash in transit, diaspora investors, and paying merchants directly from the wallet.

Built With

Share this project:

Updates

Submission history