# Core Lightning v26.06.8: onchaind failed to resolve outputs after remote splices

**URL:** <https://community.start9.com/t/core-lightning-v26-06-8-onchaind-failed-to-resolve-outputs-after-remote-splices/5792>\
**Category:** Services Support\
**Created:** [October 1, 2026, 3:22pm UTC](https://community.start9.com/t/core-lightning-v26-06-8-onchaind-failed-to-resolve-outputs-after-remote-splices/5792 "2026-10-01T15:22:31Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ironmonkeeeee](https://community.start9.com/letter_avatar_proxy/v4/letter/i/50afbb/32.png) [@ironmonkeeeee](https://community.start9.com/u/ironmonkeeeee)\
**Post date:** [October 1, 2026, 3:22pm UTC](https://community.start9.com/t/core-lightning-v26-06-8-onchaind-failed-to-resolve-outputs-after-remote-splices/5792/1 "2026-10-01T15:22:31Z")

</div>

**Title:** Core Lightning onchaind failed to resolve 3,043,561 sats after remote-initiated splices

Hello,

I’m running StartOS `0.4.0.1` with Core Lightning `26.06.8:3` on Bitcoin.

Three channels recently went through remote-initiated splice operations. In each case, the channel briefly returned to `CHANNELD_NORMAL`, then received a protocol error and went on-chain.

Affected channels:

```plaintext
969219x39x0
969244x29x1
969290x93x0

```

The observed sequence was:

1. The channel reached `CHANNELD_NORMAL`.
2. The remote peer initiated a splice.
3. The splice completed.
4. The channel returned briefly to `CHANNELD_NORMAL`.
5. CLN received a protocol `ERROR`.
6. The channel entered `AWAITING_UNILATERAL`.
7. The remote peer spent the funding transaction.
8. CLN’s `onchaind` failed to resolve some outputs.

The relevant CLN log message was:

```plaintext
Could not find resolution for output 2: did *we* cheat?
Could not find resolution for output 3: did *we* cheat?

```

CLN later logged:

```plaintext
onchaind complete, forgetting peer

```

The funding-spend transactions were:

```plaintext
f54914b3b3bea085ad13ba28414423c833ac42142c66db62a4a767b04129bb14
ffa608bc6c672ed7d6dfd161ca537bbc1579df7c2da575e52806cabcdac30ff8
c4e0b155116be1d96f7d5fc540a9f0a97fb2bc857a44b7ff45c4c7c58ed8c076

```

The local outputs identified by CLN are:

```plaintext
f54914...:3 1,229,771 sats confirmed at block 969222
ffa608...:3 1,229,171 sats confirmed at block 969247
c4e0b1...:2 584,619 sats confirmed at block 969296

```

Total:

```plaintext
3,043,561 sats

```

These outputs are now past the apparent CSV delay. However:

- They remain credited in `listchainmoves`.
- Each still has `debit_msat: 0`.
- They do not appear in `listfunds` as wallet outputs.
- No sweep transaction has been created.
- CLN is fully synced.
- The node is still running and has active channels.
- The funds have not been manually spent or moved.

I attempted:

```plaintext
dev-rescan-outputs

```

but CLN rejected it because developer-only commands are disabled.

I also upgraded CLN to `26.06.8:3`. The upgrade did not resolve the outputs, but the node identity and channel database remained intact. I have a StartOS service backup from September 21, although it predates these splice events.

I have not:

- Deleted the CLN database.
- Restored the backup.
- Manually spent the outputs.
- Shut down the node.
- Broadcast any recovery transaction.

Could someone advise on the supported recovery procedure?

Specifically:

1. Is this a known splice or `onchaind` resolution issue in CLN `26.06.8:3`?
2. Can the broken `onchaind` state be repaired or reindexed?
3. Is there a supported way to rescan or re-register these mature outputs?
4. Should the September 21 StartOS backup be provided or inspected?
5. What is the safest way to recover the outputs without constructing or broadcasting an unsafe manual transaction?
6. Is there any additional diagnostic information I should collect?