Foundation news
Author
Stellar Development Foundation
Publishing date
This guide is designed to help businesses and developers prepare for Yardstick, Protocol 26, with key dates, release information, a changelog, and more.
Stay up to date on any and all Yardstick-related announcements on the Stellar Developer Discord, where the ecosystem coordinates and shares information about the upgrade.
If you use a Stellar SDK
For your Testnet integration, upgrade to the latest version of the relevant Stellar SDK before April 16, 2026. For your Mainnet integration, upgrade to the latest version of relevant Stellar SDKs before May 6, 2026.
If you run Stellar infrastructure (Stellar Core, Horizon, RPC, Galexie)
Install Protocol 26 releases after they are available April 8, 2026. If you use Docker images, pull the Protocol 26 builds from the Docker registry. If you build from source or our Debian packages, make sure to also update your stellar-core, stellar-horizon, and stellar-rpc binaries to the Protocol 26 builds.
Ubuntu
By April 8, 2026, we will publish images for Ubuntu 24.04 and Ubuntu 22.04. To build from source you can refer to the Installation Instructions for installation steps. Package-based installation is also described in the Stellar documentation.
Docker
By April 8, 2026, we will publish the Stellar Core Docker images for Protocol 26, and the Docker-based installation is also described in the Stellar documentation.
If you run a validator
The Protocol 26 upgrade vote is scheduled for May 6, 2026. You should arm your validator with the following command:
upgrades?mode=set&upgradetime=2026-05-06T17:00:00Z&protocolversion=26
Below are up-to-date links to all available releases relevant to Protocol 26. These releases should be available by April 8, 2026. In general, please make sure to check release notes for specific instructions and requirements, and unless otherwise indicated, opt for the “Latest Release.”
Stellar infrastructure
SDKs
To stay up to date on any and all Yardstick-related announcements, join the Stellar Developer Discord, where the ecosystem coordinates and shares information about the upgrade in the #protocol-next channel.
The following is a brief summary of what’s included in Protocol 26.
Introduces protocol-level configuration settings that let validators, through consensus, maintain a list of frozen ledger keys. When a key is frozen, Soroban transactions that would touch it are rejected, and affected classic offers are pulled from the order book. An allow-list of explicitly permitted transactions can bypass the freeze when needed. This is a direct response to incidents and gives the network a consensus-driven, onchain tool to quarantine compromised entries without improvising.
Adds checked variants of 256-bit integer host functions (for both unsigned and signed types: add, subtract, multiply, and power) that return Void on overflow rather than trapping. Contracts can inspect the return value and handle overflow by design instead of crashing. Useful for financial logic involving large numbers.
Introduces v2 TTL host functions with explicit extend_to, min_extension, and max_extension parameters. The host enforces network TTL limits and clamps or rejects extensions accordingly. Contracts can now tick state forward in precise increments, proportional to actual use, enabling equitable rent policies.
Builds on the BN254 work from X-Ray (Protocol 25). Adds nine new Soroban host functions: BN254 multi-scalar multiplication, scalar-field arithmetic (add, subtract, multiply, power, inverse), and curve-membership checks for both BLS12-381 and BN254 points. These move heavy ZK arithmetic into the host layer, making NoirLang proof verification significantly cheaper than Wasm-side implementations.
Lets the Stellar Asset Contract create unlimited trustlines for G-accounts directly, mirroring ChangeTrustOp semantics but driven from Soroban. Also updates XLM SAC transfers to auto-create account entries when sending enough XLM to a new G-address, reducing the need to mix classic operations into Soroban flows.
Adds strkey conversion host functions with first-class support for muxed accounts, allowing contracts to convert between G…/M…/C… strkeys and Address/MuxedAddress objects natively. Cross-chain protocols that already speak strkeys can work with muxed accounts without writing custom encoding logic.