Stellar has released version 28 of its Soroban Rust SDK, giving smart-contract developers access to a new set of deployment, upgrade and data-migration capabilities. According to the official Stellar developer announcement, the release introduces executable references, migration-friendly contract data, sparse event publishing, a revised build process and improved native-contract testing. The SDK update primarily changes how developers build and maintain Soroban contracts rather than altering application logic automatically.
The release is closely tied to Stellar’s Adapter, or Protocol 28, architecture. CAP-85 introduces externally managed contract executables, while CAP-86 adds sparse-map host functions intended to make contract-state schemas easier to evolve. Soroban SDK v28 exposes those protocol capabilities through Rust developer tooling, separating the SDK release from the underlying network upgrade itself. That distinction matters as Stellar’s application layer expands around areas such as tokenized Treasuries and credit products on Stellar.
Executable References Simplify Contract Fleet Upgrades
The largest architectural addition is support for executable references under CAP-85. Previously, a deployed contract executable was associated directly with a Wasm hash. Version 28 also allows a contract to reference a persistent entry, owned by another contract and identified by a tag, that contains the applicable Wasm hash. Changing that single reference can move every dependent contract to new code on its next invocation, reducing a fleet-wide upgrade to one reference update.
Contracts can manage these references through env.executable_refs(), while deployments and upgrades now accept a ContractExecutable that can represent either Wasm(hash) or an external reference. The change also affects custom accounts using __check_auth, because deployment authorization contexts can now contain the new executable type. Custom authorization logic that assumes every deployment supplies a direct Wasm hash must therefore be reviewed before migrating.
Contract-state migration becomes less rigid through CAP-86. Before v28, a stored #[contracttype] map had to match its Rust structure exactly, making the addition or removal of fields difficult without explicit versioning strategies. Version 28 can unpack maps sparsely, allowing a newly added optional field to resolve as None when older stored data does not contain it. This makes incremental schema evolution substantially easier without forcing developers to rewrite every existing ledger entry at once.
That upgrade flexibility becomes increasingly relevant as Stellar supports more complex application infrastructure. The network’s expanding tokenized real-world asset ecosystem raises the operational cost of contract migrations where applications may remain active for years. CAP-85 and CAP-86 address maintainability rather than application adoption, but they reduce friction for developers managing long-lived contract systems.
Events and Builds Require Migration Checks
Soroban SDK v28 also changes event serialization. For events using the default map format, top-level fields containing void or Option::None are now omitted completely instead of appearing with an empty value. Developers can disable this behavior with sparse = false when every field must remain present. Offchain indexers and consumers that assume optional keys always exist need to update their parsing logic.
The build system changes through “spec shaking v2.” The SDK now emits specification entries broadly before stellar-cli removes entries that are not actually part of the contract boundary. Developers must build Wasm contracts with stellar contract build using Stellar CLI v25.2.0 or newer, while the deprecated export argument on contracttype and contracterror now causes a compile error. The result is a contract specification based on what the interface actually exposes rather than Rust visibility alone.
Testing also gains Env::upload, allowing native Rust contracts to be uploaded in test environments as though they were Wasm and then deployed repeatedly from the resulting hash. Meanwhile, Stellar’s broader contract roadmap is moving toward more demanding cryptographic applications, including post-quantum verification through Soroban. The new testing capability reduces friction for contract factories and deployment workflows without changing production execution semantics.
Developers migrating to v28 therefore need to review build commands, event consumers, stored-data assumptions and custom authorization logic before deployment. The next concrete milestone is production adoption of v28-built contracts after teams complete compatibility testing and security review, particularly because Stellar currently lists this SDK version as not yet audited.
Emma Lawson writes about the pressure points where crypto meets the outside world: regulation, exchanges, macro policy, tokenized assets and geopolitical risk. From the US, she follows the decisions and events that can change how capital moves, how platforms operate and how digital assets are treated by institutions.
Her work is direct and evidence-led. Emma is less interested in legal theatre than in practical consequences: what changed, who is affected, which risks are real and where the market may be overreacting. She brings a steady voice to complex stories, especially when regulation, infrastructure and global markets start pulling in the same direction.