Integrations 1.0

The ultimate blocker for releasing payjoin-1.0 proper is to validate that the API is sufficiently stable to satisfy the needs of multiple integration candidates, ideally including a mobile wallet and an exchange-like service provider. This checklist is an attempt at narrowing the scope of our focus so that we can achieve this and make the release by the end of the year.

BullBitcoin Mobile, Boltz, and Liana were selected as primary targets because they're the furthest along and already have buy-in from the respective teams. Getting the reference implementation polished is also important but IMO doesn't satisfy the "working demo" criterion for 1.0 (we need to demonstrate that our library satisfies real needs in other peoples' code).

Another pre-requisite to satisfy these integrations is ensuring that there are multiple reliable directories.

The dates below are estimated deadlines that I think we need to meet to be in good shape for 1.0 release by EOY, and I tagged relevant stakeholders in each section.

Directory Reliability

@nothingmuch, @spacebear21, @arminsabouri

• ACME support
  • Merge Support requesting certificates using ACME #1026 (comment)
  • Launch secondary server with ACME at lets.payjo.in
• Find someone else to run the directory, potentially a consortium
• tracking: opt-out of v1 requests on the directory #1198
• Metrics and alerting
  • Setup a liveness script to check payjo.in/health at a frequent interval
• Payjoin Mailroom Tracking Issue #941

Bull Bitcoin

• Bull Bitcoin x Payjoin Tracking Issue #1206

Boltz

• Boltz x Payjoin Tracking Issue #1205

Liana

• Liana x Payjoin Tracking Issue #1204

LDK-Node

lightningdevkit/ldk-node#746

payjoin-cli

@zealsham

• Demonstrate proper failure handling with broadcast of fallback tx
• Implement cancel command @nothingmuch 10/14/25
• Review history command
• Fix payjoin-cli receiver returns a 500 error after a successful payjoin. #1154
• Tag & release payjoin-cli 1.0-rc.0

FFI

@chavic

• Tag & release uniffi-dart 0.1.0
• Uniformly use primitive types in FFI boundary, with runtime validation Uniformly use primitive types in FFI boundary, with runtime validation #738
  • Drop bitcoin-ffi dependency
• Clean up error wrappers
  • Remove public From<String> implementations from FFI error wrappers #1117
  • After primitive types are enforced, revisit ForeignError category (I expect runtime validation and conversion of primitive types to result in a new category of errors)
• Audit exposed interface surface area (everything pub should be accessible in FFI downstream)
• Tag payjoin-ffi 1.0-rc.0
• Tag & release payjoin python 1.0-rc
• Tag & release payjoin dart 1.0-rc
• Tag & release payjoin JS 1.0-rc

1.0 release

@spacebear21

• Audit tasks in https://github.com/payjoin/rust-payjoin/milestone/1
• Write documentation
• Update README (note to self: monad logo is broken on crates.io)
• Validated in at least 2 fully working demos, preferably BBM + Boltz (working demo != released product)
• Tag & release payjoin 1.0

Sustainable Adoption (medium/long-term)

@DanGould, @spacebear21

• Publish case studies on integrations (see https://lightningdevkit.org/case-studies/ and https://bitcoindevkit.org/adoption/all/)
• Write an integration guide / FAQ informed by the above
• Create demand for organic adoption (ultimately we must not have to babysit every integration)
  • I see this happening now see Ark, Cove, Conor's impl, BTCPayServer
• Have a process for tracking integrations at all stages (potential leads, in-flight, completed...)
  • It's ugly and not automated but we do have it