Stellar Development Foundation
Since eliminating inflation from the Stellar protocol was first suggested in October of 2018, there’s been a lot of public discussion about the idea. It came up during meetups, was debated in public forums, and led to an in-depth discussion on the stellar-dev google group, which we encourage you to join if you haven’t already.
After listening to what everyone had to say and weighing the pros and cons, here’s what the SDF is asking validators to consider: we think it’s a good idea to disable the current inflation mechanism.
We’ve implemented a change in version 12 of Stellar core that would do just that, and we’re encouraging validators to vote to accept it. We’ll explain how that works below, but first, we’d like to explain why we think it’s the right move. If some of these arguments sound familiar, it’s because we’re paraphrasing things we learned by listening to the Stellar community.
When Stellar was conceived, we envisioned an incentive mechanism whereby account holders would collectively direct inflation-generated lumens toward projects built on Stellar. The thinking was that those lumens would support the development and growth of the ecosystem, which is why inflation was set up as a vote, why you’re able to point your inflation at any Stellar address, and why it requires a minimum amount of community support as reflected by the number of votes to be eligible to receive inflation.
Five years and several million accounts later, it’s clear that inflation doesn’t serve this purpose. Rather than sending inflation to projects building on Stellar, the majority of users join pools in order to claim that inflation for themselves—if they set their inflation destination at all. Every week, the protocol creates new lumens; every week the majority of those lumens go to individual account holders or to SDF accounts.
A few Stellar ecosystem projects receive enough votes to qualify for inflation, but the good people who vote for those projects are essentially opting out of inflation pools. They’re choosing to make a donation. We’re all for that, but it just doesn’t make sense to bake the option to donate into the protocol itself.
Increasingly, inflation is being proportionally split among individual account holders, which means they don’t actually serve any economic purpose. Balances go up in lockstep with the total supply of XLM, so individual increases are offset by an exactly proportional increase everywhere else. Imagine waking up with twice as much money in your bank account only to discover that everyone else did, too, and so everything costs twice as much. Nothing would have changed, really. Inflation, for Stellar, is just redenominating the ecosystem each week.
To grow the network, we need to maximize efficiency, throughput, and scalability, and continuing to churn weekly no-op payments runs counter to that need. Inflation pool payments don’t have much of an operational impact right now, but as Stellar grows and the number of accounts increases, they will start to drag. The more the network grows, the bigger the problem will become.
Recently, OrbitLens from stellar.expert submitted a Core Advancement Proposal to our open-source Github repository outlining a plan to disable inflation. The necessary change is actually incredibly simple: we just modify the inflation operation so that it doesn’t do anything. Instead, it returns an
opNOT_SUPPORTED result code. Some vestigial traces of the mechanism may remain but they won’t have any effect. You’ll still be able to set the inflation destination on your account, for instance, but no inflation will go out. Fees will still go to the fee pool, they’ll just be locked there, inaccessible and unused.
Since the technical execution is so trivial, and since disabling inflation is really a thumbs up/thumbs down issue, we decided to cut to the chase, implement the CAP in a core release, and call a validator vote.
We know we can’t unilaterally decide this change; this is merely our proposal for what we think is best. Stellar validators vote on which version of the protocol the network runs, so ultimately it’s up to them to decide whether or not to accept this inflation-disabling release. After introducing version 12, we need to allow time for everyone in the ecosystem to prepare for the upgrade, so we’ll follow the normal timetable, work with organizations and SDKs to make necessary changes, and deploy to the testnet to check stability. That will take about a month.
During that month, we’re proposing validators arm their nodes to upgrade the network to version 12, and to set the upgrade time to Monday, 10/28 at 1600 UTC. At upgrade time, we’ll convene on the #validators channel on Keybase to await the results, and to see if they decide to upgrade the network, and by so doing, to disable the current inflation mechanism. Whatever the outcome of that vote, the network will move on together. Very exciting.
Disabling inflation is a protocol-level change. It requires a network-wide upgrade to take effect, and network-wide upgrades take time, planning, and coordination. Stellar core developers have to write, vet, and test the code. SDK maintainers have to process pending changes and prepare necessary updates to their software. Apps, exchanges, and businesses that build on Stellar have to ensure their integrations are up to date so they can take advantage of new features and avoid disruptions.
To give the entire ecosystem time to prepare, we schedule network-wide upgrades well in advance, and after October, the next upgrade isn’t scheduled until January. As we mentioned at the top of this post, the debate about inflation has gone on for about a year. At this point, the arguments are in, everyone’s had their say. We’d like validators to vote on the issue now rather than letting it linger until next year. Whatever the outcome, we can all move on together.
If the network decides not to accept the inflation-disabling protocol upgrade, here’s what will happen: we’ll create a new version of the protocol that’s the same as version 12 minus the change to disable inflation, call it version 13, and submit that for a vote. We’ll have to give everyone in the ecosystem time to install version 13, so the subsequent network-upgrade vote won’t happen for several weeks, but the protocol will continue its march forward, no harm, no foul.
There are other important improvements introduced in protocol v12 (such as CAP24 which implements an oft-requested change to path payments), and we’re committed to ensuring those improvements make it out into the world so that people can continue to build bigger and better on Stellar.
The SDF’s mandate is to grow and support the network, and as part of that we provide education and technical assistance to projects building on Stellar. We also offer lumen grants.
In addition to research grants and the Stellar Community Fund, we offer quarterly grants to projects that build and maintain infrastructure vital for the ecosystem to flourish. Those are the exact projects inflation was designed to benefit.
We know this is an issue for many in the community. We also realize more generally we need to improve transparency around past, present, and future lumen distributions. “Increase clarity around SDF’s lumen holdings and distribution plans” is literally on our roadmap, and we still plan to do that before the end of the year. We're considering several specific options for the inflation we've collected, and an answer to this question will be part of the overall disclosure plan. So stay tuned.