feat(sdk-core): add getVaultConfig and Concrete BTC deposit path to DefiVault#9206
Closed
bitgo-ai-agent-dev[bot] wants to merge 2 commits into
Conversation
…endManyOptions Part 1 of 2 for DEFI-279 (CB-1.8). Types + interfaces + dependency bump: - Add GetVaultConfigOptions, VaultProvider, VaultConfig, ConcreteVaultConfig, ConcreteDepositResult to iDefiVault.ts; update DepositResult to a discriminated union (concrete_btccx pendingApproval | morpho operationId); add getVaultConfig to IDefiVault interface - Add defiParams: t.unknown to BuildParams whitelist so it passes through prebuildWhitelistedParams() without being stripped - Add optional defiParams field to SendManyOptions for discoverability - Bump @bitgo/public-types to ^6.39.0 (picks up defiParams on TxSendBody) Ticket: DEFI-279 Session-Id: ba171a5f-3d3c-4505-9e87-8df8afe5d59f Task-Id: bffe5f00-9f9c-4882-be0f-d620f6eba4c5
…efiVault
Part 2 of 2 for DEFI-279 (CB-1.8). Core logic + tests:
- Add getVaultConfig(params) to DefiVault, proxying
GET /api/defi-service/v1/vaults/:id
- Rename current depositToVault body to private depositToMorphoVault (unchanged)
- Add protocol dispatch in depositToVault: calls getVaultConfig, routes
concrete_btccx → depositToConcreteVault, morpho → depositToMorphoVault
- depositToConcreteVault: single sendMany with type 'defi-deposit' and
defiParams {vaultId, amount, actionType}; no recipients key passed
- extractConcreteDepositResult: extracts pendingApprovalId+state from the
custodial sendMany response (pendingApproval.id), throws on missing id
- Unit tests: getVaultConfig happy path + error cases, Concrete dispatch
(single sendMany, no recipients, pendingApproval extraction, passphrase),
Morpho regression guard (existing two-sendMany behavior unchanged)
Ticket: DEFI-279
Session-Id: ba171a5f-3d3c-4505-9e87-8df8afe5d59f
Task-Id: bffe5f00-9f9c-4882-be0f-d620f6eba4c5
Contributor
bitgo-ai-agent-dev
Bot
force-pushed
the
venkatesh/defi-279-deposittovault-getvaultconfig-pt2
branch
from
b951029 to
a97666b
Compare
2 tasks
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
getVaultConfig(params)toDefiVault, proxyingGET /api/defi-service/v1/vaults/:iddepositToVault: callsgetVaultConfig, routesconcrete_btccx→depositToConcreteVault,morpho→depositToMorphoVault(renamed from the existing body, unchanged)depositToConcreteVault: singlesendManywithtype: 'defi-deposit'anddefiParams: { vaultId, amount, actionType }; norecipientskey passed (WP resolves escrow destination server-side)extractConcreteDepositResult: extracts{ pendingApprovalId, state }from the custodialsendManyresponse (pendingApproval.id); throws descriptively on unexpected shapegetVaultConfighappy path + error cases, Concrete dispatch (single sendMany, no recipients, pendingApproval extraction, passphrase forwarding), Morpho regression guard (existing two-sendMany path unchanged)Why
sendManyreturns apendingApprovalrather than a signed txRequest. A singlesendManywithtype: 'defi-deposit'anddefiParamsis the correct path (no approve step needed)depositToVaultAPI regardless of protocol — provider dispatch belongs in the SDK, not in the callerTest plan
yarn unit-test -- --grep "DefiVault"inmodules/sdk-core: 24 passing, 1 pendingyarn buildinmodules/sdk-coreStack
This PR is part 2 of 2 in a stack. Review and merge in order:
master)pt1) ← you are hereTicket: DEFI-279