Hi everyone,
I’m reaching out to the community to discuss a technical discrepancy that, as far as I can tell, shouldn't be possible according to the Lightning Network specifications (BOLT #3). I want to understand if I’m missing something fundamental or if we’re looking at a serious state-tracking failure in exchange infrastructure.
The Context: On January 3rd, 2026, I generated a Lightning deposit invoice directly from KuCoin’s platform. I paid the invoice using my node (Electrum). The transaction timed out, resulting in a unilateral force-close.
The Paradox: KuCoin has officially confirmed (via support) that they have the record of the invoice I generated. However, they claim:
- "The channel creation was not successful."
- "The transaction is not in our records."
- "The Node ID does not appear in our peer logs."
The Hard Evidence (On-Chain): Despite their internal logs being empty, the Bitcoin blockchain shows a very different story:
- Funding Transaction:
1d9a8aec6debc2623599bee987f1486abd77d879b476bb7a48da4c266bba79ef(Confirmed with 3,300+ confirmations). - Force-Close Transaction:
65a2e68e8fdce08cccd8f04abfc2cbae0b51925fe0331f31b84cebcbfda3e91d. - The Locked Output (Unspent):
bc1q0xg5y4g2zvtt4weacflhmnjsa7lnqxf6w5l4tvtl7zkcqlwk2d4skhg3x5.
The Technical Dilemma: The Witness Script for the unspent 0.022 BTC output is 799142.... I have extracted the public keys, and one of them (02aa0971...) is a deterministic derivation that—mathematically speaking—can only belong to the entity that signed the original invoice (KuCoin).
My Question to the Experts: How is it possible for an exchange's system to generate a signed BOLT #11 invoice, have that invoice result in a successfully funded on-chain multisig 2-of-2 channel, and yet have the exchange’s node claim the channel "never existed"?
- Is it possible for a node to sign a commitment transaction and then "forget" the channel state entirely while the funding Tx is still pending?
- Could this be a failure in the automated "sweeper" because the node doesn't recognize the outpoint in its
channel.db**?** - If KuCoin is correct and the channel "failed," then who holds the private key for the remote side of a 2-of-2 multisig that was initiated by their own signed invoice?
I’m less worried about the 2.2M sats and more concerned about the implications for Lightning robustness. If an exchange can lose track of a funded channel state while admitting the invoice is theirs, we have a serious custody/infrastructure gap.
I’d love to hear thoughts from node operators or BOLT contributors.
Resources:
Thanks for your insights.
The force close action was initiated by your LN channel peer not by KuCoin.
So you have to deal the funds recovery with your peer not with KuCoin.
The timeout could be due to payment path failure or not so reliable communication, it encounter a bad forwarder and HTLC expired That's why your channel peer force closed that channel.
Kucoin have nothing to do with this, they are just the recipients of the payment that never arrived.
You mention that you used Electrum with a LN channel. I supposed that you were connected to a Electrum server through Tor. THAT could be your problem - Tor is really unreliable for LN payments. Is only adding huge response time and that could trigger force closures, due that your node is not responding well in the graph, so the peers will consider you as a dead node and automatically initiate the force close.
I will suggest to run locally an electrum server and connect to it by LAN IP or use a trusted electrum server on clearnet.