Skip to content

[Bug]: msat-precision invoices fail to send (regular BOLT11 + LNURL pay/withdraw) #511

@piotr-iohk

Description

@piotr-iohk

What happened?

When an invoice amount contains millisatoshis that are not a whole satoshi, payment handling is incorrect.

Observed from repro and user reports:

  • Regular BOLT11 invoices with valueMsat fail in app flows that should pay exact invoice amount.
  • LNURL-pay / LNURL-withdraw flows are also affected for min/max values with msat precision.
  • On iOS specifically (LNURL case), dragging the send slider does not trigger the payment action.

This matches the original Slack report where the app attempted to pay less than invoice amount due to msat handling mismatch.

Expected behavior

  • For invoices with msat precision (for example 222538 msat), app should pay successfully without truncating/invalidating amount.
  • LNURL-pay and LNURL-withdraw with msat-precision limits should execute normally.
  • On iOS, drag-to-send should trigger payment action for msat-precision LNURL flows.

Steps to Reproduce

  1. Use regtest/local setup with channel active and spending balance available.
  2. Reproduce regular invoice case via E2E @send_3 flow (invoices created with lnd.addInvoice({ valueMsat })).
  3. Try invoices with msat precision, e.g. 222538, 222222, 500500.
  4. Reproduce LNURL-pay/LNURL-withdraw msat cases (fixed min == max msat values).
  5. Observe failure behavior (iOS: drag action does not execute for affected LNURL msat case; regular invoice flow also fails for msat invoice handling).

Logs / Screenshots / Recordings

Screen.Recording.2026-03-31.at.11.38.41.mov

bitkit_logs_2026-03-31_09-40-09.zip

Bitkit Version

2.1.2

Device / OS

iPhone 17 simulator, iOS 26.0

Reproducibility

Always

Additional context

  • E2E coverage for this bug class is included in bitkit-e2e-tests PR #140 and should pass after fix.
  • Coverage includes:
    • regular invoice msat cases in send.e2e.ts (@send_3)
    • LNURL pay/withdraw msat cases in lnurl.e2e.ts
  • It would be good to add unit-level coverage in iOS payment amount handling to prevent regressions.

Similar issues check

Potentially related iOS issues reviewed:

  • #449 (open) - [Bug]: Fail to send max / near max lightning payment
  • #277 (open) - LNURL-pay comment not displayed on activity
  • #419 (open) - Unexpected notification on LNURL-withdrawal...

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions