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

[BSVanon]

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:

tx (short)	flow	abort time	recoverable BSV
fd8853b7…dcdca5eb	Inscribe icon (1Sat-Ord)	2026-05-05T02:02Z	631,971 change
525c938f…daa45d8c	Deploy + mint BSV-21 token	2026-05-05T02:02Z	448 change
7fd1a788…b7fe4a8a	BRC-29 self-pay output	2026-05-08T22:23Z	540 change + 1M output
fd41177b…4a38742	BRC-29 self-pay output	2026-05-08T22:42Z	391 change + 1M output
d8b28734…6576b77	MNEE buy vault	2026-05-09T19:39Z	1,625 change + 1,500 vault
b77fb25e…f9dbf81ec	MNEE refund	2026-05-09T23:04Z	4,058 change
068fabc5…20ce0b346	AMM pool state	2026-05-10T01:58Z	8,510 change
096a9252…49a22bfed	AMM pool swap	2026-05-11T15:49Z	1,490 change + 498,510 wallet change

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).

[tonesnotes]

Comments on the four fixes:

1. internalizeAction: Fix 1 looks good. Internalizing a transaction with matching proven_tx_req in noSend state is an ambiguous situation. This is an attempt to take ownwership of an output where control of the underlying transaction was externalized. For simplicity, it makes sense to resolve the ambiguity in favor of treating the internalizeAction call as explicity authorization to broadcast. A clear reason for this choice is to keep the behavior of the internalizeAction call consistent both when the transaction originator is using the same storage and when they are not. On the open doc-string question: Expand the "must be unproven or completed" to correctly describe what gets implemented.
2. TaskCheckNoSends.checkNow has an unresolved cost issue as the set of noSend transactions can grow large and there is a cost to constantly checking transactions that may be sitting in escrow or may be un-aborted tests. What must be added is an aging system where the re-try interval grows with the age of the transaction. Ultimately, optimizing checking for delayed externally broadcast transactions must come with performance limitations differentiating it from "normal" wallet-in-charge broadcasting. It is not enough to just enable checking all noSend proven_tx_reqs each time a new block appears.
3. abortAction: Yes, this should never abort a valid transaction that has been shared with the network, but it should remain possible to abort transactions even when offline and network confirmation is impossible. This hole can never be 100% closed, but it should refuse to abort when confirmation is possible. Don't throw when abort fails due to valid tx confirmation. Use the method return value to indicate successful abort vs refused abort.
4. specOpNoSendActions: Same as 3, never abort a valid transaction that has been shared with the network.

[tonesnotes]

On TaskCheckNoSend optimization:

A primary use case for noSend is batched transactions. The central purpose it to avoid duplicative network traffic when creating chains of large transactions. By NOT sending incrementally larger BEEFs until one complete BEEF with multiple new transactions can be sent following the sendWith createAction call.

How so ever TaskCheckNoSend is optimized, this use case must remain efficient.

[BSVanon]

Comments on the four fixes:

1. internalizeAction: Fix 1 looks good. Internalizing a transaction with matching proven_tx_req in noSend state is an ambiguous situation. This is an attempt to take ownwership of an output where control of the underlying transaction was externalized. For simplicity, it makes sense to resolve the ambiguity in favor of treating the internalizeAction call as explicity authorization to broadcast. A clear reason for this choice is to keep the behavior of the internalizeAction call consistent both when the transaction originator is using the same storage and when they are not. On the open doc-string question: Expand the "must be unproven or completed" to correctly describe what gets implemented.
2. TaskCheckNoSends.checkNow has an unresolved cost issue as the set of noSend transactions can grow large and there is a cost to constantly checking transactions that may be sitting in escrow or may be un-aborted tests. What must be added is an aging system where the re-try interval grows with the age of the transaction. Ultimately, optimizing checking for delayed externally broadcast transactions must come with performance limitations differentiating it from "normal" wallet-in-charge broadcasting. It is not enough to just enable checking all noSend proven_tx_reqs each time a new block appears.
3. abortAction: Yes, this should never abort a valid transaction that has been shared with the network, but it should remain possible to abort transactions even when offline and network confirmation is impossible. This hole can never be 100% closed, but it should refuse to abort when confirmation is possible. Don't throw when abort fails due to valid tx confirmation. Use the method return value to indicate successful abort vs refused abort.
4. specOpNoSendActions: Same as 3, never abort a valid transaction that has been shared with the network.

Thank you Tone — really good feedback. Worked through all four.

1. internalizeAction (Fix 1, docstring) — expanded both signer and storage docstrings to the per-status table you described, including the rationale that the call is explicit authorization to advance the lifecycle so behavior is consistent whether the originator shares the same storage as the internalizer or not. Commit: 7e676b9 → bc5f067.

2. TaskCheckNoSends.checkNow aging system — built a 5-tier age-based schedule on the checkNow path (skip <5 min / every-block 5 min – 1 hr / ~hourly 1 hr – 24 hr / ~daily 24 hr – 7 d / ~weekly 7 d+), with per-row staggering keyed by provenTxReqId so same-tier rows are spread across the modulo cycle instead of firing on the same block. The scheduled daily cadence (no checkNow) remains unfiltered as a safety net so externally-broadcast nosend txs are still eventually recognized regardless of age. Commits: 90db153 (initial freshness gate) → bc5f067 (full 5-tier schedule) → d3804cc (per-row staggering after an internal review caught synchronized same-tier bursts in v2).

3. abortAction return-value pivot — switched chain-confirmed refusal from throw WERR_INVALID_PARAMETER to return { aborted: false }, and lifted the conservative-refuse-on-service-unreachable. Both getStatusForTxids failure paths (catch + r.status !== 'success') now set an internal serviceUnreachable flag and proceed with the abort, writing a new abortAction-offline-fallback history note on the proven_tx_req for forensic audit. Refusal is reserved for positive on-chain confirmation, exactly as you described. Required widening AbortActionResult.aborted in the SDK from the literal true to boolean. Commits: 3c2ecbf (SDK widening) + 19895c2 (wallet-toolbox pivot).

4. specOpNoSendActions — same pivot in the bulk path. The pre-filter still does the batched getStatusForTxids for efficiency, but only protects rows on positive mined/known confirmation; service failures fall through to per-row abortAction calls (which each apply their own offline-fallback policy). The loop body now checks result.aborted per row, so race-window rows that became chain-known between pre-filter and the per-row call leave their status as nosend rather than being blanket-set to failed. Commit: 19895c2.

Build-graph follow-up — the SDK widening required switching @bsv/wallet-toolbox, @bsv/auth-express-middleware, and @bsv/payment-express-middleware from "@bsv/sdk": "^2.1.0" to "@bsv/sdk": "workspace:*" so the workspace SDK source is authoritative. Otherwise StorageServer.ts fails type identity at the points where this.wallet is passed to createAuthMiddleware/createPaymentMiddleware, because the published middleware packages bake in the older literal aborted: true WalletInterface. The pattern matches the wiring already used by conformance/runner/ts. If you'd rather coordinate this differently (e.g. release-coordinated SDK bump + middleware republish), happy to rework — let me know. Commit: a2f8244.

Test coverage: 28/28 pass on the targeted lane (taskCheckNoSendsFreshnessGate 12 + nosendLifecycleDefense 14 + processNewBlockHeader 2) under Node 24.15.0, including new cases for the offline-fallback audit notes and the mid-page race window.

[BSVanon]

On TaskCheckNoSend optimization:

A primary use case for noSend is batched transactions. The central purpose it to avoid duplicative network traffic when creating chains of large transactions. By NOT sending incrementally larger BEEFs until one complete BEEF with multiple new transactions can be sent following the sendWith createAction call.

How so ever TaskCheckNoSend is optimized, this use case must remain efficient.

Directly addressed by the tier0FreshSkipMsecs (<5 min) tier in commits bc5f067 + d3804cc: rows fresher than 5 minutes are entirely excluded from checkNow-triggered chain checks. Chained createAction({ noSend: true, sendWith: [...] }) builds therefore never trigger external getMerklePath lookups during the build phase. Once the terminator createAction broadcasts the assembled BEEF, the constituent rows age past the 5-min threshold and enter the regular schedule (per-row staggered so even a wallet with N batched-tx tails doesn't see synchronized bursts).

The class docstring at TaskCheckNoSends.ts calls out this batched-tx protection explicitly both in the aging-schedule paragraph and as the rationale on tier0FreshSkipMsecs. The scheduled daily cadence (no checkNow) is unchanged and still scans every nosend row regardless of age, so the safety net for externally-broadcast unmined nosend txs is preserved.

[tonesnotes]

Updates are consistent with issues raised in my earlier comments.
I approve the substance of these changes.

Can't speak to the build-graph choices as I'm not current on the release process.

I am not currently listed as a reviewer, not sure if that was intentional but will defer at this time to @sirdeggen for merge approval.

[sirdeggen]

I am not currently listed as a reviewer, not sure if that was intentional but will defer at this time to @sirdeggen for merge approval.

Not intentional, no. It's more a case of the auto stuff will pick up CODEOWNERS which I defaulted to me unless otherwise specified. May I add you as codeowner for wallet-toolbox? Still getting used to the new repo structure. Happy to discuss. Roughly speaking you can tag main branch with release/v* and it will release all updated packages in topological order. It's pretty nifty.

[sonarqubecloud]

Quality Gate passed

Issues
18 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
2.1% Duplication on New Code

See analysis details on SonarQube Cloud