Skip to content

BOLT12 Recurring Payments in LDK Node #1208

Open

Description

@shaavan

This issue tracks the implementation of BOLT12 recurring payments in LDK Node, following lightning/bolts#1240 and building on the protocol support in the lightningdevkit/rust-lightning#4882

The work is split into two independent PRs for receiving and sending recurring payments, followed by a shared integration PR that builds on both. Each PR documents its own implementation details and remaining work.

Progress

Inbound Recurrence

Enable receiving and tracking recurring payments, with persistent records linking offers to their payers. This includes payment progress, pending claims, cancellation status, and lookup and list APIs.

The implementation preserves progress across restarts and event replay, prevents duplicate payments for the same period, and allows already accepted payments to settle after cancellation.

Outbound Recurrence

Enable sending and tracking recurring payments through manual operations to initiate a relationship, pay the next period, retry failed payments, and cancel future payments.

Persistent records retain the offer, payment settings, progress, and continuity state needed for subsequent payments. Lookup and list APIs let applications inspect and manage these relationships across restarts.

Shared Integration

Build on both directions to complete the recurrence lifecycle. This work follows once the inbound and outbound PRs are stable.

The scope includes restart reconciliation, payment-window tracking, missed and completed transitions, and optional automatic outbound payments. It also exposes recurrence functionality through UniFFI and adds end-to-end coverage across both directions.

Activity

  1. shaavan commented on Oct 26, 2026

    @shaavan
    MemberAuthor

    @tnull

    Following up on the offline discussion:

    The inbound (#1205) and outbound (#1207) recurrence PRs are independent and can be reviewed and merged in either order. The third PR, covering shared logic for restart reconciliation, payment-window tracking, and recurrence scheduling, will build on both.

    Would love your thoughts on whether I should start the shared PR now to get a complete draft of the recurrence implementation ready, or wait until the design of the first two has settled to reduce potential rework.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions