Foundation News

Yardstick, Stellar Protocol 26

Author

Stellar Development Foundation

Publishing date

For Protocol 26, the letter Y brings us to Yardstick.

It wasn't a hard choice. A yardstick is what you reach for when approximation stops being good enough. It doesn't speed anything up or make anything louder. It makes things exact. You use it when a line needs to land in precisely the right place, when a measurement needs to be trusted, when the margin for error is zero.

That's the character of this upgrade. Where Whisk was about speed and X-Ray was about new vision, Yardstick is about precision: freezing what needs to be frozen, handling numbers correctly at the edges, and giving developers fine-grained control over things that previously required workarounds or risk tolerance. We'll call it Stellar Yardstick Protocol (26), or Yardstick for short.

Yardstick went live on mainnet on May 6, 2026 following the validator vote. Follow the upgrade guide for the latest on Stellar releases. Here's a quick rundown of the changes:

A governed, onchain incident response (CAP-0077)

CAP-0077: Ability to freeze ledger keys via network configuration. The marquee Yardstick change gets its own name and its own blog post. Read more about Quorum Freeze here. The short version:

As institutions move real capital onchain, the question isn't just whether a network is fast or cheap, it's whether it has a governed response when something goes wrong. Until now, the industry default has been improvisation for emergencies. No major L1 has had a protocol-native answer.

Quorum Freeze changes that for Stellar. It introduces protocol-level configuration settings that let validators maintain a list of frozen ledger keys. When a key is frozen, Stellar Smart Contract transactions that would touch it are rejected; affected classic offers are pulled from the order book. An allow-list of explicitly permitted transactions can bypass the freeze when needed.

What makes this different is the governance model behind it. Stellar's consensus protocol, SCP, is built on federated trust—known, accountable validators with publicly declared trust relationships. A Quorum Freeze is the output of that process: identifiable, observable, and reversible. For regulated institutions, that traceability isn't a nice-to-have. It's the prerequisite for infrastructure they can actually underwrite.

Arithmetic that doesn't just crash (CAP-0082)

CAP-0082: Checked 256-bit integer arithmetic host functions. One of the less glamorous but genuinely important things a financial platform can do is handle edge-case numbers without failing catastrophically. Until now, 256-bit integer arithmetic in Stellar Smart Contract would trap on overflow—aborting the entire transaction when a calculation hit its boundary. Safe in the sense that it doesn't produce wrong results, but brittle: a contract that hits an overflow just dies, with no chance to recover.

CAP-0082 introduces checked variants of the existing 256-bit integer host functions for both unsigned and signed types—add, subtract, multiply, and power. These return the result, or Void if overflow occurred. Contracts can inspect the return value and decide what to do.

For developers writing financial logic—position sizing, fee calculations, anything involving potentially large numbers—this is a real improvement. Libraries can detect overflow and handle it by design, not by crash. The arithmetic stays cheap (it happens at the host level), and contracts become more robust.

Precise TTL control (CAP-0078)

CAP-0078: Host functions for performing limited TTL extensions. Soroban contracts manage the lifetime of their ledger entries through TTL extensions—keeping data alive costs XLM, and contracts handle that through TTL operations. The existing host functions are blunt: there's no way to say “extend by at most one day” or “extend to exactly this target but respect the network maximum.” That ambiguity makes it hard to write equitable rent policies, where each user pays proportionally for the state they use instead of accidentally subsidizing everyone else's long TTLs.

CAP-0078 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.

Additional improvements

CAP-0080: Host functions for efficient ZK BN254 use cases builds on the BN254 work from X-Ray. It 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. If you're building ZK applications on Soroban, this is a direct cost reduction.

CAP-0073: Allow SAC to create G-account balances lets the Stellar Asset Contract create unlimited trustlines for G-accounts directly, mirroring ChangeTrustOp semantics but driven from Soroban. It also updates XLM SAC transfers to auto-create account entries when sending enough XLM to a new G-address. With it, you can use Soroban flows to handle classic onboarding and trustlines natively, which smooths UX, and simplifies app logic when you need to support both C- and G-accounts.

CAP-0079: Host functions for muxed address strkey conversions adds strkey conversion host functions with first-class support for muxed accounts, so contracts can 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.

Why upgrading matters

Incidents happen on live financial networks. The freeze mechanism in Yardstick is the first time Stellar has a consensus-driven, onchain way to respond to one quickly and cleanly. That matters more than it might sound—the difference between a hotfix and a proper quarantine mechanism is the difference between “we patched it” and “the network handled it.”

The rest of the upgrade is less dramatic but just as useful. Checked arithmetic, precise TTL control, and cheaper ZK operations are the kind of improvements that compound—they don't make headlines, but they make Stellar a more reliable place to build serious financial applications.

Check the Upgrade Guide if you haven't yet upgraded. If you want to shape what comes after Yardstick, the conversation is always open on Discord.