Stellar Protocol 28: A Technical Deep Dive into the Adapter Upgrade

Consensus behavior changes, contract fleets get a real upgrade primitive, and the authorization model on Soroban finally drops the legacy credentials introduced one protocol ago. For engineers, this is the kind of upgrade that doesn't break you tomorrow — but if you skip the homework, it will break you the next time you push a fleet-wide change.

CAP-83: Voting Before the Transaction Set Lands

The bottleneck CAP-83 addresses is propagation lag under contention. Validators can now begin voting on transactions before the full transaction set arrives, with parallel transaction-set downloading phased in after mainnet activation. Finality semantics and ledger shape stay the same, so application code is unaffected. The catch sits with anyone consuming raw ledger entries: a new value type ships alongside this change, which means your indexer or custom parser needs explicit handling for it before parallel download rolls out. Conversely, teams talking to Stellar only through Horizon or the RPC surface won't see anything change at the SDK level yet — but mark this in your backlog regardless, because the moment you need a custom analytics pipeline, that new type will be the thing that breaks it.

CAP-85 and CAP-86: A Beacon Proxy and Schema Tolerance

For teams running more than a handful of contracts, CAP-85 is the change that justifies reading the rest of the protocol notes. Contracts can now point to a single shared, externally managed executable — an updatable code reference that every linked contract resolves at call time. This is the beacon proxy pattern familiar from other chains, and it gives you atomic upgrades across an entire fleet rather than the coordination gap of upgrading contracts one at a time and hoping no one transacts in between. The trade-off is obvious once you name it: the upgrade authority becomes a higher-value target, and a buggy new implementation now affects every dependent contract in one block. In practice that argues for the same discipline any upgradeable proxy system demands — timelock on the upgrade key, multisig on the authority, staged rollout with pause guards.

CAP-86 lands alongside it and tackles the data side of the same problem. Sparse host functions let contracts tolerate missing or extra fields when comparing data entries, so schema drift between deployed contracts no longer hard-fails upgrades. You'll need to rebuild against the updated Stellar SDK to pick this up, and migration guides are forthcoming — but the structural win is real: contract data can evolve without forcing a perfect one-to-one match, which removes one of the more annoying reasons fleet upgrades used to stall.

The Soroban Authorization Cutover

The change that will touch every active Soroban project is the mandatory move to AddressV2 for authorization. Legacy credentials from Protocol 27 are being phased out, RPC simulation defaults flip to AddressV2 with this upgrade, and features like delegated authorization become available on top. The practical work is straightforward but unavoidable: authorization helpers, signature verification, and any code branching on address representation need to be rebuilt against the updated SDK. If your authorization paths handle multi-sig, sponsored reserves, or delegated signing, audit them now for assumptions that only hold under AddressV1 semantics — those are the surfaces that will quietly break the day the RPC default flips, and they are the hardest to find in a post-mortem.