One project, written the way I'd explain it to another engineer: what the constraints were, what I decided, and what I got wrong.
KES ↔ MWK settlement, T+2 to same-day
Moving money between Kenya and Malawi through banks is a two-day promise at best. A Nairobi-side payer sends shillings, the bank converts to dollars, a correspondent forwards them, a Malawian bank converts to kwacha, and the recipient sees funds on T+2 if the Malawian bank has dollars to release that week. Often it doesn't. Malawi's reserves have sat below three months of import cover through 2026, and banks there ration foreign exchange even when reserves improve on paper.
For a trader with family or suppliers on both sides, the cost is not the fee. It is not knowing which day the money lands, and what the kwacha will be worth when it does.
If the dollar leg moves on-chain as USDT and both ends settle into local mobile money, the corridor can clear same-day, and a single double-entry ledger can hold the whole trip so that every kwacha paid out is traceable to a shilling paid in.
Two sub-claims came with that:
A closed-loop voucher model. A Kenyan sender funds a voucher in KES via M-Pesa; the system quotes a fixed MWK amount; a Malawian recipient redeems it into kwacha via mobile money. USDT is the settlement asset in the middle, held in a treasury wallet, never shown to either user.
Ledger core. Append-only, double-entry, one unit of account (USD). Every voucher creates a balanced set of entries: debit KES clearing, credit USD treasury; on redemption, debit USD treasury, credit MWK clearing. The KES/USD and USD/MWK rates are written onto the entries at creation. Balances are views, never stored columns.
States, not tables. Each entry carries a status: quoted, funded, settled, redeemed, expired. Available and pending balances are separate queries. This was a direct lesson from an earlier production bug where a missing column made pending balances invisible to partners.
Idempotent edges. Every M-Pesa callback and every redemption request carries a key. Duplicate callbacks, which mobile money produces routinely, return the original result rather than a second payout.
Treasury separate from ledger. The USDT float is rebalanced by threshold-triggered sweeps, not per transaction. The ledger records obligations; treasury records what actually sits in the hot wallet. They reconcile against each other, and a mismatch halts redemptions.
Regulatory anchoring. The entity model was designed around Kenya's Virtual Asset Service Providers framework, with the Malawian side kept as a redemption partner rather than a licensed issuer, after assessing that Malawi carried the higher regulatory risk.
Settlement latency. T+2 (bank baseline) to same-day. In the pilot, end-to-end from KES funding to MWK redemption was [X hours / typically within the same business day].
Rate certainty. 100% of vouchers redeemed at the quoted kwacha amount. Rate movement between quote and redemption was absorbed by the float.
Reconciliation. Every payout traceable to a funding entry; zero unreconciled balances at pilot close.
Volume. [N] vouchers, [KES amount] in the pilot window. Small by design.
Off-ramp liquidity is the bottleneck. Converting USDT to kwacha depends on a small number of counterparties; on days they were short, “same-day” became “same-day if before 2pm.”
Float sizing is a guess. Threshold sweeps worked, but the right float cap for a two-currency corridor with asymmetric demand is still unsolved. The kwacha side drains faster than the shilling side fills.
Card rails were a distraction. I evaluated crypto-card BIN providers as a spend layer and dropped them: they solve overseas spending, which is not this corridor's problem.
Prize-linked savings, explored as a retention mechanic, was shelved for compounding regulatory risk on the Malawian side.
The ledger design generalises to any two-currency corridor with a dollar leg in the middle. The operational lessons don't: each corridor's off-ramp is its own problem, and the float has to be sized against the drain, not the average.
Celo. Chosen for sub-cent fees and stablecoin-payable gas, which keep small vouchers economic, and for existing mobile-money off-ramp integrations in East Africa. Not yet live on the pilot; chain selection was made after the ledger and treasury model were built, since neither depends on it.