feat: add sdk changes for mpc tss support for TRON

[bhuvanr159]

TICKET: CHALO-33

Summary

This PR adds MPC (Multi-Party Computation) TSS (Threshold Signature Scheme) support for Tron (TRX), enabling ECDSA-based TSS wallets alongside the existing on-chain multisig wallets.

Changes

1. Statics — Feature Flags

modules/statics/src/coinFeatures.ts

• Added CoinFeature.TSS, CoinFeature.TSS_COLD, CoinFeature.MPCV2, and CoinFeature.SHA256_WITH_ECDSA_TSS to TRX_FEATURES.
• Existing MULTISIG and MULTISIG_COLD flags are retained — on-chain multisig continues to work as before.

2. Transaction Layer — Signable Payload & External Signatures

modules/sdk-coin-trx/src/lib/transaction.ts

• Added signablePayload getter that returns the protobuf-serialized raw_data bytes (raw_data_hex). This is the data that gets SHA-256 hashed and then ECDSA-signed during TSS flows.

modules/sdk-coin-trx/src/lib/transactionBuilder.ts

• Added addSignature(publicKey, signature) method to allow externally produced MPC signatures to be injected into the transaction.
• Updated buildImplementation() to attach the stored signature to the transaction's signature[] array.

modules/sdk-coin-trx/src/lib/wrappedBuilder.ts

• Added addSignature() passthrough that delegates to the underlying builder.

3. Coin Class — TSS Opt-in & Recovery

modules/sdk-coin-trx/src/trx.ts

• supportsTss() — returns true, enabling TSS wallet creation for TRX.
• getMPCAlgorithm() — returns 'ecdsa', declaring the MPC algorithm used.
• getHashFunction() — returns SHA-256, matching Tron's native hashing.
• getSignablePayload() — rebuilds a transaction from serialized form and returns its signablePayload.
• getDefaultMultisigType() — unchanged, still returns 'onchain'. Existing multisig wallets remain the default; TSS is opt-in via multisigType: 'tss'.
• isWalletAddress() — extended with a TSS branch using verifyMPCWalletAddress with secp256k1 curve for MPC-derived address verification.
• recover() — extended with an isTss flag. When true, delegates to the new recoverTSS() method. Existing on-chain multisig recovery is unaffected.
• recoverTSS() — new method implementing TSS sweep recovery with two paths:
  • Unsigned sweep (OVC): derives the wallet address from the common keychain, builds an unsigned transaction, and returns MPCTxs with signableHex, serializedTx, derivationPath, and commonKeychain for offline signing.
  • Online MPC signing: decrypts user/backup key shares via ECDSAUtils.getMpcV2RecoveryKeyShares, signs the SHA-256 hash of the signablePayload using ECDSAUtils.signRecoveryMpcV2, and attaches the resulting signature to produce a broadcastable transaction.
• createBroadcastableSweepTransaction() — new method that reassembles OVC-signed transactions. Parses the ECDSA signature (recid:r:s:y), derives the public key from the common keychain, constructs the 65-byte Tron signature (r + s + v), and attaches it to the transaction.
• auditDecryptedKey() — new method for TSS key auditing using auditEcdsaPrivateKey.

4. Dependency

modules/sdk-coin-trx/package.json

• Added @bitgo/sdk-lib-mpc as a dependency (required for auditEcdsaPrivateKey).

5. Test Fixture Update

modules/statics/test/unit/fixtures/expectedColdFeatures.ts

• Moved trx and ttrx from the justMultiSig list to the both (multisig + TSS cold) list, reflecting the new feature flags.

Backward Compatibility

• No breaking changes. All new code paths are gated behind explicit TSS opt-in parameters.
• getDefaultMultisigType() still returns 'onchain' — existing wallet creation defaults are unchanged.
• recover() only enters the TSS path when isTss: true is explicitly passed.
• isWalletAddress() only uses TSS verification when TSS-specific params are provided.
• All existing on-chain multisig flows (wallet creation, signing, recovery, address verification) remain unaffected.

[bhuvanr159]

@claude review this PR as grug; call out only potential issues, risks, or areas for improvement (no summaries or praise), be direct and actionable, max ~500 words.

[bhavidhingra]

please check whether we need to assign it to this.transaction or not.

[bhuvanr159]

No, we don't need to assign it to this.transaction. The base class build() method (in baseTransactionBuilder.ts) does not assign the result of buildImplementation() back to this.transaction , instead it simply returns it to the caller.

[bhavidhingra]

shouldn't we add recover related changes later when other operations are working?