The Lightning Network (LN) enables Bitcoin off-chain transactions. These do not produce a unique on-chain transaction hash (txnId) and do not provide an on-chain beneficiary wallet address per payment. Therefore, Lightning payments cannot be submitted to the Sumsub Travel Rule.

Unaccepted data

You cannot submit Lightning payment artifacts, including:

• Lightning invoices (BOLT11/BOLT12), LNURL.
• Lightning Address payloads.
• Payment hash/preimage/routing data.
• Channel identifiers (channel ID, short_channel_id).

Accepted data

You can submit BTC on-chain transfers such as regular Bitcoin transactions with txnId and on-chain addresses.

You can do this using the standard Travel Rule flows:

1. Before on-chain outgoing transfer — when you know the BTC recipient wallet address—you will broadcast the BTC transaction after the Travel Rule exchange is completed.
2. After on-chain outgoing transfer — when you received an incoming BTC transaction on-chain and can provide the BTC txnId.

Channel open/close transactions

You can see the BTC txnIds related to Lightning channel management, such as:

• Channel open (funding) transactions.
• Channel close/force close (settlement) transactions.

These transactions are related to channel management/settlement and must not be submitted as a substitute for an individual Lightning payment (they do not map 1:1 to a Lightning payment beneficiary).

Examples

Here are a few examples of how it all works:

1. You must not submit a withdrawal through a Lightning invoice (LN payment), as it is an off-chain payment that has no on-chain txnId and no on-chain beneficiary address.
2. You must submit a BTC on-chain withdrawal using the Before on-chain outgoing transfer flow.
3. You must submit a BTC on-chain deposit using the After on-chain incoming transfer flow and the BTC txnId.