Hi @Hanssen, thanks for the thoughtful questions. I should clarify the
architecture more precisely.
In the current Milestone 1/2 implementation, transfers between internal Dular
users are not yet executed as a separate Fiber payment for every phone-to-
phone transfer. Internal Dular sends currently use an application ledger: the
sender is debited and the recipient is credited after both phone identities
are verified. Fiber is used as the RUSD settlement/liquidity layer around the
app, especially for the testnet RUSD payment/channel proof and deposit
settlement flow.
So the “phone-to-pubkey registry” should be interpreted as a discovery/
identity layer, not as a claim that every pilot user already runs an
independent always-on Fiber node. It maps a verified phone number to the Fiber
identity/receiving endpoint Dular can route to. In the current prototype this
is Dular-managed; in the fuller Fiber-native version, that same registry can
point to a user-owned or hosted-user Fiber node pubkey.
Because internal transfers are not yet individual Fiber channel updates, user-
level watchtower hosting is not part of the current implementation. The Fiber
nodes used in the prototype are operator-managed testnet nodes. If we move to
fully Fiber-native per-user channels, the design would need either hosted
Fiber nodes/watchtowers for mobile/USSD users or user-controlled nodes for
advanced users.
For non-Dular Fiber users: the lower-level Fiber integration exists, but the
current user-facing product is focused on phone-number transfers inside Dular.
Sending to an external Fiber user would mean exposing a “pay Fiber invoice”
flow. Receiving from an external Fiber user would mean exposing a Dular-
generated Fiber invoice or receive endpoint. These are technically aligned
with the current Fiber RPC integration, but they are not yet polished as end-
user flows in the Milestone 1/2 app.
So in short: Fiber is the settlement/payment-channel layer Dular is building
on, while the current phone/USSD product layer abstracts that complexity for
mobile money users. The current prototype is a managed-wallet architecture
with Fiber-backed settlement, and the roadmap is to progressively expose more
direct Fiber interoperability as the UX and node-hosting model mature.