What happened

A new project using soroban-sdk = 27.0.0 with testutils fails to compile when Cargo creates a fresh lockfile. soroban-env-host 27.0.0 declares ed25519-dalek = ">=2.0.0", so Cargo now selects ed25519-dalek 3.0.0 / rand_core 0.10. The host's rand_chacha 0.3.1 uses rand_core 0.6, and SigningKey::generate(chacha) therefore fails its CryptoRng bound.

The same open-ended constraint is still present on main. The adjacent comments already state that the ed25519-dalek, rand, and rand_chacha versions must match.

Minimal reproduction

Cargo.toml:

[package]
name = "soroban-sdk27-fresh-lock-repro"
version = "0.1.0"
edition = "2021"

[dev-dependencies]
soroban-sdk = { version = "=27.0.0", features = ["testutils"] }

src/lib.rs:

#[cfg(test)]
mod tests {
    #[test]
    fn sdk_testutils_compile() {
        let _env = soroban_sdk::Env::default();
    }
}

From an empty directory with no lockfile:

$ cargo test
error[E0277]: the trait bound `ChaCha20Rng: ed25519_dalek::rand_core::CryptoRng` is not satisfied
  --> soroban-env-host-27.0.0/src/builtin_contracts/testutils.rs:29:58
   |
29 | host.with_test_prng(|chacha| Ok(SigningKey::generate(chacha)))
   |                                 -------------------- ^^^^^^

Cargo resolves both rand_core 0.6.4 (through rand_chacha 0.3.1) and rand_core 0.10.1 (through ed25519-dalek 3.0.0).

Confirmed workaround

Adding this direct dev dependency makes the same project compile and its test pass:

ed25519-dalek = "=2.2.0"

Suggested fix

Bound the host dependency to the compatible major, for example ed25519-dalek = ">=2.0.0, <3.0.0" (or the project's preferred equivalent), and add a fresh-lockfile resolver check so a newly published incompatible major cannot silently break soroban-sdk/testutils again.

I can prepare a PR if this direction is acceptable.

Environment

• soroban-sdk 27.0.0
• soroban-env-host 27.0.0
• Rust/Cargo stable on macOS arm64
• Reproduced July 15, 2026 from a fresh Cargo lockfile