Implement breez lightning address - #602
Merged
Merged
Conversation
…rameter in the SDK configuration and implement lightning register related methods
This was
linked to
issues
Mar 30, 2026
Nodirbek75
marked this pull request as draft
April 2, 2026 06:11
…when user enables btc wallet
…t id on the default-wallet screen and set-default-account-modal
…method to filter out external wallets
…bitcoin-details screen
Contributor
## Summary
This PR fixes the BTC/Breez external-wallet setup flow and the main manual-send edge case found during simulator testing.
### Fixes included
- Stabilized Breez external wallet setup: (352619d935a32285acb4d7b3e51e275d79365283)
- waits for `updateExternalWallet(input: { lnurlp })` instead of treating it as fire-and-forget
- stores the backend-returned BTC/external `walletId`
- retries registration when `me.username` becomes available after Breez SDK init
- prevents duplicate registration attempts
- shows loading/error/retry states instead of surfacing raw `missing walletIds`
- Fixed manual username sends for USD → BTC-default recipients: (f0acdf2008981d0e67fc7e8d82480ef676293f1e)
- when a sender’s default wallet is USD and the receiver’s default wallet is BTC/Breez, bare username entry now routes through LNURL (`username@<lnAddressHostname>`) instead of the USD intraledger mutation
- USD → USD username sends still use the existing intraledger path
- full lightning address sends continue to use the existing LNURL path
### User testing covered
Tested with:
- Pixel 9 Android simulator
- iPhone 17 simulator
Passing cases:
- External wallet pays Flash user with USD default
- External wallet pays Flash user with BTC default
- Flash BTC default pays Flash USD default
- Flash BTC default pays Flash BTC default
- Flash USD default pays Flash USD default
- Full lightning address works for USD → BTC-default recipient
- Manual bare username now works for USD → BTC-default recipient
### Known follow-up
There is still a separate edge case for non-manual entry points: QR/NFC/card flows that resolve to a bare Flash username may still route through the shared intraledger parser and fail for USD sender → BTC-default receiver.
Tracked separately in Linear: [ENG-399](https://linear.app/island-bitcoin/issue/ENG-399)
|
islandbitcoin
approved these changes
May 22, 2026
islandbitcoin
left a comment
islandbitcoin
left a comment
Contributor
There was a problem hiding this comment.
bugs fixes applied, ACK
5 tasks
islandbitcoin
added a commit
that referenced
this pull request
Jun 20, 2026
…NURL (ENG-399) (#646) A bare Flash username scanned via QR that resolves to a recipient whose default wallet is BTC/Breez previously failed when the sender's wallet was USD: the shared parser treated it as PaymentType.Intraledger and the USD send hit intraLedgerUsdPaymentSend against the recipient's BTC wallet, failing with the generic support error. Manual entry already handled this (PR #602) via a module-private maybeResolveManualUsernameToLnurl. This: - Extracts that helper into payment-destination/resolve-username-to-lnurl.ts so every entry point can share the routing decision (the ticket flags the duplicated-logic risk). - Applies it in the QR-scan processInvoice via the same `maybeResolve... ?? parseDestination` pattern as manual entry, so a BTC-default recipient is re-routed through `username@lnAddressHostname`. - Adds unit tests for the helper covering: non-intraledger pass-through, USD-recipient pass-through, self-payment, successful LNURL re-route, and the unreachable-lightning-address error. Scope: QR is the only entry point that carries a bare username into a send. NFC is receive/withdraw-only (rejects Send-direction, reads lnurl payloads only) and the card flow always carries a Flashcard LNURL, so neither is changed. The durable cross-entry-point fix is the backend resolveSendDestination resolver (ENG-399 Phase 2), filed separately. Co-authored-by: Dread <dread@example.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.