Announcing Protocol 23

Good day and welcome to the Protocol 23 announcement blog. Protocol 23 introduces eight (!!) new Core Advancement Proposals (CAPs) to the Stellar network, detailed below.

The Mainnet vote will occur on August 14, 2025, with the CAPs going live on Testnet on June 30th, 2025.

Before we dive into the details, here’s a high-level summary of what’s new in Protocol 23:

• SEP-0041: Soroban Token Interface events can now be emitted for all Stellar operations that move value on the network. Learn more by perusing CAP-0067.
• Soroban costs are decreased thanks to moving Soroban state to RAM. Learn more in CAP-0062 and CAP-0066. Costs are also lowered because of the module cache described in CAP-0065.
• Manual restoration of archived entries is no longer necessary. Read more in CAP-0062 and CAP-0066.
• Soroban per-ledger CPU capacity can now be increased significantly, thanks to parallel transaction execution described in CAP-0063. The per-ledger read capacity has also been increased significantly, thanks again to CAP-0062 and CAP-0066.
• More useful host functions have been added to Soroban: contract executable getter (CAP-0068) and string/byte conversions (CAP-0069).
• The Stellar Consensus Protocol (SCP) network configuration can now be manipulated by validators, opening the doors for reducing ledger latency. Read more in CAP-0070.

We’ll dig into each of these CAPs a bit more below, and you can always get into the nitty-gritty details on GitHub. Find all relevant information about preparing for the vote in the Protocol 23 Upgrade Guide.

CAP-0062: Soroban Live State Prioritization

CAP-0062 introduces the performance features of full state archival (detailed in CAP-0057, currently in draft form) called live state prioritization. Live state prioritization will separate archived state and live state into two separate databases: the “Live State” BucketList and the “Hot Archive” BucketList.

The Live State BucketList resembles the current BucketList and will contain all live state of the ledger, including Stellar “classic” entries, live Soroban entries, network configuration settings, etc. The Hot Archive BucketList will store archived persistent Soroban entries. Validators will store entries from both databases; no state or entries will be removed from validators at this time.

There are significant benefits to implementing live state prioritization before full state archival, including making the update to CAP-0057 much smoother with a lower likelihood of application breakage.

The implementation of CAP-0062 opens up possibilities for further optimizations, including those introduced in two of our other Protocol 23 CAPs: CAP-0065 and CAP-0066, described below.

CAP-0063: Parallelism-Friendly Transaction Scheduling

This CAP defines a new transaction set structure that allows for the parallel execution of smart contract transactions while maintaining bounded execution time for transaction sets, improving speed and CPU efficiency. It also slightly adjusts the TTL extension and fee refund logic; read more here.

Currently, validators process smart contract transactions one at a time in a given transaction set, using only a single CPU core. This CAP details how validators can run multiple smart contract transactions simultaneously, spreading the work across multiple CPU cores in parallel. Stellar smart contracts were designed for parallelism from the outset (thanks to CAP-0046: Smart Contract Data), but nothing stopped validators from choosing parallel-friendly transaction sets over non-parallel-friendly ones. This CAP addresses that unpredictability by introducing a new protocol-level structure that allows all transaction sets to be parallelized predictably.

CAP-0065: Reusable Module Cache

CAP-0065 introduces a reusable Wasm module cache that allows all deployed and usable Wasm modules to remain parsed, validated, and translated in memory at all times, across all ledgers.

Before a Wasm module can run, it undergoes a few costly steps:

• Parsing: reading the bytecode and converting it into a structured format
• Validation: ensuring the module adheres to required rules (e.g., memory limits, function structure, etc.)
• Translation: converting the Wasm into a format executable by the underlying VM

Currently, Stellar stores the result of this work in a cache for each module on a per-transaction basis, meaning the cache exists only for the duration of a single transaction and is discarded afterwards. Even if the same Wasm module is used repeatedly in a transaction set or block, the network must redo the parsing, validation, and translation process each time.

This design decision was initially made because there was no clear way to attribute and charge fees for maintaining a longer-lived cache. However, with CAP-0062, Soroban introduces a split between in-memory and on-disk ledger state, allowing the Wasm module cache to only track live contracts. As a result, the cost of caching can now be directly tied to the moments when a contract enters memory via the upload or restore actions. User fees will be lower due to the elimination of parsing, validation, and translation costs during transaction execution.

CAP-0066: Soroban In-Memory Read Resource

CAP-0066 introduces in-memory Soroban state, where all live entries are stored in validator memory. This removes disk reads entirely from smart contract invocations, significantly improving throughput and reducing fees. Additionally, this introduces automatic restoration of Soroban entries.

To accomplish this, CAP-0066 introduces a new resource type for Soroban reads that distinguishes between in-memory and disk reads. Thanks to CAP-0062, Soroban's live state can be fully stored in memory, eliminating the need for disk access during contract execution. Since all state is stored in memory, there is also no longer a read bytes limit or read fee for live Soroban state (note that read entry limits still apply). 

There are resource limit and fee changes associated with this CAP; read more about them in GitHub here.

CAP-0066 also introduces automatic restoration of archived Soroban entries via the InvokeHostFunctionOp. Prior to Protocol 23, developers had to explicitly call a restore operation to bring archived state back into use. Now, whenever the InvokeHostFunctionOp is executed, the network automatically checks the footprint and restores any archived entries it needs before contract execution. In most cases, running simulation or preflight will detect expired entries and include them in the footprint. Archived entries being restored are still treated like disk-based data: rent, write, and read fees still apply.

CAP-0067: Unified Asset Events

This proposed CAP allows built-in “classic” operations to emit asset events in the same format as smart contract transaction events, unifying the event stream between smart contract invocations and built-in operations and enabling simpler downstream systems.

The primary changes introduced in this CAP are:

• Stellar Core can now emit events for all Stellar asset movements using the Stellar Asset Contract (SAC) event format, as defined by SEP-0041: Soroban Token Interface. There are a few minor updates to the SEP-0041 specification and the SAC implementation, which you can read about on GitHub.
• This CAP also introduces multiplexed account (M-account) support in Soroban, along with corresponding updates to the SAC to accommodate it. Because Soroban now has support for multiplexing, the use of transaction memos is no longer necessary and therefore prohibited.
• This CAP allows infrastructure operators to retroactively emit events starting from the genesis ledger. Infrastructure providers that retain full history and want full support for stellar asset events (e.g., indexers) will need to reingest all historical data. Read more here.

CAP-0068: Host Function for Getting Executable for `Address`

CAP-0068 proposes a new smart contract host function that retrieves the executable associated with another contract address. Currently, with no way to do this, it is impossible to determine whether a contract is Wasm or built-in (the only built-in contract today is the Stellar Asset Contract (SAC)) and make decisions based on that knowledge.

This CAP enables several important use cases, including:

• Custom accounts can enforce authorization policies tied to trusted contracts.
• Contracts will be able to distinguish between SAC instances and custom tokens on-chain, which helps prevent contract tokens from impersonating the metadata of a SAC, useful for bridges wrapping Stellar tokens on other chains.
• Contracts can pin exact implementations of their dependencies, meaning they can avoid interacting with upgraded or untrusted versions.

CAP-0069: String/Bytes Conversion Host Functions

This CAP proposes two new Soroban host functions that make converting between the string and byte types easier. While strings and bytes are similar under the hood, converting between them today requires complicated and inefficient workarounds, such as linking to allocator libraries that wouldn’t otherwise be needed. Providing the two new host functions (bytes_to_string, which converts a ByteObject to a StringObject, and string_to_bytes, which converts a StringObject to a ByteObject) reduces contract size and complexity.

CAP-0070: Configurable SCP Timing Parameters

Here we are at the last CAP of the day, folks! CAP-0070 introduces ledger configuration settings that let the Stellar network dynamically adjust ledger close times, nomination and ballot timeouts, per-round nomination timeout increments, and per-round ballot timeout increments. This enables controlled, incremental improvements to block time performance to help boost scalability, resilience, and efficiency without disruptive protocol upgrades.

Currently, hardcoded settings restrict performance improvements and prevent the network from gradually testing and adopting shorter block times. With this CAP, those parameters are configurable, allowing small, incremental performance tuning. If Protocol 23 passes and the network is upgraded, there will be no immediate effect on Stellar Consensus Protocol (SCP), but it will open the door for future changes.

Although these aren’t protocol-level changes, Protocol 23 also introduces a few additional updates that developers should be aware of:

• XDR-JSON integer type changes (read more in the GitHub discussion);
• Contract specs will be extended to support events (read more in this GitHub discussion).