Hi @Hanssen, thanks for pushing on this. I agree this needs to be very explicit.
For the current milestone scope, Dular is not trying to make every mobile/USSD pilot user run an independent Fiber node. The current architecture is operator-managed, because the target users are mobile money users who should not need to manage node uptime, channels, or watchtowers.
So yes, in the hosted mode, multiple users may route through the same Dular-operated Fiber node pubkey. That pubkey represents the Dular Fiber receiving/routing endpoint, not a separate always-on Fiber node for each user.
To avoid confusion, I will describe the registry more precisely as:
phone number → Dular user identity + Fiber receiving endpoint
In the pilot, each user can have a distinct Dular account/user identity, while the Fiber endpoint may be Dular-managed. In a later non-custodial version, the same registry can point to a user-owned or separately hosted Fiber node pubkey.
On external Fiber interoperability: yes, I agree this is important. By the end of the current milestones, Dular should include a Fiber interoperability flow.
- Send to non-Dular Fiber user: user pastes/provides a Fiber invoice, Dular debits their Dular balance and pays the invoice through the operator-managed Fiber node.
- Receive from non-Dular Fiber user: Dular generates a Fiber invoice tied to the Dular user account, and once the external Fiber payment succeeds, Dular credits that user’s balance.
This means Dular users still get the simple phone-number/USSD experience, but assets are not trapped inside Dular. They can enter and exit through standard Fiber invoice flows.
So the final architecture for this grant should be understood as:
- Mobile/USSD users do not run Fiber nodes themselves.
- Dular operates the Fiber node/channel infrastructure during the pilot.
- Internal phone-number transfers can remain abstracted for UX.
- External Fiber invoice send/receive should be supported so Dular remains interoperable with the wider Fiber network.
- A future fully non-custodial version can move from Dular-managed endpoints to user-owned or hosted per-user Fiber nodes
1 Like
Hello, thank you for the reminder.
Apologies for the delay in weekly updates. The main reason is that our next milestone depends heavily on production USSD access, and we have been trying to resolve that before giving a substantive update.
Our original plan was to use Africa’s Talking shared USSD code, as stated in the proposal. However, after requesting production access, the Africa’s Talking team informed us that for crypto-related services they require a dedicated USSD setup rather than the shared USSD option. The dedicated USSD route is significantly more expensive and currently exceeds the budget we allocated for this milestone.
Because of this, we have been exploring alternative options and trying to find a practical route that still allows us to complete the USSD milestone properly. We have not yet found a perfect fit, but we have set this coming week as our final deadline to resolve the USSD path and provide a clear decision/update. Without production USSD access, we cannot honestly claim the next milestone as complete beyond the simulator-tested implementation we already built.
On @Hanssen’s architecture questions: I have now responded directly in the thread.
Going forward, I will resume weekly updates even when the update is mainly about blockers or dependency resolution, so the committee and community have better visibility.
Hi @duongja — thanks for the architecture clarifications in post #15. I reviewed the public repo to understand how Fiber fits in practice, and I have a few follow-up questions on the final milestone scope.
1. How do users access and spend funds without running their own Fiber node?
You described a managed-wallet model where internal transfers use an application ledger rather than per-transfer Fiber channel updates.
- For a typical user sending RUSD via the app or USSD, what exactly authorizes the spend — a ledger entry only, or an underlying Fiber payment?
- If Dular’s backend or operator node is unavailable, can users still access or recover their funds independently?
- By the end of all milestones, will mobile/USSD users still depend entirely on Dular-operated infrastructure, or will any users run user-owned or hosted-per-user Fiber nodes?
2. How will channel liquidity be managed?
Fiber payments depend on liquidity in the right channels (local balance, inbound capacity, routing).
- Who funds and rebalances the operator channels (RUSD and CKB for fees)?
- For deposits and withdrawals, which movements actually happen on Fiber vs. only in the ledger / M-Pesa layer?
- As user count and volume grow, what is your strategy for inbound liquidity, outbound liquidity, and routing across relay nodes?
3. How are peer connectivity and channels handled?
In standard Fiber usage, payers and receivers typically need connectivity and channel relationships before payments can flow.
- Do users each get a distinct Fiber pubkey/identity, or do they share operator node key material? (Related to Hanssen’s question in post #19.)
- For internal Dular transfers, are any Fiber channels opened between user identities, or is routing entirely at the operator/relay layer?
- For deposits, withdrawals, and any future external Fiber payments: when and how are channels opened — at onboarding, on first payment, or via shared hub-and-spoke channels to relay nodes?
Thanks.
2 Likes