Blog Article

Protocol 15 Improvements


Justin Rice

Publishing date

Protocol upgrade

On Monday, 11/23/2020 at 1600 UTC, Stellar validators will vote on whether to upgrade the network to Protocol 15. To avoid headaches and disruption, anyone building on Stellar should prepare for that vote to go through by installing up-to-date versions of any and all Stellar-related software they use.
We're skipping the Protocol 14 upgrade — originally planned for 10/28/2020 — because we discovered an issue during continued testing and rolled out a fix. Out of an abundance of caution, we opted to release that fix as Protocol 15 rather than as a patched version of Protocol 14 in order to ensure that all validators are running an up-to-date version of Stellar Core when the public network upgrades. For more info, see the Guide to Protocol 15 Prep.

Stellar is designed to connect the world's financial infrastructure, and Protocol 15 introduces two new features — Claimable Balances and Sponsored Reserves — that make it easier than ever to do that. The Protocol 15 features have been over a year in the making, and they address some of the biggest pain points developers experience when building user-facing apps and services on Stellar. This post explains what those features are and why they're important. It also links to relevant resources so you can figure out how to implement them and integrate them into your product.

TL;DR: combined with Fee Bumps, which were introduced in Protocol 13, Claimable Balances and Sponsored Reserves allow apps and services built on Stellar to appeal to a much broader audience. That's because post-Protocol 15:

  • When you launch a product on Stellar, you won't have to start by educating users about lumens and trustlines
  • Anchors will be able to onboard users without sending them to third-party crypto exchanges
  • Apps will be able to move everything crypto-related to the background.

After the upgrade, developers can create simpler, better user experiences that abstract away the complexity of blockchain, and do it without losing any of the advantages of a fast, cheap, and permissionless public ledger.

Read on for the details.

Claimable Balances

What they are

Protocol 15 introduces a new ledger entry called a Claimable Balance, which can be used to split a payment into two separate parts: the creation of a balance, and the claiming of a balance. An account can now send an asset independent of the state of the receiving account by creating a Claimable Balance entry, and that entry can be claimed asynchronously by the designated claimant when their account is ready.

Why they matter

Stellar is designed to connect the world's financial infrastructure by making it easy for regulated financial institutions to set up anchor services, which are the on/off ramps for the network. Anchors accept deposits of fiat currencies (such as USD, EUR, and NGN) via existing rails, and send a user the equivalent digital tokens representing those deposits on the Stellar network.

By default, all Stellar accounts can hold lumens (XLM), the native network currency, but before holding any other asset, an account has to create a trustline to it, which is a ledger entry that explicitly opts in to accepting a balance of the asset and adds 0.5 XLM to the account's reserve. Before Claimable Balances, trustlines were a major source of onboarding friction.

When a user deposited fiat currency with an anchor, the anchor had to wait for the user to add a trustline before crediting the user's Stellar account with the equivalent digital asset. That required a lot of complicated back-and-forth between anchors and wallets, and anchors were often left in an awkward in-between state: they held the user's fiat deposit, but couldn't credit the user's Stellar account with the corresponding tokens.

It also meant users had to find an onramp to an onramp: they needed lumens to cover minimum reserve requirements and a trustline, and generally they had to buy them from a third-party crypto exchange, at which point, why involve the anchor service at all? It was a complicated process that required a lot of explanation, and it tended to confuse or annoy users, or to scare them away entirely.

Starting with Protocol 15, anchors can accept an off-network user deposit and immediately create an equivalent on-network Claimable Balance that the user can collect in their own time. If they really want to make onboarding easy, anchors can also take advantage of the second new Protocol 15 feature to cover users' trustline reserve requirements...

Sponsored Reserves

What they are

Protocol 15 introduces new operations that allow one account to sponsor the lumen reserves for another without giving over control of the underlying funds. It also adds new extensions to account entries and ledger entries to record pertinent information about sponsorships.

Anything that increases an account's minimum balance can be sponsored: the initial account requirement, offers, trustlines, account data, and signers.

Why they matter

Stellar requires small transaction fees and minimum account balances, both of which are paid in lumens, the native network currency. Neither enriches anyone — fees are burned, so they don't go to network validators or to the Stellar Development Foundation; minimum balances are held in reserve, and can be reclaimed by the account that covers them — but they're necessary to prevent large-scale bad behavior and to allow Stellar to continue to function as a fast, efficient, and decentralized system for payments

Lumen requirements are modest — a few is more than enough for most accounts — but prior to the features introduced in Protocols 13 and 15, they made it tricky to build user-friendly non-custodial apps and services on Stellar. Each account had to hold requisite lumens as part of its balance, and when you were designing a user onboarding experience, that left you with two sub-par options: either you helped users understand, acquire, and manage lumens, or you covered fees and reserves by sending lumens directly to user accounts. The first required you to educate consumers about crypto as part of onboarding; the second left you susceptible to farming attacks (malicious users could sign up for an account, wait for the minimum balance to arrive, and then merge the account to collect the reserve).

Fee Bumps, introduced in Protocol 13, allow an account to cover another account's transaction fees without giving over control of the underlying funds. Sponsored Reserves allow an account to cover another account's reserves without giving over control of the underlying funds. Together, they make it easy to build an app or service that handles lumen requirements on behalf of users, and to do it without inviting farming attacks. You can now build something on Stellar that doesn't require your users to know anything about crypto, which makes it easy to appeal to a much wider world of users.

Easier onboarding, for example

One way to picture how the new features work together: before Fee Bumps, Claimable Balances, and Sponsored Reserves, an app onboarding a new user faced some pretty difficult challenges. Typically, a wallet would explain the need for XLM, instruct a user to find a third-party exchange serving their jurisdiction to buy some, walk them through how to transfer that XLM to their wallet account, and go to great pains to help them understand how to maintain sufficient reserves to cover things like trustlines and offers. Each of those steps was pretty confusing for the non-crypto literate, so a lot of users would bail before ever really engaging with the app.

After Protocol 15, a wallet can offer in-app deposits via a Stellar anchor, who can accept a user's funds in their local currency and immediately create a Claimable Balance. The wallet can then cover lumen reserves and transaction fees on behalf of a user, so the user can start using the app pretty much immediately without knowing anything about blockchain or cryptocurrency. The user experience is seamless, and makes sense to crypto-enthusiast and the non-crypto literate alike.