[ovitrif]

Closes #1253

Twin: synonymdev/bitkit-android#1732
Dependency: synonymdev/bitkit-core#182
Refs:

• Design review: Paykit Capabilities, a general capability and intent layer for Paykit peers (answers Paykit Intents question 8) pubky/paykit-rs#229
• Tracking: Pubky Swaps as a Paykit Intents solver coreyphillips/pubky-swap#89

This PR routes a Paykit contact payment through a Pubky Swaps provider when the contact only accepts on-chain bitcoin and the wallet holds only a spending balance.

Description

• Routes a Paykit contact payment through a Pubky Swaps provider when the contact's only endpoints are on-chain and savings is empty (at or below dust) while spending is not, so a wallet holding only spending can still pay that contact. The user never picks a swap: Bitkit asks bitkit-core's router for the route.
• Finds providers in the user's own contact graph: every saved contact is asked for its swap offer over iroh, and those that run no provider are skipped. PUBKY_SWAPS_PROVIDERS adds extra candidates for testing, asked first.
• Takes only signed quotes and contracts: bitkit-core negotiates over paykit-cap.* and refuses a reply not signed by the provider's key or the key its records delegate to.
• Offers only Spending as the source for such a contact, quotes the route on Continue, and shows it on the confirm screen as Route: Pubky Swaps · <provider>, with the whole swap cost in the fee row.
• On swipe, commits the quote for the confirmed amount, pays the provider's hold invoice from spending with the chosen tags, and waits until bitkit-core has broadcast the claim of the provider's on-chain lock straight to the contact's address. The contact receives exactly the amount entered.
• Once the hold invoice is paid, waits on it on the Pending screen, with no way back to a fresh quote that could pay twice. Shows Bitcoin Sent when the hold payment settles, which the provider does on seeing the claim, with the contact on its activity. A refused commit, a failed hold payment or a swap bitkit-core failed shows the payment error screen with Retry from Amount. The claim keeps advancing in the background for up to an hour while the app runs, and a claim not broadcast within 10 minutes leaves the send pending. A quote that returns for a replaced send or another amount is dropped, a swap result reaches only the sheet and quote that started it, and a Direct answer from the router moves the payment to Savings.
• Behind PUBKY_SWAPS_ROUTES (environment or launch argument) on regtest debug builds only.
• After a wallet restore from the seed, rebuilds the swap routes the wallet left in flight from each provider's listing, claims them to a fresh Savings address (the contact's address does not survive the restore), and tells the user the payment was returned to Savings. The restore passes the Lightning payments the node sent, so bitkit-core checks each listed lockup against what was paid. Swaps already on record are driven too, without that notice, since they keep the contact's address.
• Ports the paykit-swap-route.xml journey from Android.

Builds against the bitkit-core release 0.8.0-rc15, which includes synonymdev/bitkit-core#182 (it also links Network.framework for the swap transport). Master's Spark leg (#1191) goes first: a contact payment to an on-chain address takes the swap route when Spark can't carry it, including when Spark's balance is too small for the amount and fee, the order bitkit-core's router weighs service legs and swaps in. A swap-routed send skips master's router on Amount and Confirm, so it never picks up a Spark leg next to its quote.

Why this journey

• Paying a contact over a rail you don't hold is the journey Pubky Swaps supports today, in its Bitcoin form: a Lightning balance pays a contact who only accepts on-chain.
• The USDT forms are blocked: Pubky Swaps is Bitcoin and Lightning only, so USDT needs a second, provider-trusted leg such as NEAR 1Click, which has no testnet (Paykit Capabilities §13.1).

What it needs to ship

• Providers: mainnet Pubky Swaps providers with Lightning and on-chain liquidity among users' contacts. Asking every contact for an offer tells each of them you are looking for a swap (no amount or destination); published Capability Descriptors would replace the probing.
• swap/1 in Paykit: the signed paykit-cap.* negotiation runs over iroh; over Paykit Encrypted Links it needs the additive paykit-rs SDK API for extension kinds (Design review: Paykit Capabilities, a general capability and intent layer for Paykit peers (answers Paykit Intents question 8) pubky/paykit-rs#229, §17).
• Resume: if the app stops between paying and claiming, nothing resumes the claim until the next restore; the funds come back through the timeouts (the provider cancels its hold invoice, or refunds its own lock). A restore rebuilds swaps from providers' listings, within their retention window.
• Fees: the fee row shows the provider's service fee, its on-chain cost and the wallet's claim fee under the Lightning "Instant" label, which reads as a Lightning fee. Lightning routing to the provider is on top. The claim fee rate is fixed at 2 sat/vB and should come from Bitkit's fee estimates.

Out of Scope

• Incoming Paykit payment requests: never swap-routed here, because their payment proofs need the swap's claim txid wired into the proof flow.
• Submarine routes: savings paying a Lightning-only contact.
• USDT routes and allowance auto-pay.
• Resuming an unfinished swap after a restart, and advancing it past the one-hour background window until its claim confirms. Tracked in feat: resume unfinished swaps until their claim confirms #1262 (thread).
• Retrying the swap restore: after a failed wallet start, for providers whose swap list was incomplete or past bitkit-core's 30-candidate cap, and once a pending payment settles. Tracked in feat: retry the swap restore for missed providers #1263 (thread).
• Blocking the way back from Confirm while a swap commits, so a fresh quote can't pay the contact twice. Tracked in bug: swap send can pay twice when leaving confirm mid-commit #1266 (thread).
• Catching a hold-payment failure that lands before the send returns, which now leaves the send pending. Tracked in bug: swap hold failure during send leaves it pending #1267 (thread).
• Clearing swap records on a wallet wipe, in bitkit-core's wipe_all_databases(). Tracked in fix: wipe swap records with the wallet bitkit-core#197 (thread).
• Swap routes for a wallet whose savings is above dust but short of the amount.

Design

N/A — no design available.

Preview

A wallet with only a spending balance pays a contact who accepts only on-chain bitcoin. The router finds a Pubky Swaps provider among the wallet's contacts, the confirm screen shows the route, the quote and contract are signed, and the contact receives exactly 20,000 sats on chain (iPhone simulator (iOS 27.0), 2x speed, regtest).

ios-signed-swaps-route-2x.mp4

After a wallet restore from the seed, the swap the wallet left in flight before its claim is found at its provider and claimed to Savings, with the "Payment returned to Savings" notice (iPhone simulator (iOS 26.5), 2x speed, regtest; the phrase entry is not recorded). Recorded on bitkit-core 0.8.0-swaps.4, before restores took the node's payments.

ios-restore-j22x.mp4

QA Notes

Setup

• Chain, provider and contact: feat: local pubky swaps provider bitkit-docker#39, README "Pubky Swaps" (branch feat/pubky-swap-provider until it merges): the stack, the pubky-swaps profile with the provider at f45e204 on the stack's LND, the marketplace and fixture-issuer fixtures (the on-chain-only contact), and the LNURL-pay fixture. docker compose logs pubky-swap | grep "Provider pubky" gives the provider's pubky.
• App: xcodebuild build -project Bitkit.xcodeproj -scheme Bitkit -configuration Debug -destination 'platform=iOS Simulator,name=<simulator>' 'SWIFT_ACTIVE_COMPILATION_CONDITIONS=$(inherited) E2E_BUILD' ARCHS=arm64 E2E_BACKEND=local E2E_NETWORK=regtest E2E_HOMESERVER_PUBKY=$(./pubky-marketplace info | jq -r .homeserver_z32), installed on a simulator on the same Mac as bitkit-docker and launched with xcrun simctl launch <udid> to.bitkit -PUBKY_SWAPS_ROUTES=true. The simulator reaches the host loopback directly.
• Wallet: a new wallet; open the LNURL channel from curl -H 'Host: 127.0.0.1:23010' 127.0.0.1:23010/generate/channel (500,000 sats to spending, opened with xcrun simctl openurl <udid> lightning:<lnurl>); leave savings empty; create a Pubky profile; save the provider's and the fixture-issuer's pubkys as contacts (bitkit://contact?pubky=<pubky>).
• If ./pubky-marketplace restarts the testnet container, restart homeserver-proxy, paykit-server, fixture-issuer and rc56-peer too: they share its network namespace, and profile creation fails with "complete Pubky auth flow" otherwise.

Journeys

• J1: new paykit-swap-route.xml — a spending-only wallet pays an on-chain-only contact through a Pubky Swaps provider found among its contacts, and the contact receives exactly 20,000 sats
• J2: new paykit-swap-restore.xml — a swap route left in flight before its claim is finished after a wipe and a restore from the recovery phrase: claimed to Savings, with the "Payment returned to Savings" notice

Manual Tests

N/A

Automated Checks

• added PubkySwapsRouteServiceTests.swift — configured providers are asked first and each key once
• updated ContactsManagerTests.swift — swap restore waits for a running contact load, or its timeout
• updated SendConfirmationViewTests.swift — swap warnings read the quote's debit from Spending; a late swap result reaches only the sheet and quote that started it; only a swap bitkit-core failed ends a sent hold payment
• ran SendConfirmationViewTests and PubkySwapsRouteServiceTests on an iPhone simulator (iOS 27.0) at d2621c6: pass; ContactsManagerTests passed at e878153; the app builds for the simulator (arm64) at d2621c6

Evidence

• J1 and J2 at 58139bc5d (bitkit-core 0.8.0-rc15) on a regtest iPhone 17 Pro simulator (iOS 27.0), against feat: local pubky swaps provider bitkit-docker#39's stack: both pass. Recordings, claim txids and notes are in feat: pay contacts via pubky swaps #1170 (comment).
• J1 via the saved issuer contact at 58139bc5d, against feat: local pubky swaps provider bitkit-docker#39 with its rc8 fixture-issuer: passes, with no recovery_required. Confirm showed the contact as TO and the Pubky Swaps route; the recording and claim txid are in feat: pay contacts via pubky swaps #1170 (comment).
• J1 at efc33fa on a regtest iPhone simulator (iOS 27.0), bitkit-core 0.8.0-swaps.9, provider coreyphillips/pubky-swap f45e204 with --no-homeserver, and no PUBKY_SWAPS_PROVIDERS, so the provider came only from the wallet's contacts (the recording above):
  • the confirm screen showed Route: Pubky Swaps · udi3...ez6y and a fee of ₿ 986 for 20,000 sats;
  • the provider's record of the swap holds the contract signed over the wallet's commit, signed by its own key;
  • the provider logged hold invoice accepted, HTLC funded; awaiting client claim and, after one block, client claimed; hold invoice settled;
  • the claim, 66fed8c1caaea25aedd3151d679baa2944c1ee3e17beddddaab74ddee2461c0a, has one input, the provider's HTLC, and one output of exactly 0.0002 BTC to the contact's address; Spending went from ₿ 500,000 to ₿ 479,014.
  • The contact was paid as a pubky entered on the Send screen: the fixture-issuer gets a new pubky when it restarts, so the saved contact pointed at its old identity and ended in recovery_required. That is a fixture artefact, unrelated to the route; the missing fail-fast is tracked in bug: saved contact payment stalls instead of failing #1254.
  • fab6cf8 since finishes the send on the broadcast claim and adds the review fixes; it was built and unit-tested, not rerun on the simulator.
• J2 on a regtest iPhone simulator (iOS 26.5) at 83940d3, bitkit-core 0.8.0-swaps.4, provider coreyphillips/pubky-swap main with --no-homeserver:
  • the swap was started, the provider logged "HTLC funded; awaiting client claim", and the app was killed before any block; the wallet was then wiped and restored from its throwaway regtest recovery phrase;
  • the restore listed the swap at the provider, the claim went out after one block, and the provider logged "client claimed; hold invoice settled";
  • Savings went from 0 to ₿ 20,000, the "Payment returned to Savings" notice showed, and the swap's activity turned to Sent.
  • The notice showed before the "Received Bitcoin" sheet, which iOS opens once the claim confirms.
  • The app was launched with -PUBKY_SWAPS_PROVIDERS naming the provider, in case contacts had not reloaded when the restore ran.
• J1 earlier on a regtest iPhone simulator (iOS 26.5), before quotes were signed, with bitkit-core 0.8.0-swaps.2 and no PUBKY_SWAPS_PROVIDERS, so the provider came only from the wallet's contacts (the recording above). The build was 7315045 before its formatting-only change to the new service file:
  • the amount screen offered only Spending; the confirm screen showed Route: Pubky Swaps · 5no8...pquo and a fee of ₿ 986 for 20,000 sats;
  • the provider logged HTLC funded; awaiting client claim and, after one block, client claimed; hold invoice settled;
  • the claim transaction has one input, the provider's HTLC, and one output of exactly 0.0002 BTC to the contact's address;
  • Bitcoin Sent showed ₿ 20,000, and the activity list shows the Lightning payment of ₿ 20,986.
• A second take of J1 paid the same way.
• An earlier run whose swipe came over two minutes after the quote ended in the payment error screen: the provider refused the commit with quote_expired, and nothing was paid.
• At 01198d3, on bitkit-core 0.8.0-swaps.3, the unit test selection passes apart from three PaykitPaymentProofServiceTests cases whose billing periods ended on 1 Nov; master fixed them in 421e152 ("test: keep proof billing periods in the current month"), and this PR's CI runs on the merge with master.
• At 08cc333, on bitkit-core 0.8.0-swaps.4, the unit test selection passes apart from the same three date-bound PaykitPaymentProofServiceTests cases; the restore after a wallet restore is not covered by a unit test or a device run yet.
• The unit and UI test selection of unit-tests.yml passed at 7315045; SwiftFormat lint is clean on the changed files apart from findings already on master, and validate-translations.js passes.

Gaps

• The provider's contact entry has no Pubky profile, so the route shows its key rather than a name.
• A quote that expires on the confirm screen needs a trip back to the amount screen for a new one; the error screen's Retry was not tried.
• Unlike Android, Bitcoin Sent opens the Lightning payment's activity, since the claim transaction is not the wallet's own.

Models used

• Planning/scoping: claude-opus-5-5 (reasoning: medium)
• Implementation: claude-opus-5-5 (reasoning: medium)
• Review: Not performed

[ovitrif]

Pushed 01198d3: moves to bitkit-core 0.8.0-swaps.3, whose Paykit router takes service legs (synonymdev/bitkit-core#184).

• Passes no service legs yet, so routing behaves as before; Arkade and Spark legs come in their own PRs on top of the Arkade and Spark work.
• Handles the router's new Service route, which cannot be returned while no legs are passed.
• The unit test selection passes apart from three date-bound PaykitPaymentProofServiceTests cases that master fixed in 421e152.

[ovitrif]

Pushed 08cc333: after a wallet restore, rebuilds in-flight swap routes from each provider's listing (bitkit-core 0.8.0-swaps.4, pubky_swaps_restore from synonymdev/bitkit-core#182).

• Restored swaps claim to a fresh Savings address, since the contact's address isn't in the listing. Once a claim confirms, a toast tells the user the payment was returned to Savings. The two strings are added in every locale.
• The unit test selection passes apart from the three date-bound proof tests master fixed in 421e152; translations validate. Not covered yet: a unit test or device run of the restore path.

[ovitrif]

Pushed 83940d3: adds the paykit-swap-restore.xml journey (J2), recorded on an iOS 26.5 simulator: a swap left in flight before its claim is finished after a wipe and restore, claimed to Savings, and the "Payment returned to Savings" notice shows. The recording and evidence are in the description.

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-09T22:29:04.155691Z	fab6cf8	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[ovitrif]

@coreyphillips one more version step: bitkit-core 0.8.0-swaps.11 adds a fix from Ben's review of synonymdev/bitkit-core#182, which refuses a new swap whose id is already on file. Still no app code changed since 4bee733.

[coreyphillips]

Rechecked after 2 new commits (bd19f96, 76f8374). Nothing blocking remains.

still open

• Background claim advancing stops after an hour, not at confirmation (Bitkit/Services/PubkySwapsRouteService.swift:21). The PR says the claim keeps advancing in the background until it confirms, but the loop stops after 60 minutes. confirmationTimeout is 60 minutes (PubkySwapsRouteService.swift:21), and the detached loop in awaitClaim then logs and exits. The claim fee is a fixed 2 sat/vB with no bump, so a claim that drops out of mempools after that hour is never rebroadcast. The provider settles the hold invoice as soon as it sees the claim. If the claim then does not confirm before the lock's timeout_block_height, the provider can also refund its lockup. The user pays and the contact receives nothing. This cannot happen today: the flag is regtest-only and bitkit-core refuses mainnet commits. It does need to change before the flag goes, and the description currently says otherwise. No app code changed since 4bee733. confirmationTimeout is still 60 minutes (PubkySwapsRouteService.swift:28), and advanceInBackground still stops there. The description now says "up to an hour" and #1262 tracks the behaviour, but the doc comments at :25 and :135 still say the claim is rebroadcast until it confirms.
• Swap restore runs once and is skipped if the wallet start fails (Bitkit/AppScene.swift:1268). restorePubkySwaps() runs right after startWallet(completingBackupRestore: true) (AppScene.swift:1268), whether or not the node actually started. startWallet returns early when offline and swallows start errors. In that case restoreSwaps throws (no node for newAddress/listPayments), and the error is only logged. retryWalletStart (AppScene.swift:1300) and later wallet starts never call it again. In those cases the swap J2 covers is never claimed and waits for the provider's timeout instead. Funds return through that timeout, so this is not urgent. A retry once the node is running would close the gap. AppScene.swift:1267-1268 still calls restorePubkySwaps() once, whatever startWallet did. retryWalletStart (:1301-1310) still never calls it. Deferring it to #1263 tracks the gap without closing it.
• Old swap results overwrite an edited payment in the same sheet (Bitkit/Views/Wallets/Send/SendConfirmationView.swift:1381-1382). While a 20,000-sat commit waits, the user can return to Amount and continue with 30,000 sats in the same sheet. The unchanged presentation ID accepts the old result: success opens Bitcoin Sent displaying the new draft amount, while failure clears the replacement quote. Both branches reproduced with the extracted payment method and a suspended commit. The quote check in isSwapRouteResultCurrent (SendConfirmationView.swift:1372-1379) settles the failure branch, and the case where the new quote has already landed. One path remains: Q1's send returns after Continue on Amount but before Q2 lands. Q1 is then still the active quote, so Pending (:1422) and Bitcoin Sent show wallet.sendAmountSats, which SendAmountView.swift:377 has already set to the new amount. I traced this but did not run it.
• Swap records survive a successful wallet wipe (Bitkit.xcodeproj/project.pbxproj:1244). After a routed payment, the in-app wallet wipe leaves its swap records behind. The pinned release writes contracts, destination addresses, amounts and signed claims to core/pubky_swaps/*.json. Its wipe_all_databases() clears only activity and Blocktank tables, while AppReset deletes only LDK storage. Swap history and any saved claim preimage therefore survive a successful wipe. The new pin's wipe_all_databases (bitkit-core src/lib.rs:2080 at 4f3e215) still clears only the activity and Blocktank stores, and AppReset is unchanged. Swap records still survive a wipe. Tracked in bitkit-core#197.
• Going back to Amount during the swap commit can still pay a second swap (Bitkit/Views/Wallets/Send/SendConfirmationView.swift:1406-1424). 4bee733 removes the way back to Amount once the hold invoice is paid. Before that point, during commit, decode and send (SendConfirmationView.swift:1406-1415), the user can still go back, request a fresh quote and pay a second swap. While isSubmittingPayment is true, the header back button (showBackButton: !navigationPath.isEmpty, :336) and the amount tap (navigateToAmount, gated only by canEditAmount, :253) both stay live. On Amount, Continue starts quoteSwapRoute, which asks every contact for an offer, so it usually takes longer than the commit to one provider. What follows, in order: 1. Q1's send returns while the user is on Amount. isSendCurrent() still passes because Q1 is still the active quote, so .pending is appended on top of Amount (:1422). 2. performSwapRoutedPayment returns, which releases isSubmittingPayment. 3. Q2 arrives. Its guard (SendAmountView.swift:474-476) still passes, because nothing cleared Q1. It stores Q2 and appends .confirm on top of Pending (:409). 4. That Confirm's swipe is enabled. A swipe commits and pays a second swap, so the contact is paid twice. If Q2 lands before Q1's send returns, the outcome is the same and quieter. isSendCurrent() fails, so Q1 is paid with no navigation and no toast. Q2's swipe unlocks as soon as Q1's call returns. I confirmed this by tracing the code above, and SwipeButton runs its action in an unstructured Task that is not cancelled when Confirm is popped. I did not run it: there is no provider or simulator here. It is non-blocking only because the route is behind the regtest debug flag. Two possible fixes: - Hide back and amount editing on Confirm while a swap payment is submitting. - Have quoteSwapRoute drop its result when a payment is submitting or when the path no longer ends at Amount. The reply defers this to #1266 and does not dispute it. canEditAmount (SendConfirmationView.swift:253-260) and showBackButton (:336) still ignore isSubmittingPayment, so going back during the commit can still lead to a second swap.
• Fast hold-payment failures are missed before pending registration (Bitkit/Views/Wallets/Send/SendConfirmationView.swift:1415-1424). A hold payment that fails before submission returns now opens Pending without a failure resolution. The failure listener is installed in driveSwapClaim after the awaited send, and pending registration also happens afterward. I reproduced this with the extracted methods by delivering paymentFailed during submission: HEAD retained the failed hash without a resolution, while d2621c6 opened Failure. The reply defers this to #1267 and agrees it is a regression. send (SendConfirmationView.swift:1415) still runs before both addPendingPaymentHash (:1420) and the paymentFailed listener in driveSwapClaim (:1463).

[jvsena42]

Delta review of bd19f96 and 76f8374 (bitkit-core 0.8.0-swaps.9 → 0.8.0-swaps.11): no findings. No Swift changed.

• What the core diff adds: store::create, which refuses a swap whose id is already saved. It runs in commit_route before the app pays the hold invoice, so a refusal moves no funds and lands on the existing "refused commit → Retry from Amount" path. In restore_swaps a known record still continues before create.
• What it leaves alone: SwapRecord and its JSON, key derivation, hold-invoice validation and claim logic. So swaps that testers saved under swaps.9 still restore.
• Other core changes: the API breaks are all in wake, which the app doesn't call. The swap FFI signatures are unchanged.
• Twin note: Android #1732 still pins swaps.9. No swaps.10 or swaps.11 Android artifact is published yet, so the twins differ on this refusal until one is.

The device gate is still pending.

Reviewer model: Claude Fable 5.1 (claude-fable-5-1), Claude Opus 5.5 (claude-opus-5-5)
Reasoning effort: not exposed

[ovitrif]

@coreyphillips moved bitkit-core from the 0.8.0-swaps.11 prerelease to the 0.8.0-rc14 release in d57e2bc, now that synonymdev/bitkit-core#182 is merged. Only the pin changed, so a re-approval is needed only because of the dependency bump.

[coreyphillips]

Rechecked after 1 new commit (d57e2bc). Nothing blocking remains.

still open

• Background claim advancing stops after an hour, not at confirmation (Bitkit/Services/PubkySwapsRouteService.swift:21). The PR says the claim keeps advancing in the background until it confirms, but the loop stops after 60 minutes. confirmationTimeout is 60 minutes (PubkySwapsRouteService.swift:21), and the detached loop in awaitClaim then logs and exits. The claim fee is a fixed 2 sat/vB with no bump, so a claim that drops out of mempools after that hour is never rebroadcast. The provider settles the hold invoice as soon as it sees the claim. If the claim then does not confirm before the lock's timeout_block_height, the provider can also refund its lockup. The user pays and the contact receives nothing. This cannot happen today: the flag is regtest-only and bitkit-core refuses mainnet commits. It does need to change before the flag goes, and the description currently says otherwise. The description now says the claim advances for up to an hour, which matches the code, and #1262 tracks the rest. The code is unchanged: confirmationTimeout is still 60 minutes (PubkySwapsRouteService.swift:28), and the detached loop at :150-153 still stops there with a fixed 2 sat/vB claim, so this still needs fixing before the flag goes.
• Swap restore runs once and is skipped if the wallet start fails (Bitkit/AppScene.swift:1268). restorePubkySwaps() runs right after startWallet(completingBackupRestore: true) (AppScene.swift:1268), whether or not the node actually started. startWallet returns early when offline and swallows start errors. In that case restoreSwaps throws (no node for newAddress/listPayments), and the error is only logged. retryWalletStart (AppScene.swift:1300) and later wallet starts never call it again. In those cases the swap J2 covers is never claimed and waits for the provider's timeout instead. Funds return through that timeout, so this is not urgent. A retry once the node is running would close the gap. AppScene.swift:1267-1268 still calls restorePubkySwaps() once after startWallet(completingBackupRestore: true), whether or not the node started. retryWalletStart (:1301) still never calls it. Tracking it in #1263 defers the point but does not fix or rebut it.
• Old swap results overwrite an edited payment in the same sheet (Bitkit/Views/Wallets/Send/SendConfirmationView.swift:1381-1382). While a 20,000-sat commit waits, the user can return to Amount and continue with 30,000 sats in the same sheet. The unchanged presentation ID accepts the old result: success opens Bitcoin Sent displaying the new draft amount, while failure clears the replacement quote. Both branches reproduced with the extracted payment method and a suspended commit. Claude still sees it: The quote-ID check (SendConfirmationView.swift:1367-1376, 1393-1400) helps only once Q2 is stored. onContinue sets wallet.sendAmountSats to the new amount (SendAmountView.swift:377) before quoteSwapRoute stores Q2, so Q1 still passes isSendCurrent() in that window. Q1's success therefore pushes Pending, and later Bitcoin Sent, with the edited amount. Q1's failure nils the route's quote (:1443), which makes Q2's app.paykitSwapRoute == route guard drop the replacement quote silently.
• Swap records survive a successful wallet wipe (Bitkit.xcodeproj/project.pbxproj:1244). After a routed payment, the in-app wallet wipe leaves its swap records behind. The pinned release writes contracts, destination addresses, amounts and signed claims to core/pubky_swaps/*.json. Its wipe_all_databases() clears only activity and Blocktank tables, while AppReset deletes only LDK storage. Swap history and any saved claim preimage therefore survive a successful wipe. I checked rc14 (8fbf1d75): wipe_all_databases() in src/lib.rs:2092 still wipes only the activity and Blocktank databases. The swap store opened at lib.rs:524 is untouched, so the records still survive a wipe. This is tracked in synonymdev/bitkit-core#197, not fixed.
• Going back to Amount during the swap commit can still pay a second swap (Bitkit/Views/Wallets/Send/SendConfirmationView.swift:1406-1424). 4bee733 removes the way back to Amount once the hold invoice is paid. Before that point, during commit, decode and send (SendConfirmationView.swift:1406-1415), the user can still go back, request a fresh quote and pay a second swap. While isSubmittingPayment is true, the header back button (showBackButton: !navigationPath.isEmpty, :336) and the amount tap (navigateToAmount, gated only by canEditAmount, :253) both stay live. On Amount, Continue starts quoteSwapRoute, which asks every contact for an offer, so it usually takes longer than the commit to one provider. What follows, in order: 1. Q1's send returns while the user is on Amount. isSendCurrent() still passes because Q1 is still the active quote, so .pending is appended on top of Amount (:1422). 2. performSwapRoutedPayment returns, which releases isSubmittingPayment. 3. Q2 arrives. Its guard (SendAmountView.swift:474-476) still passes, because nothing cleared Q1. It stores Q2 and appends .confirm on top of Pending (:409). 4. That Confirm's swipe is enabled. A swipe commits and pays a second swap, so the contact is paid twice. If Q2 lands before Q1's send returns, the outcome is the same and quieter. isSendCurrent() fails, so Q1 is paid with no navigation and no toast. Q2's swipe unlocks as soon as Q1's call returns. I confirmed this by tracing the code above, and SwipeButton runs its action in an unstructured Task that is not cancelled when Confirm is popped. I did not run it: there is no provider or simulator here. It is non-blocking only because the route is behind the regtest debug flag. Two possible fixes: - Hide back and amount editing on Confirm while a swap payment is submitting. - Have quoteSwapRoute drop its result when a payment is submitting or when the path no longer ends at Amount. Neither gate changed. showBackButton: !navigationPath.isEmpty (SendConfirmationView.swift:336) and canEditAmount (:253) still ignore isSubmittingPayment. quoteSwapRoute (SendAmountView.swift:474-476) still accepts Q2 while Q1 is the active quote, so Q2's Confirm can be pushed over Pending. Tracked in #1266, not fixed.
• Fast hold-payment failures are missed before pending registration (Bitkit/Views/Wallets/Send/SendConfirmationView.swift:1415-1424). A hold payment that fails before submission returns now opens Pending without a failure resolution. The failure listener is installed in driveSwapClaim after the awaited send, and pending registration also happens afterward. I reproduced this with the extracted methods by delivering paymentFailed during submission: HEAD retained the failed hash without a resolution, while d2621c6 opened Failure. send(bolt11:) is still awaited at SendConfirmationView.swift:1415, before addPendingPaymentHash (:1419) and before the paymentFailed listener in driveSwapClaim (:1463). A failure delivered during the send is still missed. Tracked in #1267, not fixed.

[jvsena42]

Delta review of d57e2bc1b (bitkit-core 0.8.0-swaps.11 → 0.8.0-rc14): no findings.

• v0.8.0-swaps.11 is an ancestor of v0.8.0-rc14, and the swaps merge (core#182) has a tree identical to swaps.11. So no swap code is dropped, and swaps saved under swaps.11 restore as before.
• rc14 adds only regtest basic auth (core#201, #203): a trailing auth: String? = nil on the regtest calls. The CoreService callers compile unchanged, and build-local passes.
• The Package.swift checksum matches the rc14 BitkitCore.xcframework.zip.

⚠️ Device gate: still not run — J1/J2 need the pubky-swap provider (coreyphillips/pubky-swap f45e204) against bitkit-docker's LND and the marketplace stack. I'll run it on a later pass.

Reviewer model: Claude Fable 5.2 (claude-fable-5-2), Claude Opus 5.5 (claude-opus-5-5)
Reasoning effort: not exposed

[ovitrif]

Merged master in 6f1859b. The only conflicts were the package pins: bitkit-core stays on 0.8.0-rc14, which contains master's 0.8.0-rc13, and paykit, ldk-node and vss take master's versions. No code changed, so a re-approval is needed only because of the base merge.

[coreyphillips]

Rechecked after 42 new commits (5aafcfd, 75fe13b, 265389e, and 39 more). Nothing blocking remains.

still open

• Background claim advancing stops after an hour, not at confirmation (Bitkit/Services/PubkySwapsRouteService.swift:21). The PR says the claim keeps advancing in the background until it confirms, but the loop stops after 60 minutes. confirmationTimeout is 60 minutes (PubkySwapsRouteService.swift:21), and the detached loop in awaitClaim then logs and exits. The claim fee is a fixed 2 sat/vB with no bump, so a claim that drops out of mempools after that hour is never rebroadcast. The provider settles the hold invoice as soon as it sees the claim. If the claim then does not confirm before the lock's timeout_block_height, the provider can also refund its lockup. The user pays and the contact receives nothing. This cannot happen today: the flag is regtest-only and bitkit-core refuses mainnet commits. It does need to change before the flag goes, and the description currently says otherwise. confirmationTimeout is still 60 minutes (PubkySwapsRouteService.swift:28), and the detached loop at :149-160 still logs and exits. The description now says "up to an hour" and defers the rest to #1262, which settles the description mismatch. The doc comments at :25 and :133-135 still promise rebroadcasts "until it confirms", and the behaviour itself is unchanged.
• Swap restore runs once and is skipped if the wallet start fails (Bitkit/AppScene.swift:1268). restorePubkySwaps() runs right after startWallet(completingBackupRestore: true) (AppScene.swift:1268), whether or not the node actually started. startWallet returns early when offline and swallows start errors. In that case restoreSwaps throws (no node for newAddress/listPayments), and the error is only logged. retryWalletStart (AppScene.swift:1300) and later wallet starts never call it again. In those cases the swap J2 covers is never claimed and waits for the provider's timeout instead. Funds return through that timeout, so this is not urgent. A retry once the node is running would close the gap. restorePubkySwaps() is still called once, right after startWallet(completingBackupRestore:) (AppScene.swift:1268), and retryWalletStart (:1301-1310) still does not call it. This is deferred to #1263, which is open; no code changed.
• Old swap results overwrite an edited payment in the same sheet (Bitkit/Views/Wallets/Send/SendConfirmationView.swift:1381-1382). While a 20,000-sat commit waits, the user can return to Amount and continue with 30,000 sats in the same sheet. The unchanged presentation ID accepts the old result: success opens Bitcoin Sent displaying the new draft amount, while failure clears the replacement quote. Both branches reproduced with the extracted payment method and a suspended commit. Part of this is fixed. The quote-ID check (SendConfirmationView.swift:1372-1378, used at :1394-1400) stops an old result from navigating or clearing the quote once the edited payment's fresh quote is stored. The window between Continue on Amount and the fresh quote landing is still open. In it, SendAmountView.swift:377 has already set wallet.sendAmountSats to the edited amount, while the old quote is still the active one. The old send then passes isSendCurrent() and pushes Pending (:1422). Pending (SendPendingScreen.swift:110-111) and SendSuccess (:47-48) both show the edited amount. #1266 now records this window, so it closes with point 5.
• Swap records survive a successful wallet wipe (Bitkit.xcodeproj/project.pbxproj:1244). After a routed payment, the in-app wallet wipe leaves its swap records behind. The pinned release writes contracts, destination addresses, amounts and signed claims to core/pubky_swaps/*.json. Its wipe_all_databases() clears only activity and Blocktank tables, while AppReset deletes only LDK storage. Swap history and any saved claim preimage therefore survive a successful wipe. Nothing changed. The merge did not touch AppReset, and per the delta review core rc14 only adds regtest auth on top of swaps.11, so wipe_all_databases() still leaves pubky_swaps/*.json. This is deferred to bitkit-core#197, which is open.
• Going back to Amount during the swap commit can still pay a second swap (Bitkit/Views/Wallets/Send/SendConfirmationView.swift:1406-1424). 4bee733 removes the way back to Amount once the hold invoice is paid. Before that point, during commit, decode and send (SendConfirmationView.swift:1406-1415), the user can still go back, request a fresh quote and pay a second swap. While isSubmittingPayment is true, the header back button (showBackButton: !navigationPath.isEmpty, :336) and the amount tap (navigateToAmount, gated only by canEditAmount, :253) both stay live. On Amount, Continue starts quoteSwapRoute, which asks every contact for an offer, so it usually takes longer than the commit to one provider. What follows, in order: 1. Q1's send returns while the user is on Amount. isSendCurrent() still passes because Q1 is still the active quote, so .pending is appended on top of Amount (:1422). 2. performSwapRoutedPayment returns, which releases isSubmittingPayment. 3. Q2 arrives. Its guard (SendAmountView.swift:474-476) still passes, because nothing cleared Q1. It stores Q2 and appends .confirm on top of Pending (:409). 4. That Confirm's swipe is enabled. A swipe commits and pays a second swap, so the contact is paid twice. If Q2 lands before Q1's send returns, the outcome is the same and quieter. isSendCurrent() fails, so Q1 is paid with no navigation and no toast. Q2's swipe unlocks as soon as Q1's call returns. I confirmed this by tracing the code above, and SwipeButton runs its action in an unstructured Task that is not cancelled when Confirm is popped. I did not run it: there is no provider or simulator here. It is non-blocking only because the route is behind the regtest debug flag. Two possible fixes: - Hide back and amount editing on Confirm while a swap payment is submitting. - Have quoteSwapRoute drop its result when a payment is submitting or when the path no longer ends at Amount. Both ways back are still live during the commit. The header back button is shown on !navigationPath.isEmpty (SendConfirmationView.swift:336), and navigateToAmount (:2102-2105) is gated only by canEditAmount (:253-260), which ignores isSubmittingPayment. The quote guard in SendAmountView.swift:473-475 still does not check for a submitting payment. Deferred to #1266, which is open.
• Fast hold-payment failures are missed before pending registration (Bitkit/Views/Wallets/Send/SendConfirmationView.swift:1415-1424). A hold payment that fails before submission returns now opens Pending without a failure resolution. The failure listener is installed in driveSwapClaim after the awaited send, and pending registration also happens afterward. I reproduced this with the extracted methods by delivering paymentFailed during submission: HEAD retained the failed hash without a resolution, while d2621c6 opened Failure. The order is unchanged. send(bolt11:) is at SendConfirmationView.swift:1415 and addPendingPaymentHash at :1420. The paymentFailed listener is only installed in driveSwapClaim at :1463, so a failure handled before the send returns is still dropped. Deferred to #1267, which is open.

[ovitrif]

Merged master in (3ca711e) to clear the conflict. Master moved to bitkit-core 0.8.0-rc15, which only bumps lightning-invoice to 0.34.2, so this PR now builds on rc15 too. The only conflicting lines were the bitkit-core pins, and I took master's. @coreyphillips this needs your re-approval only because of the base merge: the PR's own code is unchanged since 6f1859b.

[ovitrif]

Merged master in (04d25e5) to clear the conflict with #1128, which brought Spark contact payments and their own Paykit router. Both routes now live side by side:

• A contact payment to an on-chain address takes Spark's leg first, when Spark is ready and holds a balance, and the Pubky Swaps route otherwise. That's the order bitkit-core's router weighs service legs and swaps in.
• A swap-routed send skips master's router on Amount (which would refuse it, since the router is asked for no swaps) and on Confirm (which could add a Spark leg next to the swap quote).
• Strings, Confirm views, the warning amounts and the tests keep both sides.

The app and test target build. @coreyphillips this needs a real re-review, not just a re-approval: the merge decides how the two routes share a send. Reverse the order if you want the swap first. Asking the core router for swaps on both sides would be a follow-up.

[ben-kaufman]

A small Spark balance can block the available Pubky Swaps fallback.

Reviewer model: gpt-6.1-sol
Reasoning effort: xhigh

[ben-kaufman]

Editing during Spark quoting can leave the swap fallback with a different amount.

Reviewer model: gpt-6.1-sol
Reasoning effort: xhigh

[ovitrif]

QA: J1 and J2 pass at 58139bc (bitkit-core 0.8.0-rc15) on a regtest iPhone 17 Pro simulator (iOS 27.0). The stack is synonymdev/bitkit-docker#39's pubky-swaps profile: the Pubky Swaps provider at f45e204 on bitkit-docker's LND and Electrum, plus the marketplace and fixture-issuer fixtures. The app launched with -PUBKY_SWAPS_ROUTES=true.

J1: paykit-swap-route.xml	J2: paykit-swap-restore.xml
j1-swap-route2x.mp4	j2-swap-restore2x.mp4

J1, Spending only (500,000 sats, Savings 0), paying the on-chain-only fixture-issuer 20,000 sats:

• Confirm showed FROM Spending, the route Pubky Swaps · 31i8...6kgy and a fee of ₿ 1,265.
• The provider logged hold invoice accepted, HTLC funded; awaiting client claim and, after one block, client claimed; hold invoice settled.
• The claim, f0b461b90144a951f2527046c61ef8e508a3a04c8f1352c5db41cd14fdc8b87b, spends only the provider's HTLC and pays exactly 0.0002 BTC to the issuer's address.
• Bitcoin Sent showed ₿ 20,000, and Spending went from 500,000 to 478,735 (20,000 plus the 1,265 fee).

J2: the swap was started, the provider funded its HTLC, and the app was killed before any block. Then the app was reinstalled with its keychain reset, and the wallet restored from its recovery phrase:

• The restore found the swap (Restored 1 Pubky Swaps routes).
• After one block the claim went out, the "Payment returned to Savings" notice showed, and the provider logged client claimed; hold invoice settled.
• The claim, 508c8bbb943775420340cb841aa403f10282746b1350d5e3015d3c4de8ca0c05, pays exactly 0.0002 BTC to the restored wallet's own Savings address.
• Savings shows ₿ 20,000, and the swap's activity is Sent 21,265.

Not as written:

• J1 step 3 paid the issuer by its pubky through Enter Manually, not as a saved contact: tapping the contact logged recovery_required against the stack's older issuer. The rerun via the saved contact on the rc8 issuer passes: feat: pay contacts via pubky swaps #1170 (comment).
• J2 restored the J1 wallet itself and paid the issuer by manual entry too.

[ovitrif]

QA: J1 passes via the saved issuer contact at 58139bc (bitkit-core 0.8.0-rc15), on a regtest iPhone 17 Pro simulator (iOS 27.0). The stack is synonymdev/bitkit-docker#39 with main merged in, so its fixture-issuer runs on Paykit rc8 (synonymdev/bitkit-docker#38). The app logged no recovery_required.

J1 via the saved contact: paykit-swap-route.xml
j1-saved-contact.mp4

J1, Spending only (500,000 sats, Savings 0), paying the saved fixture-issuer contact 20,000 sats:

• Send, then Contact, listed the provider and the issuer. Tapping the issuer opened the amount screen.
• Confirm showed FROM Spending, TO the contact jir5...33xo, the route Pubky Swaps · 31i8...6kgy and a fee of Instant (₿ 1 265).
• The provider logged hold invoice accepted, HTLC funded; awaiting client claim and, after one block, client claimed; hold invoice settled.
• The claim, 0e6e53ee8a80578baf712a150313228a6b08f53eec9088ebd616a6b8101a6cd3, spends only the provider's HTLC and pays exactly 0.0002 BTC to the issuer's address.
• Spending went from 500,000 to 478,735 (20,000 plus the 1,265 fee). The activity row is Sent to jir5...33xo with the contact's avatar.

Setup: the issuer must be linked to the wallet and have sent it its private payment list before the tap. synonymdev/bitkit-docker#39's README has the three calls.

Not as written: the journey's SendAmount and SendConfirm tags are missing from the accessibility tree, so the run checked those screens by the elements on them (AssetButton-spending, SendConfirmToggleDetails). The recording cuts the wait on the amount screen.