Four majors of @stellar/stellar-sdk in one repo, two behind latest — unify and make it a peer dep

[Miracle656]

The problem

One monorepo, four different majors of @stellar/stellar-sdk, none of them current:

Package	Declares
sdk	^15.1.0
frontend/wallet	^14.6.1
frontend/mobile	^14.6.1
packages/agent	^16.1.0
latest on npm	17.0.1

And it really does duplicate at install time:

frontend/mobile/node_modules/@stellar/stellar-sdk                     14.6.1
frontend/mobile/node_modules/@blend-capital/blend-sdk/node_modules/…  16.0.0
frontend/wallet/node_modules/@stellar/stellar-sdk                     14.6.1
frontend/wallet/node_modules/@blend-capital/blend-sdk/node_modules/…  14.4.3
packages/agent/node_modules/@stellar/stellar-sdk                      14.6.1

Note the last row: the agent declares ^16.1.0 but has 14.6.1 installed.

Why it is worth fixing

Two copies of stellar-sdk in one process means two separate class identities. An Asset, Transaction or Keypair built by one copy fails instanceof against the other, and the failure surfaces far from its cause as a confusing type or serialisation error rather than a clean version conflict. We already spend real time debugging in this area.

The SDK also declares @stellar/stellar-sdk as a regular dependency, which guarantees a consumer gets our copy alongside their own. For a library this belongs in peerDependencies, so the application chooses the version and there is exactly one.

Scope

• Move @stellar/stellar-sdk to peerDependencies (plus devDependencies for building and tests) in sdk/package.json
• Align every package in the repo onto one major, ideally current
• Fix the agent's declared-vs-installed drift
• Note in the PR whether @blend-capital/blend-sdk can be satisfied by the shared copy or genuinely needs its own

Watch out for

• 14 → 17 crosses two majors. Read the stellar-sdk changelogs; expect breaking changes around rpc/SorobanRpc naming, Horizon types and transaction assembly. This is not a version-bump-and-ship.
• Protocol 25 (X-Ray) is live on mainnet. Confirm the chosen version supports what the contracts use before settling on it.
• The passkey signing path is the sharpest edge — derToRawSignature, low-S normalisation, SorobanAuthorizationEntry assembly. Re-verify a real passkey spend on testnet after upgrading; a green typecheck proves nothing here.
• Contracts must not be redeployed. The mainnet WASM matches contracts/expected-hashes.json byte-for-byte and that reproducible-build claim is load-bearing. This is a JS-side change only.
• Mobile uses plain npm install, not --legacy-peer-deps. sdk/ is the opposite.

Acceptance criteria

• @stellar/stellar-sdk is a peer dependency of the SDK
• One major across sdk, frontend/wallet, frontend/mobile, packages/agent, and declared matches installed
• No duplicate copy in the install tree except any that blend-sdk provably requires
• A passkey-authorised transaction verified end to end on testnet, with the hash in the PR
• Typecheck, tests and builds green in every touched package

Drips Wave · Complexity: Advanced · 200 points

---

Required: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk

[Silver36-ship-it]

@Silver36-ship-it has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I would love to work on this professionally, please assign it to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Silver36-ship-it to this issue.

[zainmatty22]

@zainmatty22 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello,
I’ve reviewed the details. I will deliver on schedule and to standard.
Assign this to me.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @zainmatty22 to this issue.

[Goodnessoj]

@Goodnessoj has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi @maintainer would love to resolve this, please assign this issue to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Goodnessoj to this issue.

[ibochivincent-lang]

@ibochivincent-lang has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I intend to resolve Issue #660 by first auditing how @stellar/stellar-sdk is declared, resolved, and installed across the monorepo. The goal is to eliminate unnecessary duplicate SDK instances while maintaining compatibility with the existing wallet, mobile, agent, Blend, and Soroban functionality.

I will begin by reviewing the package.json files and lockfile for sdk, frontend/wallet, frontend/mobile, and packages/agent to identify all direct and transitive Stellar SDK requirements. I will also inspect the actual installed dependency tree so that declared versions and resolved versions are consistent, particularly for the current agent drift.

Before selecting the target version, I will review the Stellar SDK changelogs and migration guidance for the major-version jump from 14/15/16 to the current major. I will specifically check changes affecting RPC/SorobanRpc APIs, Horizon types, transaction assembly, and Soroban authorization. I will also verify that the selected version supports the protocol features currently used by the project, including Protocol 25/X-Ray.

For the sdk package, I will move @stellar/stellar-sdk from dependencies to peerDependencies and retain it in devDependencies so the SDK can still be built and tested independently. I will then align the other packages onto the same compatible major version and regenerate the appropriate lockfiles using the repository's required installation workflows.

I will pay particular attention to @blend-capital/blend-sdk. Rather than assuming its dependency can be deduplicated, I will inspect its peer/dependency requirements and verify whether it can safely use the repository's shared Stellar SDK version. If it genuinely requires a separate version, I will document that clearly in the PR.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @ibochivincent-lang to this issue.

[Mamavee001]

@Mamavee001 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I would like to apply for Issue #660 and help resolve the multiple @stellar/stellar-sdk versions currently used across the monorepo.

I will first audit the package manifests and lockfiles for sdk, frontend/wallet, frontend/mobile, and packages/agent to identify all direct and transitive SDK versions and understand the agent's declared-versus-installed mismatch.

Before choosing the target version, I will review the Stellar SDK migration notes and changelogs, particularly the breaking changes affecting Soroban RPC, Horizon types, transaction assembly, and authorization. I will also confirm compatibility with Protocol 25 and the contracts currently used by Veil.

I will move @stellar/stellar-sdk from dependencies to peerDependencies in sdk/package.json, while keeping it in devDependencies for SDK development and testing. I will then align the affected packages to one compatible major and regenerate the appropriate lockfiles using the repository's required installation workflows.

I will specifically investigate @blend-capital/blend-sdk to determine whether it can safely use the shared SDK version or genuinely requires its own copy. Any unavoidable duplication will be documented clearly rather than hidden.

The passkey signing flow will receive dedicated testing because SDK upgrades can affect signature conversion, low-S normalization, and SorobanAuthorizationEntry construction. I will perform an end-to-end passkey-authorized transaction on Stellar testnet and include the resulting transaction hash in the PR.

I will also verify that no contract files or WASM artifacts are modified or redeployed as part of this dependency migration.

Finally, I will run typechecks, tests, builds, and dependency-tree checks across all affected packages to confirm that declared versions match installed versions and unnecessary duplicate SDK copies have been removed.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Mamavee001 to this issue.

[Kenlachy]

@Kenlachy has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi maintainer, I’d love to work on this issue. I’ve reviewed the requirements and I’m ready to get started. Please consider assigning it to me.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Kenlachy to this issue.

[AGWAM001]

@AGWAM001 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Subject: Unify @stellar/stellar-sdk to single peer dep across monorepo

Problem
We currently have 4 different majors of @stellar/stellar-sdk in one repo:
sdk ^15.1.0, wallet ^14.6.1, mobile ^14.6.1, agent ^16.1.0. Latest is 17.0.1.
Install shows duplicates and agent declares 16.1.0 but installed 14.6.1.

This causes 2 SDK copies in one process → different class identities. Asset, Transaction, Keypair from one copy fail instanceof against the other. Bugs surface as weird type/serialization errors.

Proposed fix

1. Move @stellar/stellar-sdk to peerDependencies in sdk/package.json + devDependencies for build/tests
2. Align all packages to one major, target 17.0.1
3. Fix agent drift and verify install tree has no duplicates
4. Check if @blend-capital/blend-sdk can use the shared copy

Risks to verify
14 → 17 has breaking changes: RPC/Soroban naming, Horizon types, tx assembly.
Protocol 25 support must be confirmed.
Re-test passkey signing flow end-to-end on testnet. No contract redeploys.

Acceptance
Single SDK version, green typecheck/tests/builds, 1 passkey tx hash in PR.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @AGWAM001 to this issue.

[drips-wave]

Congratulations, @AGWAM001! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @AGWAM001: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊