Foundation
Protocol upgrades
Stellar protocol upgrades are network-wide changes to consensus and core functionality. Validators must update their software to stay in sync. Upgrades may add new features, improve transaction performance, or strengthen network security.
The Latest
Bell | Protocol 30
Bell, Protocol 30, makes smart accounts ready for businesses at scale and starts work on two longer-term goals: quantum-safe signatures and faster ledgers. It adds muxed contract addresses, post-quantum signature verification in smart contracts, and millisecond ledger close times.
Testnet upgrade vote: November 3, 2026, 1700 UTC. Mainnet upgrade vote: November 23, 2026, 1700 UTC. Dates are subject to change. Upgrade to the latest Stellar SDK before the votes; if you decode raw ledger data without an SDK, update your XDR definitions.
Bell
CAP-0084
Muxed contract addresses: a contract address can carry a 64-bit ID (new W address), so one smart account can serve many customers
CAP-0087
Soroban host functions to verify ML-DSA post-quantum signatures, so contract accounts can require quantum-safe authorization
CAP-0088
Records ledger close times in milliseconds instead of whole seconds, the protocol-level prerequisite for faster ledgers
CAP-0087
Quantum-safe signatures for smart contracts
Stellar, like almost every major blockchain, secures accounts with elliptic-curve signatures, which a large enough quantum computer could break. In 2024, NIST finalized ML-DSA as a post-quantum signature standard, and it already ships in mainstream software such as OpenSSL and Java.
CAP-0087 lets Stellar smart contracts verify ML-DSA signatures. Verification runs inside Stellar Core rather than in contract code, which keeps it cheap to call and means the implementation is written and tested once, against the official test vectors. A custom account contract can now require a quantum-safe signature to spend. Network transaction signatures stay Ed25519 for now.
CAP-0088
A millisecond clock for the ledger
Stellar records each ledger's close time in whole seconds, so the network can only target whole-second intervals. In September, Adapter (Protocol 28) brought mainnet ledger close times down from about 5.7 seconds to 5 seconds; as close times keep falling, whole-second timing becomes the thing that sets the pace.
CAP-0088 moves the ledger to a millisecond clock, the protocol-level prerequisite for faster ledgers. It changes the ledger header format: SDK users should upgrade before the votes, and anything that decodes raw ledger data must update its XDR definitions. The existing closeTime field still reports whole seconds.
Previous upgrades
- Protocol 28 9/16/26 - CAP-0083 (Faster consensus with empty transaction sets), CAP-0085 (Atomic upgrades for fleets of contracts), CAP-0086 (Migration-friendly contract data)
- Protocol 27 7/8/26 - CAP-0071-01 (Authentication delegation for custom accounts), CAP-0071-02 (Address-bound Soroban address credentials)
- Protocol 26 5/6/26 - CAP-0073 (SAC can create G-account balances), CAP-0077 (Freeze ledger keys via network configuration), CAP-0078 (Precise TTL extensions), CAP-0079 (Muxed address strkey conversions), CAP-0080 (Additional BN254 host functions), CAP-0082 (Checked 256-bit integer arithmetic)
- Protocol 25 1/22/26 - CAP-0074 (BN254 host functions), CAP-0075 (Poseidon/Poseidon2 hash primitives)
- Protocol 24 10/22/25 - Stability upgrade fixing a state archival bug in Stellar Core
- Protocol 23 9/3/25 - CAP-0062 (Network evicts persistent entries to archive), CAP-0063 (Parallel smart contract transaction processing), CAP-0065 (Cache parsed WASM modules permanently), CAP-0066 (New Soroban read resource types), CAP-0067 (Standardize Classic and Soroban events), CAP-0068 (Get executable from Soroban address), CAP-0069 (Convert String and Bytes types), CAP-0070 (Dynamic ledger timing configuration settings)
- Protocol 22 12/5/2024 - CAP-0058 (Introduce 'constructor' feature for Soroban smart contracts), CAP-0059 (BLS12-381 host functions).
- Protocol 21 6/18/2024 - CAP-0051 (Support secp256r1 verification), CAP-0053 (Allow extending the Time To Live (TTL)), CAP-0054 (Refining the Soroban cost model used for VM instantiation), CAP-0055 (Lower total costs by linking fewer host functions during VM instantiation), CAP-0056 (Lower total costs by caching parsed Wasm modules)
- Protocol 20 03-19-2024 - CAP-0046-01 (Soroban: Wasm smart contracts for Stellar), CAP-0046-02 (Smart contract structure and creation on Stellar.), CAP-0046-03 (Host functions for Stellar Wasm contracts.), CAP-0046-05 (Smart contract data storage and interaction.), CAP-0046-06 (Allow contracts to interoperate with Stellar assets.), CAP-0046-07 (Smart contract fee mechanism.), CAP-0046-08 (Contract metadata writing for downstream systems.), CAP-0046-09 (Network-wide configuration storage and upgrades.), CAP-0046-10 (Smart contract resource metering framework.), CAP-0046-11 (Smart contract authorization framework.), CAP-0046-12 (Soroban state archival interface.)
- Protocol 19 6-8-2022 - CAP-0021 (Generalized transaction conditions and timelocks.), CAP-0040 (Shared transaction signing for contracts.)
- Protocol 18 11-3-2021 - CAP-0038 (Automated market maker liquidity.)
- Protocol 17 6-1-2021 - CAP-0035 (Asset clawback for regulatory compliance.)
- Protocol 16 4-10-2021 - CAP-0029 (Issuer trustline authorization semantics.)
- Protocol 15 11-23-2020 - CAP-0023 (Separate payment sending and receiving.), CAP-0033 (Cross-account reserve payments), CAP-0034 (Nomination protocol close time selection)
- Protocol 13 6-18-2020 - CAP-0015 (Fee-bump transactions for arbitrary accounts), CAP-0018 (Partial trustline authorization for issuers.), CAP-0019 (Extensible transaction envelope union.), CAP-0027 (Multiplexed accounts with memo IDs.), CAP-0028 (Pre-auth signer removal on application.), CAP-0030 (Remove unnecessary asset issuer errors.)
- Protocol 12 10-10-2019 - CAP-0024 (PathPayment with fixed send amount.), CAP-0025 (Bucket list simplification removing shadows.), CAP-0026 (Disables the inflation mechanism.)
- Protocol 11 6-10-2019 - CAP-0005 (Network throttling and fee rationalization), CAP-0006 (ManageBuyOffer operation for buying asset.), CAP-0020 (Bucket entry type extensions.)
- Protocol 10 2-8-2018 - CAP-0001 (Bump sequence operation.), CAP-0002 (Consistent signature verification for contracts), CAP-0003 (Asset-backed offers execution guarantee.), CAP-0004 (Offer crossing algorithm improvements.)