The temptation
A dependency report shows ~47 of EmpoorioChain's 124 direct dependencies behind the latest crates.io release. The instinct is to update them.
Why most must stay
libp2p, jsonrpsee, polkavm, wasmi, revm, syn, bitflags and many more are versions fixed by polkadot-sdk. Advancing one ahead of the SDK either breaks compatibility or puts two copies of the crate in the lock file — two wasmtimes, two frame-metadatas, two of anything that carries types across crate boundaries.
The rule
The right version is the one polkadot-sdk uses, not the newest. The question to ask of any upgrade is which version is already in the tree because the SDK brought it? — and to move toward that.
The subxt example (1 September 2026)
The workspace was on subxt 0.38; the latest was 0.50; the correct target was 0.44, because that is what the SDK's frame-benchmarking-cli brings. Moving to 0.50 would have created a duplicate in the other direction. Moving to 0.44 removed the duplicate — and a duplicated frame-metadata with it.
Same with arkworks: 0.5 → 0.6 was worth doing because 0.6 was already in the tree via the SDK's VRF crates. The upgrade merged families rather than adding one.
Vulnerabilities you cannot fix
cargo audit reports eight advisories. Seven come from libp2p 0.54.1 (in h2, a DNS crate, an old ring, three in rustls-webpki) or from an exact SDK pin (tracing-subscriber = "=0.3.19"). Every Polkadot node inherits them; they are not fixable without patching the SDK. Before "fixing" an advisory, check its reverse dependencies — if it comes through the SDK, the fix is upstream.
Related
The Frontier fork is vendored precisely so it can be made to compile against the SDK version the workspace uses. When the tree had two SDKs and two wasmtimes, the fix was to connect the fork to the same SDK — not to override versions. Zero duplicate SDK crates, one wasmtime 36.
From the EmpoorioChain dependency review, 2026-09-01.