Protocol 11 Improvements

Our recent blog post on Surge Pricing detailed what happens on Stellar when submissions to a ledger exceed network capacity: the network enters surge pricing mode, which uses market dynamics to decide which submissions are included in a ledger. Essentially, submissions that offer a higher fee per operation make it onto the ledger first.

Before Protocol 11, fees were fixed: you submitted the amount you were willing to pay to add your transaction to the ledger, and that was that. You paid the fee you specified, or, if that fee was too low, ran the risk of getting squeezed out by surge pricing.

As a result, users who wanted to ensure their transactions made it onto the ledger chose higher fees than necessary, and developers creating pre-signed transactions and smart contracts had to guess at future fees, and hope that when the time came for those transactions to execute, they hadn’t undershot. In general, the fixed-fee model encouraged people to overpay for their transactions, which honestly goes against the very spirit of Stellar.

After Protocol 11, fixed fees are replaced with a version of a VCG auction. You now choose the maximum fee you’re willing to pay, but you’re actually charged the lowest possible fee. If network activity is light, you’ll pay the absolute minimum. If it’s heavy, you’ll pay up to the amount you specify, but no more. As a result, you can choose the highest fee you’re comfortable with safe in the knowledge that you’ll only pay that fee if required by circumstance.

Surge pricing only kicks in when the Stellar network reaches capacity. Capacity is determined by validators, who vote on ledger limits as part of SCP. Ideally, they set it high enough to allow the network to support an increasing volume of activity but low enough to allow nodes with access to lower-end hardware and slower connectivity to keep up.

Before Protocol 11, striking that balance was nearly impossible: validators voted on the number of transactions per ledger, which, it turns out, is an inexact and highly variable metric. The reason: on Stellar, an operation is a single command that changes the ledger. A payment is an operation, for example, as is a buy offer. A transaction, on the other hand, is a bundle of operations that can contain anywhere from 1 to a defined limit of 100 operations.

A transaction-per-ledger limit contains a wide swath of possible activity, and validators tended to err on the side of caution when setting limits. To prevent the network from drowning, they accounted for the biggest-case scenario where every transaction contains 100 operations, and so historically, they set the transaction/ledger limit at 50. That’s a max of 5,000 operations/ledger. In reality, however, most transactions only contain a single operation, so most of the time, the effective limit was closer to 50 operations/ledger.

After Protocol 11, validators vote on an operations-per-ledger limit. So now, rather than assuming the biggest-case scenario and setting conservative limits, they can throttle network activity with finesse. In fact, five minutes after the vote to upgrade to Protocol 11, validators will convene for a second vote, where they are expected to set the operations/ledger limit to 1000. That’s a lot higher than the current average, and throughput on the network will increase dramatically.

As a result of these two changes:

• Network capacity will generally be higher and more consistent
• Surge pricing will kick in less frequently
• If you’re worried about surge pricing, you can choose a higher-than-average fee to ensure you don’t get squeezed out
• Knowing full well that you won’t be charged that fee unless it’s strictly necessary
• Which means it’s easier and cheaper to get your transaction to the ledger
• Even if you’re writing a smart contract that won’t execute for a few months

In addition to pricing and network throttling improvements, Protocol 11 also introduces a new operation that allows users and financial institutions to express buy offers more intuitively and accurately than before.

Before Protocol 11, there was a single operation for placing an order on Stellar’s decentralized exchange — ManageOffer — and it only expressed an offer in terms of what you were willing to sell in exchange for another asset. That made sense if you were actually selling an asset, but it was pretty convoluted if (in your mind) you were trying to buy an asset. If you wanted to buy EUR with USD, for instance, you had to instead sell USD for EUR, which forced you to think about the transaction upside down.

Beyond being confusing, it also posed a significant problem: when you make an offer, you don’t actually know what the execution price will be. Many financial institutions have obligations to execute customer orders faithfully and accurately, and the ManageOffer operation didn’t always allow them to do that.

After Protocol 11, you can use a new operation called ManageBuyOffer to submit actual buy offers. With it, you can specify the maximum amount of an asset that you are willing to buy, and the amount you’re willing to pay for it. To keep things clear, we’ve also renamed ManageOffer to ManageSellOffer and CreatePassiveOffer to CreatePassiveSellOffer respectively.

Whether you’re placing a buy offer or a sell offer, the units you specify for the price are consistent with typical market usage. So:

• If you offer to buy EUR with USD at $0.90/EUR, the units are expressed in terms of what you are selling, in this case USD.
• If you offer to sell EUR for USD at $1.11/EUR, the units are expressed in terms of what you are buying, again USD.

As a result of this change, the Stellar orderbooks behave just like other major market orderbooks, which makes things a lot easier for pretty much everybody.

Before ideas are ever implemented in Stellar, they go through an arduous review process to make sure that the design of upcoming changes is up to our standards of security, usability, and performance. The changes discussed in this post were introduced in CAP-0005 and CAP-0006. Like all Core Advancement Protocols, those CAPs were originally written as drafts, and then went through our formal process on Github (more details on CAPs and SEPs). If you’re simply curious about upcoming protocol changes, or want to participate more fully in the development of Stellar’s protocol, we encourage you to take a look!

You should also feel free to reach out to us in the stellar.public team on Keybase with any thoughts or feedback you may have, and to ask questions about any of the changes outlined above, or about anything else Stellar-related, on Stellar’s Stack Exchange.