feat(sdk-coin-near): MPCv2 signed hot recovery - #9485
Draft
bitgo-ai-agent-dev[bot] wants to merge 2 commits into
Draft
feat(sdk-coin-near): MPCv2 signed hot recovery#9485bitgo-ai-agent-dev[bot] wants to merge 2 commits into
bitgo-ai-agent-dev[bot] wants to merge 2 commits into
Conversation
Add MPCv2 detection and signing to Near.recover() alongside the existing MPCv1 path. What changed: - Import getEddsaSigningMaterial and signEddsaMpcV2RecoveryTx from @bitgo/sdk-core in near.ts - Add isMpcv2SigningMaterial() private method that decrypts the user keycard once and returns true when the plaintext is CBOR (MPCv2) - Refactor signRecoveryTransaction() to accept an isMpcV2 boolean; when true it calls signEddsaMpcV2RecoveryTx (MPS DSG) instead of the legacy EDDSAMethods.getTSSSignature path - Call isMpcv2SigningMaterial() once at the top of recover() and thread the isMpcV2 flag into both the native NEAR and NEP141 FT token paths - Add three new unit tests: native MPCv2 signed recovery, NEP141 FT token MPCv2 signed recovery, and bitgoKey/commonKeyChain mismatch Why: NEAR wallets provisioned with the new Silence Labs (MPCv2) key material cannot be recovered with the Zengo-era getTSSSignature path because the keycard format is different (CBOR base64 vs JSON uShare/yShare). This adds the same MPCv2 detection+signing path that was introduced for SOL in WCI-398, enabling hot recovery for MPCv2 NEAR wallets without any new caller-visible parameters. Ticket: WCI-1223 Session-Id: 8de2a998-4754-4499-82b5-49167b8d9fd6 Task-Id: 7e0eb924-0c33-4cc6-9402-c71587bb14a5
Contributor
ralph-bitgo
Bot
force-pushed
the
WCI-1223-near-mpcv2-signed-hot-recovery
branch
from
August 12, 2026 11:49
5fc6899 to
f43e93f
Compare
…ion call Wrap long function call arguments to satisfy the project's line-length constraint enforced by prettier/eslint. Ticket: WCI-1223 Session-Id: 8de2a998-4754-4499-82b5-49167b8d9fd6 Task-Id: 7e0eb924-0c33-4cc6-9402-c71587bb14a5
ralph-bitgo
Bot
force-pushed
the
WCI-1223-near-mpcv2-signed-hot-recovery
branch
from
August 12, 2026 12:29
ed8bc24 to
d062b1f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
getEddsaSigningMaterialandsignEddsaMpcV2RecoveryTxfrom@bitgo/sdk-coreinnear.tsisMpcv2SigningMaterial()private method: decrypts the user keycard once and returnstruewhen the plaintext is CBOR-encoded (MPCv2 Silence Labs format) vs JSON (MPCv1 Zengo format)signRecoveryTransaction()to accept anisMpcV2boolean: whentrue, routes tosignEddsaMpcV2RecoveryTx(MPS DSG local signing) instead of the legacyEDDSAMethods.getTSSSignaturepathisMpcV2once at the top ofrecover()and thread the flag through both the native NEAR transfer path and the NEP141 FT token recovery path (recoverNearToken)bitgoKey/commonKeyChainmismatch errorWhy
NEAR wallets provisioned with the new Silence Labs (MPCv2) key material cannot be recovered using the legacy
getTSSSignaturepath because the keycard format is different (CBOR base64 reduced share vs JSONuShare/yShare). This adds the same MPCv2 detection + signing path introduced for SOL in WCI-398, enabling hot signed recovery for MPCv2 NEAR wallets without requiring any new caller-visible parameters. Detection is automatic based on keycard format.Test plan
should route to MPCv2 path for native NEAR recovery when keycard is MPCv2— verifies signed tx returned,getTSSSignaturenot calledshould throw when MPCv2 commonKeyChain does not match bitgoKey— verifies mismatch errorshould route to MPCv2 path for NEP141 FT token recovery when keycard is MPCv2— verifies token recovery routes to MPCv2Ticket: WCI-1223