Hello everyone,
I want to give a clear update on two things: the USSD blocker and the architecture direction for Dular after the feedback from @Hanssen and @ebubedev.
USSD update
We implemented the USSD interface and tested it through the Africa’s Talking simulator. The current implementation supports balance checks, phone-number sends, receive details, M-Pesa deposit initiation, PIN setup, and a withdrawal placeholder. The simulator evidence and implementation are already in the public repo.
However, we will not use USSD as the main live testing channel for the next phase.
The reason is that our original proposal budgeted for Africa’s Talking shared USSD codes. After engaging Africa’s Talking for production access, they informed us that for crypto-related services they require a dedicated USSD code, not the shared USSD option. The dedicated USSD route is significantly more expensive than the shared-code setup we budgeted for, and it is not practical within the current Spark grant amount.
So the USSD implementation will remain in the codebase as a simulator-tested interface, but we will not depend on production USSD for the next live user test phase unless we later secure a dedicated USSD budget or find another production-ready provider.
Architecture update after committee feedback
The questions from @Hanssen and @ebubedev were valid. Our earlier implementation was closer to a managed/operator model:
- internal Dular transfers were application-ledger based;
- users did not run their own Fiber nodes;
- Fiber was used around settlement/proof/liquidity;
- external Fiber invoice send/receive was not yet exposed as a polished user flow.
That helped us prototype quickly, but I agree it weakens the relationship between Dular and Fiber if users cannot directly control their Fiber identity or interact with external Fiber payments.
Because of this, we are changing the direction for the next phase.
Instead of continuing with USSD as the main live test path, we will move toward a mobile web/PWA flow using Fiber WASM through fiber-js. The goal is to make Dular more directly Fiber-native and closer to self-custody.
The updated direction is:
- users access Dular through a mobile browser/PWA;
- the user’s device generates and stores their wallet/Fiber keys locally;
- Dular backend handles phone verification, registry lookup, M-Pesa coordination, and UX support;
- the phone-to-pubkey registry maps phone numbers to user-owned Fiber identities/receiving endpoints;
- Fiber invoice send/receive flows will be exposed so assets can move between Dular users and non-Dular Fiber users;
- internal transfers should move away from being only ledger entries and toward Fiber invoice/payment flows where technically feasible.
This means the registry becomes closer to what was originally intended:
phone number → user-owned Fiber identity / receiving endpoint
rather than:
phone number → Dular-managed backend account only.
What this means for the final milestone scope
For the live test phase, we are no longer treating production USSD as a hard dependency. The priority is now mobile-phone testing through a browser/PWA self-custody flow.
The target final architecture for this grant becomes:
- mobile users do not need to install or manage a desktop Fiber node;
- the browser runs Fiber WASM where possible;
- user keys are generated and stored locally on the user’s device;
- Dular does not need to custody the user’s private key;
- Dular still provides phone-number identity, M-Pesa integration, and coordination services;
- users should be able to send to and receive from external Fiber users through invoice flows.
Longer term, we can still support other modes:
- hosted nodes as a service for users who want convenience;
- native mobile support if Fiber mobile tooling matures;
- USSD if we later secure a dedicated code or a viable provider;
- operator-managed liquidity nodes for routing/rebalancing support.
But for now, the practical decision is:
- keep the USSD implementation and simulator evidence in the repo;
- do not rely on production USSD for the next live test phase;
- move the main testing path toward mobile web + Fiber WASM + user-controlled keys;
- strengthen direct Fiber interoperability instead of relying mainly on an internal ledger abstraction.
This should address the core concern that Dular must not become a closed mobile-money ledger with Fiber only in the background. The updated path makes Fiber central to the user identity and payment flow while still preserving Dular’s original goal: making stablecoin payments usable from ordinary mobile phones.