Blog Article

Fast Forwarding Stellar AMMs


Justin Rice

Publishing date



In early November, Stellar validators will vote on the public network upgrade to Protocol 18. If accepted, that upgrade will add a new feature to Stellar — the ability to create Automated Market Makers (AMMs) — and in a previous blog post, we looked at how that feature works and why it's exciting. The short version: AMMs can democratize market making, boost overall network liquidity, and make asset conversion more efficient. This post, however, will not focus on the potential AMMs have to transform Stellar. Rather, it will focus on another remarkable piece of the AMM story: the speed with which the ecosystem moved to implement, integrate, and support them.

Over the past few months, as the teams devoted to Stellar Core and the Horizon API have been heads down implementing Protocol 18, developers across the Stellar ecosystem have been working in parallel to build products and interfaces to allow users to take advantage of AMMs. Many are preparing their launches to coincide with the November upgrade vote, which means that unlike past protocol rollouts, there won't be a delay between network upgrade and feature availability. If Stellar validators vote to accept the upgrade, real-world users will immediately be able to use those products and interfaces to create, deposit into, withdraw from, and trade against liquidity pools.

If you follow Stellar, or any ecosystem-based network or platform, really, you know that kind of simultaneous launch is unusual. How did the ecosystem manage to fast forward AMM development? To answer that question, let's take a look at the usual rollout, and compare it with the accelerated rollout.

The usual rollout

A new Stellar feature has a specific lifecycle. It starts with an initial discussion on the open-participation Stellar Developer Mailing List. It's then drafted into a Core Advancement Proposal (CAP), goes through several rounds of public discussion, iteration, and revision, and, when it's sufficiently baked, it's submitted to the CAP committee for official approval or rejection. If accepted, it's implemented in Stellar Core, and bundled into a major Stellar Core release. (It doesn't actually go live on the public network until validators vote to upgrade to the protocol version that contains it.)

While the Stellar Core implementation is underway, there's parallel work to update the Horizon API and the Stellar SDKs to add support for the feature. Stellar Development Foundation engineering teams collaborate with community SDK maintainers, and everyone involved does their best to make sure all the upstream software comes together just before the testnet upgrade.

The testnet upgrade is a month before the public network upgrade vote, and in the past, that was the first opportunity downstream ecosystem developers had to deploy Horizon and the Stellar SDKs, and to start thinking about integrating the new feature into their products and services. A month isn't a lot of time to design, build, and test an integration, and so the adoption of a new protocol feature usually lagged behind its release.

The accelerated rollout

This time, we wanted to try something different. There was a ton of ecosystem interest and enthusiasm around AMMs, and a general consensus that, for Protocol 18 to realize its potential, users need quality interfaces to interact with liquidity pools on day one. So rather than doing things the usual way, we asked ecosystem developers how we could include them earlier in the process, and shared some first-wave resources based on what they told us — 100% in line with Stellar's open source DNA. Here's what we did:

  • The first week of August, about two months before the scheduled release of Stellar Core, we published a spec detailing the planned Horizon API changes. Access to the API contract allowed devs to see what was coming, to build their own wireframes, and to provide feedback to the Horizon team.
  • The second week of August, we shared a mock API environment that allowed devs to test against that spec, and to continue to provide feedback based on their experiences.
  • The second week of September, we set up a Futurenet, a full-fledged Protocol 18 testing environment. It runs release candidates of Stellar Core and Horizon, so it's not stable like the testnet, but it gives first-wave developers a few extra weeks in a testing environment
  • We also prioritized completing documentation in advance to allow early developers to better understand how liquidity pools will work on Stellar, and we will continue to add docs over the coming weeks.

Throughout the process, we solicited feedback from the ecosystem, and used it to fine-tune Horizon and SDK implementations. So in addition to helping support the accelerated development of ecosystem products and interfaces, we also got valuable information that allowed us to better serve developers building on Stellar. It seems like openly incorporating the broader ecosystem earlier turned out to be a good thing for everyone involved.

At this point, while several ecosystem-built products and services are poised for a November launch, none have officially announced their intentions. So I won't name them here. Not yet. In the coming weeks, however, we'll make sure to highlight some key release information as it becomes available, and to keep you up to date as the Protocol 18 story unfolds.

Generally, we anticipate that end users will be able to access liquidity pools using new interfaces along with well-known wallets, exchanges, and delegated signing services, and that developers who want to work on their own AMM integrations will have access to ecosystem-built APIs that aggregate key data — in addition to all the endpoints Horizon exposes. It's a great time to be building on Stellar, and it's exciting to see so many people work together to fast forward AMM development.

What's next?

As of today, the Futurenet is still up, and we are on track for Protocol 18 Stellar Core, Horizon, and Stellar SDK releases in the coming days. In a little over a week, the testnet will upgrade, and we plan to schedule the vote to upgrade the public network for early November. Between now and then, we will continue to work with ecosystem developers to make sure they can access the tools they need to build and launch their products and interfaces, and we will continue to release more info about Protocol 18 and Stellar AMMs — both from SDF’s development teams and some of the companies in our ecosystem who have been on this journey with us. But in many ways, that's just the beginning.

If the Protocol 18 upgrade goes through — and users begin to access ecosystem-built products and interfaces to create and trade against liquidity pools — SDF, and the ecosystem as a whole, will see how they work, and how people use them. As we pointed out in the previous blog post, the current protocol implementation relied on specific design choices that introduced the minimum viable version of AMMs on Stellar, but if and when there are new needs in the ecosystem, we can work together to adapt the technology to meet them. This AMM development process to-date has been a shining example of how our entire ecosystem can work together, anchored around Stellar's guiding open source principles, to further Stellar network development and sets a new bar on our collective collaboration.