Summary

When building example contracts in a fresh stellar scaffold init project, cargo compiles both stellar-strkey v0.0.13 and stellar-strkey v0.0.16 into the same workspace. PR #486 pinned stellar-strkey = 0.0.15 in the scaffold-stellar workspace specifically to eliminate duplicate-crate type mismatches with stellar-cli 26 — but the user-facing template still pulls in v0.0.13 transitively.

Environment

• Stellar CLI: v26.0.0
• stellar-scaffold-cli: v0.0.24
• stellar-registry-cli: v0.0.21

Output

Build output for guess-the-number (and same pattern for the OZ contracts):

[stellar]    Compiling stellar-strkey v0.0.13
[stellar]    Compiling stellar-xdr v23.0.0
[stellar]    Compiling soroban-env-common v23.0.1
[stellar]    Compiling stellar-strkey v0.0.16
[stellar]    Compiling soroban-sdk v23.5.3

Concern

This is the exact "duplicate crate" pattern that #486 addressed at the workspace level. If the template propagates the conflict downstream, users hitting type mismatches in their own contracts wouldn't have a clear path to fixing it — the duplication is in transitive dependencies.

Suggested investigation

• Where is v0.0.13 coming from? Likely via soroban-env-common 23.0.1 or stellar-xdr 23.0.0 in the template
• Should the template Cargo.toml add an explicit pin to align with the scaffold workspace?
• Is this expected during the soroban-sdk 23 → 25 → 26 transition, or is it a real bug?

Note: would like the maintenance label applied to this issue once it's created in the repo.

Related

• fix: align deps and struct shapes for stellar-cli 26.0.0 #486 — align deps and struct shapes for stellar-cli 26.0.0
• scaffold-stellar-frontend#208 / Bump LATEST_SUPPORTED_OZ_RELEASE to v0.7.x #465 — soroban-sdk 25.x + OZ v0.7.x upgrade tracking