Receive URI generation can stall 10–15s on mobile: lazy LSP reconnect + LSPS2/mint round-trips are serialized behind one opaque await

[hash-money]

Observed

On mobile (Android + iOS, orange-sdk 4e9d230, Cashu trusted tier on Mutinynet signet, LSPS2 JIT via our LSP), Wallet::get_single_use_receive_uri() intermittently takes 10–15 seconds. The variance correlates with how long the app was backgrounded first: mobile OSes kill the LSP TCP socket in the background, and the reconnect cost is paid lazily by the next operation that needs the peer — which is usually this call, right when a user is standing in front of a payer.

Where the time goes (as integrators understand it)

get_single_use_receive_uri serializes, behind one opaque await, up to all of:

1. LSP peer reconnect (TCP + noise + init + channel_reestablish) if the connection died — the mobile-lifecycle tax.
2. LSPS2 JIT negotiation when inbound is insufficient (fee-menu fetch + buy round-trips over LN messages).
3. Trusted-backend quote creation (Cashu: HTTP POST to the mint) on the trusted path.
4. On-chain address derivation (local, fine).

None of this is individually wrong, but bundling them means integrators can neither overlap the slow parts with UI (the user is typing an amount anyway) nor tell users what they're waiting for.

Asks (any subset helps)

1. Mobile lifecycle hook / eager reconnect — an ensure_lsp_connected() (or on_foreground() hint) so apps can start the reconnect the moment the app foregrounds or the Receive screen opens, instead of paying it inside invoice generation. This is the single biggest win for perceived latency.
2. Split preparation from construction — a prepare_receive()-style warm-up that performs the connection/fee-menu legwork, letting get_single_use_receive_uri be fast at tap time.
3. Cache LSPS2 opening_fee_params within their valid_until window — if the fee menu is currently refetched per invoice, reusing a still-valid menu removes a round-trip from every JIT invoice.
4. Per-stage tracing — debug-level timing per stage (reconnect / LSPS2 / trusted quote / address) so integrators can attribute field latency instead of guessing.

Context

Downstream product issue with the client-side trace: emergent-money/graduated-wallet#331. We can work around with a parallel warm-up on screen-entry once there's any connect/warm API to call — but the lazy-reconnect-inside-receive behavior is the structural cause and affects every mobile integrator.

[hash-money]

Field data update that narrows this issue's scope. We shipped client-side instrumentation (generate <ok|error> in <N>ms lsp_connected_at_tap=<bool>) and the first real-device datapoint came back:

generate ok in 16650ms lsp_connected_at_tap=true

The LSP was already connected at tap, and the generated URI was a trusted-tier mint quote — so this particular stall class is not the lazy-reconnect path this issue hypothesizes. Isolating further: the same quote flow completes in 103 ms on a local-store wallet vs 16,650 ms VSS-backed (mint server itself ~700 ms) — that stall is the per-operation synchronous VSS round-trips, now tracked with measurements in #90.

What remains squarely THIS issue's territory:

1. The native-LN/LSPS2 sub-path when the LSP connection is cold — a reconnect serialized ahead of the LSPS2 round-trip would still produce the original 10–15s signature, and our instrumentation will tag those lsp_connected_at_tap=false as they occur.
2. The observability ask: get_single_use_receive_uri is still one opaque await; per-phase timing (reconnect / LSPS2 / mint quote / store writes) would have attributed this in one datapoint instead of three experiments.

We'll keep posting datapoints as they accumulate from device testing.

[hash-money]

Closing this out per our own data discipline: the datapoint that would keep it alive never materialized.

Since the re-scope above (2026-07-10), the instrumentation has run through several on-device sessions (2026-07-11 and the 2026-07-15 #94 benchmark run, with repeated receive taps). Every tap came back lsp_connected_at_tap=true — we never caught a single cold-LSP stall of the class this issue hypothesizes. Meanwhile the stall we did measure was fully attributed to per-operation VSS round-trips in #90 and has been materially fixed by #93/#94, with the residual attributed to the sequential chain-source path (corepc#661) — full before/after tables in #90.

We're also withdrawing the per-phase-timing observability ask. With the VSS class fixed and no cold-LSP datapoint, finer-grained timing inside get_single_use_receive_uri is our tooling problem downstream, not a change this repo needs.

If we ever tag a lsp_connected_at_tap=false stall with the original 10–15 s signature, we'll open a fresh issue carrying that datapoint rather than reviving this one. Thanks for the patience while we chased it — the detour surfaced #90, which turned out to be the real fix.