fix(wallet-toolbox): close nosend orphan-output failure mode

Summary

Closes a fund-loss-class failure mode where a nosend transaction that has been externally broadcast and confirmed on chain gets transitioned to proven_tx_reqs.status='invalid' + transactions.status='failed' by wallet-toolbox's own state machine, orphaning every output the tx produced (including auto-fund change outputs the wallet itself emitted).

Four independent issues combine to make this failure mode reachable. Each fix below is necessary but not sufficient alone; all four together close the demonstrated failure path (and any failure ordering involving accurate chain-status answers — see "Residual edge cases" near the end of this PR for the one case the four-fix bundle does not cover).

In one production wallet this failure mode fired 8 times in 6 days, orphaning 1,146,053 sats of BSV change across 8 transactions — recoverable only via direct SQLite UPDATE on the wallet's storage. The largest single incident orphaned 498,510 sats from 8 derivation addresses; the user thought their funds were lost until chain-verification confirmed the keys + outpoints were intact and the bug was in wallet bookkeeping, not anywhere else. Full recurrence audit below.

Architectural context

We're aware that wallet-toolbox is in mid-transition to the Teranode / Arcade / Merkle-service ecosystem, that go-wallet-toolbox is in flight as the canonical reference, and that maintainer attention is reasonably split between tactical fixes to the TypeScript stack and the larger architectural redesign. This PR is positioned as a tactical fix on the current TypeScript wallet-toolbox:

• The bug class is architecture-independent. State-machine inversion (wallet bookkeeping disagreeing with chain reality) is a property of the wallet's lifecycle state design, not the underlying broadcast/proof-fetch service abstractions. Even as services.getStatusForTxids is reshaped to source from Merkle-service in the new architecture, the fix shape — "don't invalidate a tx the chain already knows about" — will port. The new tests will port too.
• The Go equivalent has the same validateTxStatusForAbort allow-list gap. go-wallet-toolbox/pkg/storage/internal/actions/abort.go permits aborting NoSend without chain-check, same as TS. Out of scope for this PR; flagging it here in case maintainers want to track the parallel fix.
• We're flexible on shape. If maintainers prefer to (a) merge this tactically and let it be re-shaped during the migration, (b) wait for the architecture pivot and design the migration-aware fix together, or (c) split this PR into atomic single-fix PRs for easier review, any of the three works. The default proposal below is (a).

The four fixes

1. mergedInternalize lifecycle advance (storage/methods/internalizeAction.ts:327-341) — when internalizeAction is called against a tx already in nosend status, retire the nosend req (transition proven_tx_req.status out of nosend + add a history note) instead of silently no-op'ing on the lifecycle.
2. TaskCheckNoSends.checkNow wire-up (monitor/Monitor.ts:434) — nudge TaskCheckNoSends on every new block header, parallel to the existing TaskCheckForProofs.checkNow nudge. The hook was designed but never wired up.
3. abortAction chain-status check (storage/StorageProvider.ts:280-287) — refuse to invalidate a nosend req whose txid is mined or known (mempool-aware) per services.getStatusForTxids.
4. specOpNoSendActions.postProcess pre-filter (storage/methods/ListActionsSpecOp.ts:50-70) — chain-check rows before bulk-abort so Fix 3's throw never fires from the bulk-recovery path, and so returned rows reflect actual outcomes per-row (not blanket-failed).

Each fix is line-anchored, mechanically simple, and independently testable. Combined, they form a layered defense:

• Layer 1 (Fix 1): post-broadcast internalizeAction retires the nosend lifecycle immediately. Subsequent abortAction calls see the tx in unproven / completed status, which is in unAbortableStatus (StorageProvider.ts:273), and refuse.
• Layer 2 (Fix 2): if Layer 1 was missed (caller never called internalizeAction, or it threw before reaching the merge path), TaskCheckNoSends now fires per-block and retires the nosend req within minutes of confirmation. Same unAbortableStatus protection then applies.
• Layer 3 (Fix 3): if Layers 1+2 are bypassed (e.g., user-facing UI calls abortAction directly inside the same block as the broadcast, or against a tx that's still mempool-only), the new chain-status check inside abortAction itself refuses to invalidate any tx whose status is mined or known.
• Layer 3 bulk-recovery integration (Fix 4): specOpNoSendActions pre-filters chain-known rows so Layer 3's throw never fires mid-page from bulk recovery, and so returned row statuses reflect per-row outcomes accurately.

Any of Fixes 1, 2, or 3 alone closes the most common failure path. All four together close the failure path the recurrence audit demonstrates — including edge cases (broadcast in same block as abort click, intermittent wallet uptime causing missed Monitor cycles, callers that omit internalizeAction entirely, and bulk-abort recovery affordances that should still work for genuinely off-chain rows). One residual edge case is documented near the end of this PR.

Background — the failure mode walkthrough

The incident sequence reproducible from the evidence DB:

1. Caller invokes wallet.createAction({noSend: true, ...}). Storage writes a new transactions row with status='nosend' and a new proven_tx_reqs row with status='nosend'. History: {what: 'status', status_was: 'unknown', status_now: 'nosend', when: T0}.

2. Caller signs the tx (via signAction) and broadcasts externally — e.g., via a multi-source broadcast ladder, ARC, or any non-wallet broadcaster. The tx confirms on chain at block H within minutes.

3. Caller invokes wallet.internalizeAction({tx: signedTx.toAtomicBEEF(), outputs: [...], description: '...'}) to inform the wallet. The storage-layer internalizeAction.ts:206 allows the merge path for tx already in nosend status. But mergedInternalize (lines 327-341) only touches labels + outputs — it never updates transactions.status, never updates proven_tx_reqs.status, never adds a history note. Issue chore(deps): bump pnpm/action-setup from 3 to 6 #1: silent no-op on lifecycle.

4. Hours later (or minutes — any time after step 3), the user clicks an "abort pending action" affordance in any wallet UI, OR an app calls wallet.abortAction({reference: txid}) or listActions({labels:[specOpNoSendActions, 'abort']}) for bulk recovery. The storage-layer abortAction at line 273 allows nosend (it's only forbidden for completed | failed | sending | unproven). The function then unconditionally transitions:

   • transactions.status → 'failed' (line 280)
   • proven_tx_reqs.status → 'invalid' (line 285) — terminal state per ProvenTxReqTerminalStatus in sdk/types.ts

   Issue chore(deps): bump actions/setup-node from 4 to 6 #2: no chain-status check before invalidating. When called via the bulk-recovery specOpNoSendActions.postProcess (ListActionsSpecOp.ts:50-70), the spec-op iterates rows and unconditionally force-sets tx.status = 'failed' in the returned page regardless of what the per-row abort actually did. Issue Implementation tooling visibility #4: bulk-recovery spec-op forces blanket failure status on returned rows.

5. All outputs of the tx are now excluded from listOutputsKnex.ts:128's txStatusAllowed = ['completed', 'unproven', 'nosend', 'sending'] filter. specOpWalletBalance reports them as if they don't exist. The allocator can't pick them. User sees "balance gone."

6. Theoretically TaskCheckNoSends would have transitioned the nosend req to completed before step 4 — the task explicitly handles status: ['nosend'] reqs and getProofs accepts nosend (TaskCheckForProofs.ts:118). But the task's checkNow static flag is never set by any external code path; the only mechanism is triggerMsecs = oneDay * 1, which combined with intermittent wallet uptime + the early-return on undefined lastNewHeader means the task effectively never runs. Issue chore(deps): bump actions/checkout from 4 to 6 #3: orphaned hook.

The user's bookkeeping has now diverged from chain reality, and there is no path back to a healthy state through any public wallet-toolbox API — only direct SQLite UPDATE on transactions and proven_tx_reqs. That's where users lose funds in their mental model, even though the keys + outpoints remain intact on chain.

Fix 1 — mergedInternalize retires the nosend lifecycle

File: packages/wallet/wallet-toolbox/src/storage/methods/internalizeAction.ts
Lines: 327-341 (current mergedInternalize method body)

Current behavior: when internalizeAction is invoked on a tx already in storage with status='nosend', the merge path adds labels + records output ownership but never updates transactions.status or proven_tx_reqs.status. The caller has no way to know the lifecycle wasn't advanced.

Proposed change (sketch — exact diff TBD per maintainer feedback):

async mergedInternalize () {
  const transactionId = this.etx!.transactionId

  await this.addLabels(transactionId)

  for (const payment of this.walletPayments) {
    if ((payment.eo != null) && !payment.ignore) await this.mergeWalletPaymentForOutput(transactionId, payment)
    else if (!payment.ignore) await this.storeNewWalletPaymentForOutput(transactionId, payment)
  }

  for (const basket of this.basketInsertions) {
    if (basket.eo != null) await this.mergeBasketInsertionForOutput(transactionId, basket)
    else await this.storeNewBasketInsertionForOutput(transactionId, basket)
  }

  // NEW: if we just merged into a nosend tx, the caller is asserting
  // this tx is now externally broadcast and the wallet should retire
  // the nosend lifecycle. Transition the proven_tx_req out of nosend
  // so Monitor's standard proof-fetching flow can take over, OR if a
  // BUMP is included in the BEEF, transition all the way to completed.
  if (this.etx!.status === 'nosend') {
    const txid = this.txid
    const bump = this.ab.findBump(txid)
    if (bump != null) {
      // BEEF includes mining proof — transition directly to completed.
      // Reuse the same `findOrInsertProvenTx` path that `newInternalize` uses.
      // [exact integration to be worked out per maintainer feedback]
    } else {
      // Mark req for re-validation; Monitor will fetch the proof.
      const req = await EntityProvenTxReq.fromStorageTxid(this.storage, txid, /* trx */)
      if (req != null && req.status === 'nosend') {
        req.addHistoryNote({ what: 'internalizeAction', userId: this.userId })
        req.status = 'unmined'
        await req.updateStorageDynamicProperties(this.storage, /* trx */)
      }
      await this.storage.updateTransaction(transactionId, { status: 'unproven' })
    }
  }
}

Open question for maintainers: there's a doc-string inconsistency at signer-layer internalizeAction.ts:19 which says "must be unproven or completed" — contradicting the storage code's permissive line 206 which allows nosend. Should the signer's doc-string be updated to reflect that nosend is also a valid merge target (since this PR is explicitly making nosend retirement reliable)? Or is the doc-string the canonical intent and merge should be restricted to non-nosend statuses, requiring callers to use a different API for nosend retirement? Either shape is implementable; the user-friendlier one is to allow merge and advance lifecycle (what this PR does).

Fix 2 — TaskCheckNoSends.checkNow wire-up

File: packages/wallet/wallet-toolbox/src/monitor/Monitor.ts
Line: 434 (inside processNewBlockHeader)

Current behavior: processNewBlockHeader sets TaskCheckForProofs.checkNow = true but not TaskCheckNoSends.checkNow. The TaskCheckNoSends.ts source comment at line 22-25 documents the intended design ("An external service such as the chaintracks new block header listener can set this true") but no code anywhere in the repo actually does it.

Proposed change:

processNewBlockHeader (header: BlockHeader): void {
  const h = header
  this.lastNewHeader = h
  this.lastNewHeaderWhen = new Date()
  // Nudge the proof checker to try again.
  TaskCheckForProofs.checkNow = true
  // Nudge the nosend checker — externally-broadcast nosend txs may have
  // confirmed in this new block. The TaskCheckNoSends.checkNow hook was
  // designed for this signal but was never wired up; flipping it here
  // gives nosend reqs the same per-block proof-fetch opportunity as the
  // other lifecycle statuses TaskCheckForProofs handles.
  TaskCheckNoSends.checkNow = true
}

That's the entire fix. TaskCheckNoSends.runTask already handles the work correctly — queries proven_tx_reqs with status: ['nosend'], calls getProofs, transitions to completed on proof success. The daily triggerMsecs cadence stays as a fallback.

Empirical confirmation from the evidence DB: in 8 days of monitor_events (5,681 records), zero CheckNoSends events fired. Other tasks fired normally: Clock (2649), ReviewProvenTxs (2215), NewHeader (534), MonitorCallHistory (236), FailAbandoned (13), SendWaiting (12), CheckForProofs (6), ReviewDoubleSpends (4), ReviewStatus (3). The 6 CheckForProofs events demonstrate the per-block nudge mechanism works correctly when wired; the 0 CheckNoSends events demonstrate it's not wired for the parallel task. A grep across the source tree for TaskCheckNoSends.checkNow returns exactly three sites — all inside TaskCheckNoSends.ts itself (the static-field declaration plus the read/clear inside trigger and runTask). No external setter exists.

Fix 3 — abortAction chain-status check

File: packages/wallet/wallet-toolbox/src/storage/StorageProvider.ts
Lines: 273-287 (inside abortAction)

Current behavior: when caller invokes abortAction({reference}) on a tx with status='nosend' AND tx.txid set, the function unconditionally:

• transitions transactions.status → 'failed' (line 280)
• transitions proven_tx_reqs.status → 'invalid' (line 285)

No check that the txid might be known to the network already (in which case the abort is destructive: it inverts the wallet's bookkeeping relative to chain reality and orphans every output the tx produced).

Proposed change (sketch):

const unAbortableStatus: TransactionStatus[] = ['completed', 'failed', 'sending', 'unproven']
if ((tx == null) || !tx.isOutgoing || unAbortableStatus.findIndex(s => s === tx.status) > -1) {
  throw new WERR_INVALID_PARAMETER(
    'reference',
    'an inprocess, outgoing action that has not been signed and shared to the network.'
  )
}

// NEW: if the tx has been signed and assigned a txid, verify the
// network doesn't already know about it before invalidating. Aborting
// a tx that's already on chain (or in mempool about to mine) orphans
// its outputs in the wallet's view, including auto-fund change.
//
// `getStatusForTxids` (WalletServices.interfaces.ts:341-353) returns
// `StatusForTxidResult[]` with status ∈ {'mined' | 'known' | 'unknown'}:
//   - 'mined'   : depth > 0 (confirmed in a block)
//   - 'known'   : depth === 0 (in mempool, processor-aware)
//   - 'unknown' : depth === undefined (never processed or purged)
//
// Protect BOTH 'mined' AND 'known'. A tx that's been broadcast and
// is propagating in mempool returns 'known' — it's about to mine,
// and invalidating it would cause the same orphan-output failure as
// invalidating a mined tx.
if (tx.txid && tx.status === 'nosend') {
  const services = this.getServices()
  let chainStatus: 'mined' | 'known' | 'unknown' | undefined
  try {
    const r = await services.getStatusForTxids([tx.txid])
    // GetStatusForTxidsResult has TWO failure modes:
    //   (a) the call throws → caught below
    //   (b) the call returns with top-level `status === 'error'` and
    //       (typically) empty `results[]` → graceful failure
    // We treat BOTH as service-unreachable and conservatively refuse
    // the abort. Reading `r.results.find(...)` directly without the
    // (b) check would silently fall through with chainStatus undefined,
    // which would proceed-with-abort and re-introduce the bug.
    if (r.status !== 'success') {
      chainStatus = 'known'
    } else {
      chainStatus = r.results.find(x => x.txid === tx.txid)?.status
    }
  } catch {
    // (a) Indexer unavailable. Conservative refuse, same as (b).
    chainStatus = 'known'
  }
  if (chainStatus === 'mined' || chainStatus === 'known') {
    const req = await EntityProvenTxReq.fromStorageTxid(this, tx.txid, trx)
    if (req != null) {
      req.addHistoryNote({ what: 'abortAction-skipped-onchain', reference: args.reference, chainStatus })
      await req.updateStorageDynamicProperties(this, trx)
    }
    throw new WERR_INVALID_PARAMETER(
      'reference',
      `transaction is already on chain (status='${chainStatus}'); call internalizeAction instead of abortAction.`,
    )
  }
}

await this.updateTransactionStatus('failed', tx.transactionId, userId, reference, trx)
if (tx.txid) {
  const req = await EntityProvenTxReq.fromStorageTxid(this, tx.txid, trx)
  if (req != null) {
    req.addHistoryNote({ what: 'abortAction', reference: args.reference })
    req.status = 'invalid'
    await req.updateStorageDynamicProperties(this, trx)
  }
}

Four explicit choices in this sketch, called out so they're easy to push back on:

1. Status vocabulary: 'mined' | 'known' | 'unknown', matching WalletServices.interfaces.ts:352.
2. Protection set: 'mined' OR 'known'. A tx that's been broadcast and is in mempool returns 'known' (depth === 0); guarding only 'mined' would still allow the bug to fire during the propagation window (typically several minutes between broadcast and first confirmation).
3. Service-unreachable on THROW: treat as 'known' (conservative refuse), not as 'unknown' (proceed with abort).
4. Service-unreachable on graceful-error return: GetStatusForTxidsResult has two failure modes — the call can throw, OR it can return with top-level status === 'error' and empty results[]. The explicit if (r.status !== 'success') branch closes the silent fall-through that would otherwise proceed-with-abort.

Companion fix to bulk-abort path (see Fix 4 below) — by itself, this abortAction throw inside StorageProvider would cause specOpNoSendActions.postProcess to bail mid-page on the first chain-known nosend row, leaving genuinely off-chain nosend rows in the same page un-aborted. Fix 4 pre-filters the page so the throw never fires from bulk-abort.

Open question for maintainers: throw vs. auto-recover? Draft prefers the throw shape (more conservative, surfaces divergence to caller, gives the bulk-abort spec-op pre-filter something to detect). Auto-recovery (silently transitioning to unproven and queuing for proof fetch) is more user-friendly but more invasive. Either is implementable.

Fix 4 — specOpNoSendActions.postProcess pre-filters chain-known rows

File: packages/wallet/wallet-toolbox/src/storage/methods/ListActionsSpecOp.ts
Lines: 50-70 (specOpNoSendActions.postProcess)

Current behavior: when listActions({labels: [specOpNoSendActions, 'abort'], ...}) is called, the spec-op's postProcess iterates every matched nosend row and calls storage.abortAction({reference: tx.reference!}) per row, then unconditionally force-sets tx.status = 'failed' in the returned page (lines 62-67):

for (const tx of txs) {
  if (tx.status === 'nosend') {
    await s.abortAction(auth, { reference: tx.reference! })
    tx.status = 'failed'   // <-- unconditional, even though abortAction may have changed reality differently
  }
}

Two problems given Fix 3's throw behavior:

1. If abortAction throws on a chain-known nosend row, the await propagates the throw out of the for-loop, aborting the entire bulk call. Subsequent rows in the same page (including genuinely off-chain nosend rows that SHOULD be aborted) never get processed.
2. Even if Fix 3 is auto-recovering instead of throwing, the postProcess still force-sets tx.status = 'failed' for the rows it skipped — lying to the caller about what happened.

Proposed change:

[specOpNoSendActions]: {
  name: 'noSendActions',
  labelsToIntercept: ['abort'],
  setStatusFilter: () => ['nosend'],
  postProcess: async (
    s: StorageProvider,
    auth: AuthId,
    vargs: Validation.ValidListActionsArgs,
    specOpLabels: string[],
    txs: Array<Partial<TableTransaction>>
  ): Promise<void> => {
    if (!specOpLabels.includes('abort')) return

    // Pre-filter: which rows have txids the network already knows about?
    // Don't call abortAction for those — that would orphan outputs of
    // chain-confirmed (or about-to-mine) txs. Without this pre-filter,
    // the per-row abortAction call in the loop below would either throw
    // (per the chain-check fix in StorageProvider.abortAction) and bail
    // the bulk call halfway, or silently no-op while we still force-set
    // tx.status = 'failed' below.
    const candidates = txs.filter(tx => tx.status === 'nosend' && !!tx.txid)
    const candidateTxids = candidates.map(tx => tx.txid as string)
    const protectedTxids = new Set<string>()
    if (candidateTxids.length > 0) {
      const services = s.getServices()
      let serviceFailed = false
      try {
        const r = await services.getStatusForTxids(candidateTxids)
        if (r.status !== 'success') {
          // Graceful service-level failure (e.g., upstream provider
          // returned an error but the call did not throw). Treat as
          // unreachable per the conservative-refuse policy.
          serviceFailed = true
        } else {
          for (const result of r.results) {
            if (result.status === 'mined' || result.status === 'known') {
              protectedTxids.add(result.txid)
            }
          }
        }
      } catch {
        serviceFailed = true
      }
      if (serviceFailed) {
        // Indexer unreachable. Conservative: protect everything. Better
        // to leave nosend rows alone than risk orphaning outputs of txs
        // that may be on chain. The caller can retry when indexers are
        // available.
        for (const txid of candidateTxids) protectedTxids.add(txid)
      }
    }

    for (const tx of txs) {
      if (tx.status !== 'nosend') continue
      if (tx.txid && protectedTxids.has(tx.txid)) {
        // Skip: tx is on chain or in mempool. Leave the returned row's
        // status as 'nosend' so the caller sees clearly that this row
        // was NOT aborted. Monitor's TaskCheckNoSends (per Fix 2) will
        // retire the nosend lifecycle on the next block tick.
        continue
      }
      await s.abortAction(auth, { reference: tx.reference! })
      tx.status = 'failed'
    }
  }
}

Result: callers iterating a page of nosend rows now see accurate per-row outcomes — nosend for skipped rows (Monitor will retire) and failed for genuinely off-chain rows the abort processed. Bulk recovery affordances (wallet UI, scripts) keep working for the rows that should be processed, instead of bailing on the first chain-known row.

Recurrence audit — evidence this is a systemic, not isolated, bug class

A 37-row sweep of transactions.status='failed' AND txid IS NOT NULL rows in the evidence wallet DB shows 8 of 37 are confirmed on chain via WhatsOnChain, with every single one following the identical unknown → nosend → abortAction → invalid trajectory in proven_tx_reqs.history. The 8 incidents span 2026-05-05 through 2026-05-11 — six days of repeated firings in one wallet, all closeable retroactively by this 4-fix bundle. The 29 remaining "failed" rows are genuinely off-chain (the wallet was correct in marking those failed).

The 8 confirmed-on-chain orphaned txs:

The pattern is the same across all 8: caller used createAction({noSend:true}), broadcast externally, called internalizeAction post-broadcast (which silently no-op'd on lifecycle — Issue #1), TaskCheckNoSends never fired (Issue #3), and eventually some abort path fired which invalidated the chain-confirmed tx (Issue #2 / #4).

Evidence pack

Available on request to maintainers. Contents:

• Pre-surgery SQLite (~2.9 MB) at the moment of the largest incident — full storage state with 1 inverted tx, 498,510 sats orphaned. SHA256 329e5e7a2d0e955a05515b9d6fc7ba3aa3ccb215c290e53950ac914412d8e1a5.
• Pre-surgery SQLite with the remaining 7 inversions still in place (for reproduction independent of the first), SHA256 9624002b5fe864b5e037169a792eae2ab9b78e5c866c07a5ae094f94763b1a6d.
• Read-only state dump of relevant rows from the affected wallet.
• Line-anchored bug analysis + trigger sequence + fix shape per finding.

Wallet identity in the evidence: pubkey 02d29584e1f8fadcb4ef525e922debcde346fed99c6ac3cde235f276ae2d2ec85d. All chain references in the audit table are independently verifiable on mainnet.

Tests

Existing wallet-toolbox unit tests in storage/methods/__test/ and monitor/tasks/__tests/ continue to pass unchanged. New tests required as part of this PR:

• Storage: abortAction refuses to invalidate a nosend tx that getStatusForTxids reports as 'mined' (mock the service to return {status:'success', results:[{txid, status:'mined', depth:6}]}).
• Storage: abortAction refuses to invalidate a nosend tx that getStatusForTxids reports as 'known' (results:[{txid, status:'known', depth:0}]).
• Storage: abortAction proceeds normally for a nosend tx that getStatusForTxids reports as 'unknown' (results:[{txid, status:'unknown', depth:undefined}]).
• Storage: abortAction conservatively refuses (treats as 'known') when getStatusForTxids THROWS.
• Storage: abortAction conservatively refuses (treats as 'known') when getStatusForTxids returns {status:'error', results:[]} gracefully (graceful service-level failure).
• Storage: mergedInternalize against a nosend tx transitions both transactions.status and proven_tx_reqs.status correctly, with and without a BUMP in the BEEF.
• Storage: specOpNoSendActions.postProcess skips per-row when chain says 'mined' or 'known', processes per-row when 'unknown', leaves skipped rows with status='nosend' in the returned page (not blanket-failed).
• Storage: specOpNoSendActions.postProcess conservatively protects ALL rows when getStatusForTxids throws AND when it returns {status:'error', results:[]} (both service-failure modes).
• Storage: specOpNoSendActions.postProcess doesn't bail mid-page when a chain-known row is encountered — subsequent off-chain rows are still processed.
• Monitor: processNewBlockHeader sets both TaskCheckForProofs.checkNow and TaskCheckNoSends.checkNow.

Residual edge case

One narrow case is not closed by this bundle: if services.getStatusForTxids returns status='success' AND results[i].status='unknown' for a txid that is in fact on chain (e.g., the indexer hasn't yet ingested the new block, or it's a transient cache miss for a tx that's still propagating), Fix 3 treats the chain-check as authoritative and proceeds with the abort. That destroys bookkeeping for the on-chain tx anyway.

Mitigations available without changing this PR's scope:

• Fix 2's per-block TaskCheckNoSends nudge gives a self-heal opportunity: once the indexer ingests the block, the next TaskCheckNoSends run will transition the (now failed/invalid) req via the existing unfail recovery path if a caller invokes it.
• Callers can be conservative on their side (chain-verify across multiple indexers before calling abortAction).

Maintainer-side hardening that would close this case (out of scope for this PR but worth flagging):

• Multi-source chain-status check: query 2 or more indexer providers and treat the inconclusive case (any of them returning 'mined'/'known') as protective.
• Confidence interval on 'unknown' based on tx age: if the tx was created via createAction({noSend:true}) within the last N seconds and the chain says 'unknown', treat as 'known' (it's likely still propagating).

Both belong to a larger "chain-status confidence" design conversation, out of scope for this PR.

Scope and limitations

This PR specifically does NOT:

• Modify the triggerMsecs cadence for any task. The per-block nudge added in Fix 2 makes the daily fallback effectively unused in normal operation, but the schedule is left intact as a safety net.
• Add a new public wallet API for chain-status reconciliation. That's a larger design conversation; this PR is the minimum surface to close the failure mode.
• Address TaskReviewUtxos policy (the open follow-up from PR fix(wallet-toolbox): evict confirmed-stale inputs on broadcast failure #113's review).
• Address internalizeAction allowing failed status as a merge target (would close another theoretical failure class, but no concrete evidence in this dataset). Separate followup if the maintainers want it.
• Change the getStatusForTxids API or status taxonomy. The 'mined' | 'known' | 'unknown' vocabulary is left as-is.
• Touch go-wallet-toolbox. Same validateTxStatusForAbort gap exists there; flagged for separate consideration.

Coordination with PR #113

PR #113 (fix/auto-evict-stale-utxos-on-doublespend) merged on 2026-05-11, so this PR can be opened directly without coordination wait. The two PRs are cleanly separable in concern:

• fix(wallet-toolbox): evict confirmed-stale inputs on broadcast failure #113: UTXO basket state on broadcast failure (transient retry vs. permanent eviction).
• This PR: transaction lifecycle state on nosend retirement and abort.

No file overlap between the two PRs (#113 is in storage/methods/attemptToPostReqsToNetwork.ts; this PR is in storage/StorageProvider.ts, storage/methods/internalizeAction.ts, storage/methods/ListActionsSpecOp.ts, and monitor/Monitor.ts).