Standard closing
Most Lightning operators close a channel the same way. You run closechannel, wait for the transaction to confirm, and your share lands in a fresh address of your own node wallet. If the money was meant for somewhere else, you then send it again. That second transaction costs an on chain fee, and it adds one more step where a mistake can happen.
There is a shorter path. In a cooperative close, you decide which address receives your share, and it does not have to belong to the node you are closing from.
What LND does by default
In a cooperative close, each side declares the address where it wants its own balance paid out. Both declarations end up in the same closing transaction, with one output per party.
If you say nothing, LND derives a new address from its internal wallet and uses that. This is sensible, because the funds end up in a wallet the node controls and can spend right away. It is also the reason so many people close to their own node and then forward the coins by hand.
The flag that changes the destination
closechannel accepts a --delivery_addr option. Whatever address you pass becomes your payout address in the closing transaction.
Before you start
Three things need to be true.
First, the peer must be online. A cooperative close is a negotiation, so both nodes have to be reachable. If the peer is offline, you are looking at a force close, and that changes everything (more on that below).
Second, you should not have an upfront shutdown script set on that channel. This is an address committed at channel opening, and if one exists, LND will not let you pay out to a different one. In listchannels, check that the close_address field of the channel is empty. I have not tested the behavior with a script set on this specific node, so treat this as the general LND rule and check your own channel.
Third, get the destination address from the receiving wallet itself. In my case it was an address generated by the other node I operate. Do not paste an address from a third party service unless you fully understand what that service will do with an incoming deposit.
You also need to choose a fee rate.
Finding the channel point
The close command needs the channel point, which is the funding transaction id and the output index joined by a colon. You get it from listchannels. On my setup LND runs inside a Docker container named lit, and lncli is not in the PATH, so the call looks like this:
docker exec lit /app/lncli --network mainnet listchannels
For the channel in this example the funding transaction was 83908315d2a8b2c269dXXX and the output index was 1.
Starting the close
docker exec lit /app/lncli --network mainnet closechannel \
--funding_txid 83908315d2a8b2c269dXXX \
--output_index 1 \
--delivery_addr bc1qu7vvntnkep5mr8qYYY \
--sat_per_vbyte 3
No --force. The command returns the closing txid right away.
One rule matters more than the others: the flag has to be given when you start the close. There is no editing the destination afterwards. Read the address twice, then a third time. A wrong address here is not something you can recover from, because the coins are simply sent where the transaction says.
Checking the closing transaction
Open the closing txid in a block explorer such as mempool.space and look at the outputs. In this example there should be two:
10,012,180 sats to the address I supplied, which is my share
11,987,421 sats to the counterparty
The remaining 399 sats are the miner fee, and Counterparty paid it (opening side). They opened the channel, so as the channel initiator they bear the closing fee under the protocol’s rules. That is a good reason to look at who opened a channel before you decide when to close it. It affects who pays.
The numbers add up to the full sat capacity, which is a quick sanity check worth doing every time.
Confirmation and the receiving side
The transaction confirmed in block 971060. On the receiving node, the new output showed up in listunspent as UTXO 6b7ba0b3…:1, and it was spendable after two confirmations.
There is no hop through the first node’s wallet. No second transaction, no second fee, and no moment where the coins sit at an address I have to copy somewhere else by hand.
What this does not cover
Force closes
This works only in a cooperative close. If you force close, the output paying you is determined by the commitment transaction, and you do not get to choose the address. The flag does nothing for you there.
A close already in the mempool
Once the closing transaction has been broadcast, the destination is fixed. I ran into this one day earlier with another channel. I had already started the close the normal way, so the only option was to wait for confirmation and then use sendcoins to move the funds. It works, it just costs an extra fee.
There is also the question of whether the peer accepts your address. In this example’s case, the counterparty had no issue with it. In a cooperative close, each side only dictates its own output, so most peers should be fine.
Conclusion
If you already know where your funds are going after a channel closes, tell LND at the moment you close. You save a transaction, you save its fee, and you remove one manual step. The condition is simple: cooperative close, peer online, no upfront shutdown script, and an address you have checked more than once.
If you run your own Lightning node and have your own routine for closes, I would like to hear it. If you want a node that is ready to experiment with, my company Denali PRO runs Lightning nodes on Denali.pro VPS infrastructure at nimblenode.dev .