feat(sdk-core): add EdDSA MPCv2 full 3-round signing orchestration

[Marzooqa]

• Add signTxRequest, signTxRequestForMessage, and signRequestBase to EddsaMPCv2Utils implementing WASM round 0 + API rounds 1 and 2
• Verify PGP signatures on BitGo round1Output and round2Output
• Return latestTxRequest after round 2 (round 3 + send deferred to next PR)
• Add signTxRequest unit tests using nock with real BitGo DSG sessions

Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com

TICKET: WCI-154

[linear-code]

WCI-154 [BitgoJS] Implement signRequestBase on EddsaMPCv2Utils - round 1 & round 2

[zahin-mohammad]

Reviewed against base #8687. Built locally — tsc --noEmit clean in sdk-core, signTxRequest.ts test passes (5/5).

The orchestration faithfully mirrors ECDSA's EcdsaMPCv2Utils.signRequestBase and the protocol structure looks right: WASM rounds 0/1/2 interleaved with API rounds 1/2/3, no client-side verification on round 3 (WP finalises). Nothing here freezes public API surface — the two new public methods (signTxRequest, signTxRequestForMessage) match the existing ITSSUtils/ECDSA shape, and signRequestBase is private. So everything below is follow-up safe.

Most significant finding is the missing mpcv2PartyId plumbing — backup signing is implicitly unsupported here even though the helpers from #8687 already accept the party id. ECDSA supports it; this is a behavioral gap vs the parallel path.

See inline comments.

[zahin-mohammad]

Backup-signer support gap. params.mpcv2PartyId (declared on TSSParamsWithPrv for exactly this purpose) is silently dropped. ECDSA's signRequestBase plumbs it through to both DSG init and the share helpers (see ecdsaMPCv2.ts:784, 792, 827, 845, 876, 893); here the user is hardcoded to MPCv2PartiesEnum.USER.

The helpers from #8687 already accept partyId: 0 | 1, so plumbing is mechanical:

const partyId = params.mpcv2PartyId ?? 0;
const userParty = partyId === 0 ? MPCv2PartiesEnum.USER : MPCv2PartiesEnum.BACKUP;
const userDsg = new EddsaMPSDsg.DSG(userParty);
userDsg.initDsg(userKeyShare, bufferContent, derivationPath, MPCv2PartiesEnum.BITGO);
// pass partyId through each getEddsaSignatureShareRoundN call

Follow-up safe — but worth filing as a Linear ticket so it doesn't get lost. Without it, EdDSA MPCv2 backup-signer flow can't go through this path.

[zahin-mohammad]

Typo: handleIncomingMessagexs → handleIncomingMessages.

[zahin-mohammad]

Assert ordering — the assert runs after Buffer.from(txOrMessageToSign, 'hex'). If signableHex is undefined, Buffer.from(undefined, 'hex') throws a TypeError first and the helpful assertion message never surfaces. Same pattern at L388-389 for the message branch. Suggest moving the assert above the Buffer.from call:

txOrMessageToSign = unsignedTx.signableHex;
assert(txOrMessageToSign, 'Missing signableHex in unsignedTx');
bufferContent = Buffer.from(txOrMessageToSign, 'hex');

[zahin-mohammad]

Defensive: handleIncomingMessages returns DeserializedMessages (an array). If WASM ever returns [] or an unexpected length, userMsg2 becomes undefined and the next getEddsaSignatureShareRound2(undefined, ...) crashes with a confusing PGP error. A targeted assert(userMsg2, 'WASM round 1 produced no message') after the destructure would surface the real failure. Same applies to userMsg3 at L478.

[zahin-mohammad]

Fragile share lookup: txRequestSignatureShares[length - 1] assumes BitGo's response share is always last. ECDSA does the same thing so it's not a regression, but it would be more robust to filter explicitly:

const bitgoShare = txRequestSignatureShares.find(
  (s) => s.from === SignatureShareType.BITGO && s.to === SignatureShareType.USER
);
assert(bitgoShare, 'Missing BitGo round-2 share');

Follow-up safe; flagging here so the pattern doesn't propagate further.

[zahin-mohammad]

Note (not blocking, pre-existing pattern): signTxRequestForMessage accepts a TSSParamsForMessageWithPrv which includes messageRaw: string and bufferToSign: Buffer, but signRequestBase ignores both — it derives bufferContent from txRequest.messages[0].messageEncoded. ECDSA does the same thing so this PR isn't introducing the issue, but it's a quiet footgun: a caller who passes bufferToSign thinking that's what gets signed will be confused when actual signing uses the txRequest's messageEncoded. Worth filing as a separate cleanup ticket against the shared TSSParamsForMessageWithPrv contract.

[zahin-mohammad]

Coverage gap: rate-limit retries are tested for round 2 only. Rounds 1 and 3 use the same sendSignatureShareV2 retry path but aren't exercised. A parameterised helper that injects 429s on each round in turn would be cheap to add.

[zahin-mohammad]

Coverage gaps that pair with the mpcv2PartyId finding on the impl side:

• Tests only cover party 0 (USER); BACKUP path is untested.
• No round-2 tampered-signature negative test (round 1 negative is at L198, but round 2's verifyBitGoEddsaMessageRound2 could swallow tampering with no test catching it).
• No test for malformed/missing round-3 server response — currently any failure there surfaces as a confusing sendTxRequest error rather than something localised to round 3.