Context
soroban-sdk 26.1.0 was released on 2026-06-08. The following user-facing changes in this release (and the preceding 26.0.x patch series) are not yet covered in the Stellar docs.
Missing / incomplete documentation
1. export = ... deprecation under experimental_spec_shaking_v2
SDK change: #1876
When experimental_spec_shaking_v2 is enabled, using export = true or export = false on #[contracttype], #[contracterror], and #[contractevent] macros now emits a compiler deprecation warning. Under v2, spec entries are determined by reachability (dead-code elimination), not by the export hint.
Docs needed:
- A note in any existing guide that mentions
export = ... (if one exists), or a new guide on experimental_spec_shaking_v2 behaviour.
- Upgrade guidance: contracts using
export = false to exclude internal types should migrate to letting the linker shake them out naturally.
2. #[cfg] attribute support on #[contracttrait] and #[contractimpl]
SDK change: #1871
A bug fix that now correctly handles #[cfg(...)] attributes on:
#[contracttrait] default function methods (cfg/cfg_attr on default functions is explicitly rejected with a clear error)#[contractimpl(contracttrait)] override methods (direct #[cfg] is now supported; the generated default-function wrapper is emitted under the inverse cfg)- Generated args helpers and test registration code now follow the same cfg as the method
Docs needed: A guide or section explaining how to use conditional compilation (#[cfg]) with contract traits and implementations — a common pattern for platform-specific logic or feature flags.
3. Hash<N> provenance guarantees
SDK change: #1870 (landed in 26.0.x)
The SDK docs for Hash<N> were updated to clarify that while values returned by SDK crypto functions are hash outputs, Hash<N> is represented at contract boundaries as BytesN<N>, so accepting it as a contract argument does not prove the bytes came from a hash function.
Docs needed: Any documentation on the Hash<N> type or on writing custom account contracts (__check_auth) should note this provenance limitation — callers can pass arbitrary bytes in the Hash<N> position.
4. BytesN<N> → [u8; N] zero-copy conversion guide (partial)
SDK change: #1888 (26.1.0)
A companion PR to this issue (#2479) added a basic BytesN to Fixed-Size Array section to bytes-conversions.mdx. What's still missing:
- A note about when to prefer
to_array() over iterating manually
- Cross-reference from the
BytesN type description in the types reference
Related
Context
soroban-sdk 26.1.0 was released on 2026-06-08. The following user-facing changes in this release (and the preceding 26.0.x patch series) are not yet covered in the Stellar docs.
Missing / incomplete documentation
1.
export = ...deprecation underexperimental_spec_shaking_v2SDK change: #1876
When
experimental_spec_shaking_v2is enabled, usingexport = trueorexport = falseon#[contracttype],#[contracterror], and#[contractevent]macros now emits a compiler deprecation warning. Under v2, spec entries are determined by reachability (dead-code elimination), not by theexporthint.Docs needed:
export = ...(if one exists), or a new guide onexperimental_spec_shaking_v2behaviour.export = falseto exclude internal types should migrate to letting the linker shake them out naturally.2.
#[cfg]attribute support on#[contracttrait]and#[contractimpl]SDK change: #1871
A bug fix that now correctly handles
#[cfg(...)]attributes on:#[contracttrait]default function methods (cfg/cfg_attr on default functions is explicitly rejected with a clear error)#[contractimpl(contracttrait)]override methods (direct#[cfg]is now supported; the generated default-function wrapper is emitted under the inverse cfg)Docs needed: A guide or section explaining how to use conditional compilation (
#[cfg]) with contract traits and implementations — a common pattern for platform-specific logic or feature flags.3.
Hash<N>provenance guaranteesSDK change: #1870 (landed in 26.0.x)
The SDK docs for
Hash<N>were updated to clarify that while values returned by SDK crypto functions are hash outputs,Hash<N>is represented at contract boundaries asBytesN<N>, so accepting it as a contract argument does not prove the bytes came from a hash function.Docs needed: Any documentation on the
Hash<N>type or on writing custom account contracts (__check_auth) should note this provenance limitation — callers can pass arbitrary bytes in theHash<N>position.4.
BytesN<N>→[u8; N]zero-copy conversion guide (partial)SDK change: #1888 (26.1.0)
A companion PR to this issue (#2479) added a basic
BytesN to Fixed-Size Arraysection tobytes-conversions.mdx. What's still missing:to_array()over iterating manuallyBytesNtype description in the types referenceRelated