ios: savings empty and transfer in progress after update

[piotr-iohk]

What happened?

User reports that after updating to the latest native iOS app and refreshing, Savings shows 0.00 despite having bitcoin, while TRANSFER IN PROGRESS remains visible.

From logs on 2026-02-25:

• Transfer sync keeps 1 active transfer indefinitely.
• The active order transfer is expired and unresolved:
  • transfer id: e0e00517ec5d09a95be67146f5a0ffa302f8b9705b762f6c78f120078f394077
  • order id: 995ece86-ff6f-4ba4-b45e-6a2a46dc42b8
  • state: expired, has no fundingTx, Could not resolve channel for transfer
• Derived state repeatedly shows:
  • Active transfers: 1
  • Balances in state: onchain=0 ... toSpending=630475

Expected behavior

• Savings should show available on-chain funds after sync/refresh.
• Expired unresolved order transfers should not keep TRANSFER IN PROGRESS stuck forever.

Steps to Reproduce

1. Have an existing wallet with previous transfer/order history.
2. Update to current native iOS build and open app.
3. Refresh/sync wallet on Home.
4. Observe Savings remains 0.00 and TRANSFER IN PROGRESS remains shown.

Logs / Screenshots / Recordings

bitkit_logs_2026-02-25_09-43-11.zip

• Slack thread: https://synonymworkspace.slack.com/archives/C07BJ7DNPCG/p1772012754024529

Bitkit Version

Reported as latest native iOS version.
Log session shows build 177 running and update available to build 178 (v2.0.5).

Device / OS

TBD

Reproducibility

Rarely (once or twice)

Additional context

• Related to Balance from closed channel not appearing in Savings account #457, but not identical due to persistent TRANSFER IN PROGRESS in this case.
• Strongly related to expired transfer cleanup / transfer state reconciliation in TransferService.syncTransferStates.
• Early startup errors also present in session:
  • Failed to get channels for transfer sync
  • Failed to update balance state ... LightningService.balances is nil
• Reporter note on Balance from closed channel not appearing in Savings account #457 : they had confirmed funds missing for ~1 week but did not see TRANSFER IN PROGRESS.
• Slack discussion reference: https://synonymworkspace.slack.com/archives/C07BJ7DNPCG/p1772012754024529

[jvsena42]

Steps to reproduce: Expired Blocktank order inflates total balance

###Setup

1. Start the app on regtest
2. Fund the on-chain wallet with some sats (e.g., 1M sats via regtest faucet)

###Reproduce

1. Initiate a transfer to spending (on-chain → Lightning via Blocktank)
2. Go to Savings wallet → "Transfer to Spending"
3. Enter an amount (e.g., 630,000 sats)
4. Confirm the transfer — this creates a Blocktank order and sends on-chain sats
5. Let the order expire without mining

Do NOT mine any blocks — let the Blocktank order timeout and expire
On regtest/staging, orders expire relatively quickly
Wait until the order state transitions to expired
Verify the bug

1. Open the app and check the home screen
2. Total balance should show the full amount (on-chain + lightning + the expired order amount)
3. Tap Savings (on-chain) → shows 0 sats
4. Tap Spending (lightning) → shows only the lightning balance
5. The expired order amount is included in the total but invisible in both savings and spending

What to check in logs
Look for these log lines confirming the bug:

Order <id> exists but has no fundingTx yet (state: expired)
Could not resolve channel for transfer: <id> orderId: <id>
Order payment transfer: id=<id> orderId=<id> amount=630000
Balances in state: onchain=0 lightning=... toSavings=0 toSpending=630000

Expected (after fix)
syncTransferStates() should detect the expired order and settle the transfer
toSpending should be 0
totalBalanceSats should equal totalOnchainSats + totalLightningSats
Root cause
Bitkit/Services/TransferService.swift#L137-L143 — when resolveChannelId() returns nil for an expired order, the transfer is never settled. It stays "active" forever, and BalanceManager.getOrderPaymentsSats() keeps counting it as toSpending.

[jvsena42]

From RN:

The most likely scenario is actual: The transaction was created but the broadcast itself failed silently. The Electrum server may have returned the txid (which is computed locally from the raw TX, not by the server) but the TX was rejected by the Bitcoin node behind it, perhaps due to a connectivity issue, an already-spent input, or a transient error that beignet's Electrum client didn't surface as an error.

But regardless of why the broadcast didn't stick, the chain of events in the RN app is clear:

1. broadcastTransaction() returned ok(txid)
2. addPaidBlocktankOrder persisted the order in paidOrders
3. The TX never confirmed, order expired
4. handleOrderStateChange crashed on transactions[0].txId (empty array) — cleanup never ran
5. Stale paidOrders entry was backed up and restored by the native app

The root cause on the RN side is the crash at blocktank.ts:305 preventing any cleanup, combined with paidOrders never being pruned even when cleanup does work.