Dular Phase 1 is complete, and I want to use this post differently: not to summarize deliverables, but to share what building on Fiber for real mobile-money users actually taught us. Founder findings, including the uncomfortable ones. If you’re building payments on Fiber or CKB or thinking about it I hope some of this saves you months.
Finding 1: Users don’t want a wallet. They want a loop.
We onboarded 30 users and collected 23 structured feedback responses, and the most important thing in the data isn’t a rating, it’s who showed up. A small shop owner receiving from customers. A boda rider. A grocery vendor whose customers send to her number. We built for “peer-to-peer transfers” and the field handed us circuits: customer → till → supplier, stage → rider, customer → stall.
That distinction reorganized my thinking completely. A P2P transfer is a line segment — it starts nowhere and ends nowhere, leaking value at both ends (usually straight back into cash). A merchant circuit compounds: one person’s spend is another person’s revenue inside the same system, and every rotation makes the next one easier. Our job was never “move money.” It was “keep money moving inside.”
The ratings tell the same story from a different angle: send flow 3.96/5, onboarding 3.96, deposit 3.70 and reliability 3.39, the lowest score, with 19 of 23 saying they’d use it again. Read that carefully: users liked the product and still marked us down on the one thing that matters. They forgive rough edges, confusing PIN names, Swahili gaps. They do not forgive money that doesn’t arrive. If you’re building payments anywhere in this ecosystem, my blunt advice: instrument arrival certainty before you polish anything else. The prettiest wallet in the world is worthless on the day a shopkeeper hands over goods for a payment that never lands.
Finding 2: The full-stack thesis is right — but it’s missing a layer.
Earlier this year Sandeep Nailwal laid out the Open Money Stack argument: stablecoins alone change nothing; what moves money end-to-end is a complete stack, wallets, fiat ramps, routing, settlement — open and vertically integrated at the same time, where every seam between vendors is a fee, a failure point, and a margin skim. It’s a good thesis and it maps onto Dular almost exactly: a self-custody wallet with phone-number identity, production M-Pesa deposits, Fiber routing resolved by phone number, settlement anchored to CKB. We didn’t set out to mirror it; building honestly in this market just converges there.
But here’s what I’d add back to that thesis, from the field: every full stack described so far stops at wallets built for people who already have financial identities. Our users identify with phone numbers. They verify with an OTP text. They confirm with an M-Pesa SMS they’ve learned to trust the way the rest of us trust a bank app. No seed phrases, no hex addresses, no smartphone requirement, no new mental model, the financial identity they already carry.
So my amendment, offered respectfully: identity is the last mile of every payments stack. It’s the layer that converts infrastructure into adoption and without it, the most elegant stack on earth has no distribution. Our phone-to-Fiber identity registry is Dular’s version of that layer, and it’s the single piece I’d tell any Africa-facing Fiber builder to build first, before a single swap feature or points program. The stack gets you correctness. Identity gets you users.
Finding 3: The margin was never the fee.
The strategy memo that rewired our roadmap says it best: M-Pesa’s fortress was never the send-money fee table, most small P2P transfers are already near-free, and shaving them further wins you nothing. The real money sits elsewhere: the tariff paid to turn digital value back into cash, the cut taken on every merchant collection, the cost of pulling money out of a business wallet, and credit priced on top of the payment graph (the Fuliza playbook — small fees on enormous observed flow).
Follow that money and the strategy inverts. Don’t build a cheaper send button; build a world where the send button’s fee doesn’t matter because value rarely exits. A salary paid in, spent at the in-network shop, passed to the in-network supplier, no cash-out event, no tariff, nobody queuing at an agent kiosk. The painful loop every Kenyan knows is receive → pay to withdraw → spend cash; kill that loop and the fee table becomes optional.
That inversion dictates sequencing, and ours changed because of it. Merchant tills come before remittance corridors — a shop paying roughly nothing instead of ~0.5% per collection is an attackable, winnable fight, and every till is daily volume. Daily gig payouts come early too, because fifty individually provable micro-payouts turn “did my pay arrive?” disputes into a solved problem. Savings groups come before cross-border, because a chama treasury whose ledger IS the receipt book is the highest-retention financial product in the country. And the working-capital credit play, loans priced off visible on-rail cashflow instead of blind — only prices correctly once loop density exists. Data exhaust needs an exhaust pipe first. Remittance, the headline everyone starts with, goes last: it should ride on liquidity the loops already created, never cold-start.
One line version: price movement at cost, harvest the stillness. Free to move; the value is in everything that happens while value rests, software on the till tape, capital on the cashflow, FX where corridors are genuinely broken.
Finding 4: The hardest problem is also the most ordinary — the receiver is offline.
Nothing in the demos prepares you for this. In every hackathon P2P flow, both phones are open, both wallets unlocked, everyone smiling. In real life the receiver’s phone is off, or it’s a feature phone with no data, or the browser tab died three hours ago and on channel-based networks, receiving needs you present with a route. Our pilot hit this wall constantly: delivery delays, “keep the wallet open” warnings, confused users. It is THE bottleneck between a demo and a product, and I’d guess half the Fiber builders reading this have met it quietly.
Our answer, which I’d genuinely like pushback on: give every user two balances, not one. The first is fully theirs, keys on their device, savings live here, nobody can touch it. The second is a small day-to-day float parked with our always-on operator, whose only job is catching money while you’re away: send to an offline number and it lands instantly with a receipt, capped low, shown separately and labeled plainly, movable into the user’s own wallet in one tap (automatic next time they open the app). Online? Settles directly phone-to-phone. Offline or feature phone? Caught safely, waiting, earning us nothing.
Three rules we’re holding as non-negotiable, offered as a pattern: never blend the two balances into one number (opacity was the original sin of custodial models, not custody itself); keep the float capped low and say the number out loud (it bounds our honeypot, our regulatory surface, and everyone’s temptation); and the user must be able to pull their float home even if we vanished tomorrow, otherwise it’s just a ledger with marketing. Our earlier “payment waits and retries when you return” mechanism was the seed of this; we’re growing it up.
And an open question to Fiber devs, in plain words: is anyone working on ways for money to wait safely for an offline receiver as a first-class network feature, rather than every wallet team reinventing the holding pen? If that ever exists, our float account dissolves into protocol, happily. Until then, this is the honest architecture. Argue with us before we build it.
What’s next
Phase 1 proved the stack and surfaced these four findings. Phase 2 is built directly out of them, every item traces back to a paragraph above, and it’s already in motion. Get ready
Thank you to the committee (@xingtianchunyan @zz_tovarishch @Hanssen @ebubedev) the push toward self-custody and interop is woven through half of what’s above. And thank you to the pilot users who taught us more in a month than a year of designing would have.
Builders: repo’s open (GitHub - duongja/Dular · GitHub), live app at https://dular.vercel.app/