[bug]: Assets Not Found On-Chain After Normal Forced Closure to 'Closedchannel' State

[shuishihang]

I have a node that opened an asset channel, which entered the pending_force_closing_channels state and eventually moved to closedchannels. However, when I used the command tapcli --network mainnet --rpcserver localhost:8443 a l, I couldn’t find the on-chain assets. Additionally, the data shown in unconfirmed_transfers looks unusual.

{
    "assets": [],
    "unconfirmed_transfers": "23",
    "unconfirmed_mints": "0"
}

This is the data returned by my lncli closedchannels command.

{
    "channels": [
        {
            "channel_point": "7b57e36406cf36d5d8d5846adc7ab1890605cc00632419f6445e3fc53a0b327e:0",
            "chan_id": "999601205214773248",
            "chain_hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
            "closing_tx_hash": "e63fe180c665ed237f270c3fd07d6ed973bf9aaace71197ffc632579c52caf28",
            "remote_pubkey": "02c953421bc7f07be6052920e46843d11e6d3ffc9986177c91f140d76c6ed3a3d4",
            "capacity": "20000",
            "close_height": 914486,
            "settled_balance": "10000",
            "time_locked_balance": "0",
            "close_type": "REMOTE_FORCE_CLOSE",
            "open_initiator": "INITIATOR_REMOTE",
            "close_initiator": "INITIATOR_REMOTE",
            "resolutions": [
                {
                    "resolution_type": "COMMIT",
                    "outcome": "CLAIMED",
                    "outpoint": {
                        "txid_bytes": "28af2cc5792563fc7f1971ceaa9abf73d96e7dd03f0c277f23ed65c680e13fe6",
                        "txid_str": "e63fe180c665ed237f270c3fd07d6ed973bf9aaace71197ffc632579c52caf28",
                        "output_index": 3
                    },
                    "amount_sat": "10000",
                    "sweep_txid": "a65a1a6879bcdfacf0620354fbbdde54ce77fdacb62aa360f4e2579c20d750f4"
                }
            ],
            "alias_scids": [
                "17592186044416000001"
            ],
            "zero_conf_confirmed_scid": "0"
        }
    ]
}

This is the output returned by the command tapcli --network mainnet --rpcserver localhost:8443 a t.

assetTx.txt

[ffranr]

I can see that the channel point 7b57e36406cf36d5d8d5846adc7ab1890605cc00632419f6445e3fc53a0b327e:0 is listed in the asset transfer command output that you shared in assetTx.txt. In that CLI output we can see that proof transfer is still pending. This doesn't seem unusual to me.

I can also see other unconfirmed transfers in the output file that you shared. They seem unrelated to the channel and its closure.

Can you share any tapd logs so that we can diagnose why proof transfer is incomplete?

[shuishihang]

This file contains the full log data of the noThis file contains the full log data of the node.https://cdn.file.microlinktoken.com/box/lnd.zipde.https://cdn.file.microlinktoken.com/box/lnd.zip

[ffranr]

Thanks for sharing the logs.

I noticed this entry in the log file, which corresponds by outpoint to the channel that was closed:

2025-10-14 12:03:08.733 [INF] FRTR: ChainPorter executing state: SendStateStorePostAnchorTxConf
2025-10-14 12:03:08.733 [INF] FRTR: Importing 0 passive asset proofs into local Proof Archive
2025-10-14 12:03:08.773 [ERR] FRTR: Error evaluating state (SendStateStorePostAnchorTxConf): unable to store proofs: failed to generate an updated proof file for output 0: error fetching input proof: error fetching input proof -- locator=(proof.Locator) {
 AssetID: (*asset.ID)(0xc000ecd214)((len=32 cap=32) 97b98f3c45f926057d430ef71f20a6d3e25d7a00fbd1d7b72b306a49d48c9d8c),
 GroupKey: (*secp256k1.PublicKey)(<nil>),
 ScriptKey: (secp256k1.PublicKey) {
  x: (secp256k1.FieldVal) 90fd801e74ade972ffbb1b38a372ab9ad3cf08264de0808178f652120aa1092e,
  y: (secp256k1.FieldVal) e385966f56b69d3d51aa0cea2fa92e3f853317bed9401719e5e68959207f1350
 },
 OutPoint: (*wire.OutPoint)(0xc000ecd1f0)(e63fe180c665ed237f270c3fd07d6ed973bf9aaace71197ffc632579c52caf28:3)
}
: unable to find proof

I'll continue to look into this. I might be able to use the following to investigate further: https://github.com/lightninglabs/taproot-assets/blob/614acdcb1c51b85dc926d44e21139d4f7d176adb/proof/proof_stitching_test.go#L20-L25

Also note that we have planed work to improve robustness here: https://github.com/lightninglabs/taproot-assets/issues/1835