fix(sdk-core): enforce recipient verification in ECDSA TSS signing

[mrdanish26]

Summary

Closes the ECDSA TSS default-path signing vulnerability (WCN-151 Phase 3)
where a compromised BitGo API server could swap signableHex undetected.

The Vulnerability

Both EcdsaUtils and EcdsaMPCv2Utils defaulted txParams when absent:

// Before — vulnerable
txParams: params.txParams || { recipients: [] }

With no txParams (Classic UI pending approval, Express), verifyTransaction()
gets an empty recipients list and skips all address/amount checks.

Root cause of prior failures: stale hardcoded arrays in coin-level overrides
were missing staking types, causing false throws on legitimate staking transactions.

Loki is authoritative. Kibana misses wallet-platform-admin-nocluster entries.

┌────────┬────────────────┬──────┬──────────────────┐
│  Coin  │    tx_type     │ Loki │      Status      │
├────────┼────────────────┼──────┼──────────────────┤
│ canton │ enableToken    │  206 │ already exempt   │
├────────┼────────────────┼──────┼──────────────────┤
│ sol    │ customTx       │  106 │ already exempt   │
├────────┼────────────────┼──────┼──────────────────┤
│ canton │ createAccount  │   89 │ added in this PR │
├────────┼────────────────┼──────┼──────────────────┤
│ sol    │ enableToken    │   22 │ already exempt   │
├────────┼────────────────┼──────┼──────────────────┤
│ canton │ transferAccept │    8 │ added in this PR │
├────────┼────────────────┼──────┼──────────────────┤
│ bsc    │ tokenApproval  │    6 │ already exempt   │
├────────┼────────────────┼──────┼──────────────────┤
│ hash   │ contractCall   │    3 │ added in this PR │
├────────┼────────────────┼──────┼──────────────────┤
│ ada    │ pledge         │    2 │ added in this PR │
├────────┼────────────────┼──────┼──────────────────┤
│ apt    │ customTx       │    2 │ already exempt   │
└────────┴────────────────┴──────┴──────────────────┘

Changes

Commit 1 — Enforce recipient verification

- recipientUtils.ts (new) — 27-type NO_RECIPIENT_TX_TYPES set and
resolveEffectiveTxParams(). Falls back to intent.recipients, resolves
txType from intent.intentType, propagates stakingRequestId, throws
InvalidTransactionError only when no recipients and no exemption applies.

- ecdsa.ts, ecdsaMPCv2.ts — replace vulnerable default:
txParams: resolveEffectiveTxParams(txRequest, params.txParams)

- bsc.ts, bscToken.ts, xdc.ts, xdcToken.ts, evmCoin.ts,
abstractEthLikeNewCoins.ts — replace stale hardcoded arrays with
NO_RECIPIENT_TX_TYPES.has(txParams.type) + stakingRequestId bypass.

- iBaseCoin.ts, baseTypes.ts, iWallet.ts — add
stakingRequestId?: string to TransactionParams, PopulatedIntent,
PrebuildTransactionResult.

Test Plan

- yarn test --filter=@bitgo/sdk-core passes
- Normal ETH/BTC send — address + amount still verified
- Post-deploy Loki: zero new "TSS signing with no intent recipients" hits
- TypeScript compiles clean across all affected packages

[linear-code]

WCN-151

[zahin-mohammad]

Review summary

This routes both ECDSA TSS signing paths through a single resolveEffectiveTxParams() that resolves recipients (txParams → intent.recipients), exempts known recipient-less types via NO_RECIPIENT_TX_TYPES, and throws otherwise — replacing the txParams: params.txParams || { recipients: [] } default that disabled recipient verification when txParams was absent. Core logic looks sound and the test coverage is good. A few things worth resolving before merge, especially given the revert history below.

Context: this is the third attempt

The same fix has merged and been reverted twice (#8462 → reverted by #8538; #8539 → reverted by #8665). Both reverts were caused by being too strict and throwing on legitimate recipient-less transactions:

• fix(tss): require txParams with recipients for TSS tx signing #8462 required recipients unconditionally → broke token/staking/contract flows.
• fix(tss): verify recipients before signing #8539 added intent fallback + an EVM-only exemption set, but resolved the type only from txParams (not intent.intentType), so flows that sign without txParams still threw.

This PR's intent.intentType resolution + expanded exemption set is the right fix for what broke #8539. The recurring failure mode (exemption set under-counts legitimate cases) is worth keeping in mind — the bar for completeness should be high here.

Blocking concerns

1. The skipTssRecipientVerification opt-out may undercut the fix on the main path.
Per the description, a companion client-side PR sets this flag to true, which disables recipient verification for that path. But resolveEffectiveTxParams already falls back to intent.recipients for intent-only flows — so what case requires the blanket opt-out? As written, the most common signing path would skip the exact check this PR adds. Could you clarify why the intent fallback is insufficient there, or scope the opt-out more narrowly than a per-call boolean? The flag also reads as insurance against the exemption set being incomplete, which is worth being explicit about.

2. Pending-approval recipient threading was dropped vs. the prior attempts.
#8462 and #8539 both threaded the pending-approval recipients explicitly through recreateTxRequest. This PR removes that and relies entirely on txRequest.intent.recipients being populated after recreation. Can you confirm recreated pending-approval txRequests carry intent.recipients? If not, this could reintroduce a false-throw on that path.

3. enableToken casing.
NO_RECIPIENT_TX_TYPES uses camelCase 'enableToken' (matching intentType), but the EVM coin layer sets txParams.type to lowercase 'enabletoken' in some paths. The intent-sourced path is covered, but a caller passing the lowercase string with no recipients would now throw. Adding 'enabletoken' to the set as well is a cheap safeguard.

Lower-priority notes

• skipTssRecipientVerification is exposed on the Express route schema. Consistent with the threat model (the flag is set client-side), but it does broaden the bypass surface to every request — worth a confirming comment.
• The exemption set mixes intent types across coin families. Worth confirming each newly added non-EVM type is genuinely recipient-less and routes through this path, rather than being a value transfer.

Strengths

• The intent.intentType resolution directly addresses the regression that reverted the previous attempt, and the isPopulatedIntent() type guard replaces the prior unsafe cast.
• Test coverage asserts value-transfer types (payment, fanout, vote) are not exempt, and the new coin-level suite covers the flag, hop, and missing-param ordering.
• Centralizing the previously divergent per-coin arrays into one set removes the drift that contributed to the earlier reverts.
• Reordering the wallet/hop checks ahead of the recipient guard is a genuine correctness improvement and is tested.

Recommendation

Worth resolving (1) and (2) before merge — given two prior production reverts, the key questions are whether the opt-out leaves the main path protected, and whether the pending-approval path still resolves recipients. (3) is a one-line safeguard. The core logic is solid; the remaining risk is in completeness and in whether the opt-out hollows out the protection.

[mrdanish26]

Blocking concerns

1. The skipTssRecipientVerification opt-out may undercut the fix on the main path. Per the description, a companion client-side PR sets this flag to true, which disables recipient verification for that path. But resolveEffectiveTxParams already falls back to intent.recipients for intent-only flows — so what case requires the blanket opt-out? As written, the most common signing path would skip the exact check this PR adds. Could you clarify why the intent fallback is insufficient there, or scope the opt-out more narrowly than a per-call boolean? The flag also reads as insurance against the exemption set being incomplete, which is worth being explicit about.

The two layers do different things:

• Layer 1 (resolveEffectiveTxParams): recipients exist — not bypassable by the flag
• Layer 2 (verifyTssTransaction): recipients match the txPrebuild — currently bypassed by the flag

The flag was backup against the exemption set being incomplete (Layer 1 throws on unknown no-recipient types).

2. Pending-approval recipient threading was dropped vs. the prior attempts. #8462 and #8539 both threaded the pending-approval recipients explicitly through recreateTxRequest. This PR removes that and relies entirely on txRequest.intent.recipients being populated after recreation. Can you confirm recreated pending-approval txRequests carry intent.recipients? If not, this could reintroduce a false-throw on that path.

The intent (including recipients) is persisted server-side at txRequest creation time and is not affected by signature deletion. I verified in production logs that all payment intents carry intent.recipients.

[zahin-mohammad]

per the huddle, needs a few more changes (removing the opt out bool)

[zahin-mohammad]

lgtm... but please keep a close eye on this for the beta release and the ui release