Stellar’s blockchain just got a serious speed and safety upgrade. Developers call it Adapter, and the network knows it internally as Protocol 28. The Stellar Adapter upgrade begins its testnet vote today. If approval goes smoothly, validators vote on a mainnet rollout on September 16, 2026.
The Stellar Development Foundation built Adapter to fix three problems that have quietly limited the network for years. Consensus slows under heavy load, smart contract upgrades can break live apps, and data structures stay too rigid to evolve safely. Each fix targets real friction developers hit today, not a hypothetical future problem.
Validators Now Vote Before All the Data Arrives
The biggest change lives in a proposal called CAP-83. Right now, Stellar validators wait for a complete transaction set to arrive before they vote on the next ledger. That wait becomes a bottleneck when the network gets busy and data propagates slowly across nodes.
Adapter changes the order of operations. Validators can start voting before the full transaction set lands, so the network keeps moving even when some data trails behind. Stellar Core also picked up a related fix: it can now download pieces of a transaction set in parallel instead of one at a time. A new empty transaction-set marker keeps ledgers closing on schedule.
The result: ledgers close faster, and close times stay steady even as usage spikes. That kind of consistency matters for any app that promises users a fast, predictable payment.
Smart Contracts Can Now Upgrade as a Fleet
Adapter’s second big change targets developers running many related smart contracts at once. Under CAP-85, a contract can now point to shared, externally managed code instead of carrying its own copy. Update that one shared reference, and every contract pointing to it upgrades atomically. No more updating dozens of instances one by one and hoping nothing breaks in between.
This pattern mirrors the beacon proxy model used on other chains, and it cuts real operational risk. A partial upgrade across a fleet of contracts is exactly the kind of gap attackers look for. Adapter closes it.
Safer Data Migrations With CAP-86
The third piece, CAP-86, introduces what Stellar calls sparse host functions. Today, if a contract’s stored data does not exactly match what code expects, calls fail outright. Sparse functions let contracts handle missing or extra fields gracefully instead of rejecting the whole transaction.
That sounds small, but it unlocks something developers have wanted for a long time. Contracts can now change their data structure over time without breaking every contract that already uses the old one. Schema migrations move from risky to routine.
Why the Stellar Adapter Upgrade Matters
None of these three changes make headlines on their own. Together, they remove friction that has slowed builders on Stellar. Consensus chokes under load, contract fleets upgrade one risky step at a time, and data schemas stay frozen in place. Adapter fixes all three without asking most integrators to do more than update their SDK.
Other chains are chasing similar goals right now. Cardano’s Dijkstra upgrade tackles blockchain scaling from a different angle, and Algorand’s 5.0 release doubled smart contract capacity earlier this week. Adapter shows Stellar racing toward the same finish line: faster networks that developers can actually trust with production code.
Stellar Core’s stable release shipped August 13, and infrastructure and SDK updates followed through August 21. The testnet vote lands today, August 27. Read the Stellar Development Foundation’s full announcement for the technical specification.