Currently when enough fee credit has been built up, the receive transaction(s) that trigger the channel opening are very confusing in the CSV.
The following example starts with a regular receive that goes to fee credit. It then receives another payment, and the channel is opened.
The next payment is due to btcpayserver/BTCPayServer.Lightning#176.
date,id,type,amount_msat,fee_credit_msat,mining_fee_sat,service_fee_msat,payment_hash,tx_id
2026-01-01T00:00:00.0000,some-uuid,lightning_received,0,13739000,0,0,payment_hash_a,
2026-01-01T00:00:00.0000,some-uuid,lightning_received,3825000,-13739000,1027,21122000,payment_hash_b,some_on_chain_hash
2026-01-01T00:00:00.0000,some-uuid,lightning_received,8410000,0,0,0, payment_hash_c,
It would easier to understand and to parse if there were two entries:
- a regular lightning_received transaction increasing fee credit (up to what's needed)
- a liquidity_purchase transaction using the fee credit
date,id,type,amount_msat,fee_credit_msat,mining_fee_sat,service_fee_msat,payment_hash,tx_id
2026-01-01,some-uuid,lightning_received,0,13739000,0,0,payment_hash_a,
2026-01-01,some-uuid,lightning_received,3825000,8410000,0,0,payment_hash_b,
2026-01-01,some-uuid,liquidity_purchase,0,-22149000,1027,21122000,,some_on_chain_hash
# hopefully no duplicate transaction
https://phoenix.acinq.co/server/auto-liquidity
Currently when enough fee credit has been built up, the receive transaction(s) that trigger the channel opening are very confusing in the CSV.
The following example starts with a regular receive that goes to fee credit. It then receives another payment, and the channel is opened.
The next payment is due to btcpayserver/BTCPayServer.Lightning#176.
It would easier to understand and to parse if there were two entries:
https://phoenix.acinq.co/server/auto-liquidity