Protocol 15 Improvements

• Read the CAP
• Read the docs
• See the API Reference
• See an example

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

• Read the CAP
• Read the docs
• See the API Reference
• See an example

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.

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.