Spark Program | Dular

English
,
21

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
22

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.

1 Like
CKB Ecosystem Biweekly Update
23

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.

3 Likes
24

Hi @duongja ,

The review committee has no further comments or follow-up questions on your current submission.

Please note, however, that if you encounter issues that are difficult to resolve, you should promptly provide a brief update to the committee and the community.

Best,
xingtian
On behalf of the Spark Program Committee

2 Likes
25

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.

4 Likes
26

Hi @duongja ,

Regarding your recent request for a change of direction, after careful review, the committee has reached the following decision:

  • The committee is willing to approve your request to adjust the project’s direction, provided that deposit and withdrawal functions continue to operate normally. Provided this condition is met, the proposed changes to the milestones may be accepted, and the grant amount need not be adjusted.

However, before formally updating the milestones, please clearly specify the status of the deposit and withdrawal functions. This is a prerequisite for approval of the change in direction.

Please provide a clear status update on this matter.

Best,
xingtian
On behalf of the Spark Program Committee