## 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 - #486 — align deps and struct shapes for stellar-cli 26.0.0 - scaffold-stellar-frontend#208 / #465 — soroban-sdk 25.x + OZ v0.7.x upgrade tracking