Introducing Automated Market Makers on Stellar

Stellar connects the world's financial infrastructure by making it easy to issue assets and to use those assets for seamless cross-border and cross-currency payments. Market liquidity, which allows the quick and efficient exchange of assets at stable and transparent prices, is fundamental to the network's success, and like many in the ecosystem, SDF has long understood that fact. To quote our 2021 Roadmap, "[i]mproving liquidity is an essential part of the 2021 growth plan. The ability to efficiently convert assets is what enables varied use cases and actors to interact with one another on Stellar."

Liquid markets require substantial depth (measured in the amount of units available to be bought and sold) at narrow widths (measured by the spread between buy and sell prices), both of which contribute to minimizing slippage (a measure of price impact or "cost" for a conversion). Creating liquid markets that are both deep and tight on a network like Stellar, which is designed to handle massive international payment flows, is a real challenge. There's a lot of bootstrapping to do.

Every asset issued on Stellar starts with zero liquidity. To create and sustain a market, people have to be willing to put capital onto the network, and to use that capital to facilitate asset conversion. Currently, there is only one way to do that — creating orders on the order books — but the desire to improve liquidity to make cross-border payments fast, cheap, and highly usable led to a proposal to enable the creation of automated market makers, or AMMs, on Stellar. Based on what we've seen on other decentralized networks, AMMs have the potential to help the network continue to thrive and grow by making liquidity provision an accessible, simple, and inclusive process.

Since its inception, Stellar has featured a built-in decentralized exchange, or SDEX for short. Protocol-level operations allow users to create orders to buy or sell one Stellar-network asset for another, and those orders are aggregated into order books and prioritized for execution based on price. When buy and sell orders cross, the protocol automatically matches them to execute a trade. Path payments, which are Stellar operations that facilitate cross-border payments by combining asset transfer with asset conversion, are also routed through the order books, so currently, they rely on liquid order books to execute.

The order book model is tried and true, and it's familiar to anyone who has used traditional exchanges to trade forex or cryptocurrencies. But it also presents some liquidity challenges, and those challenges are magnified by the decentralized nature of the network.

In an order book model like the SDEX, liquidity comes from standing orders that users can trade (or, in the case of Stellar, make path payments) against. The majority of those orders are placed by professional market makers, who hold an asset in inventory, and quote both a bid — which is the price at which they are willing to buy more of the asset — and an ask — which is the price at which they are willing to sell the asset. Their goal is to make a profit on the difference between the two, the bid/ask spread.

Because bid/ask spreads in active markets are small, market makers rely on high trading volumes in order to thrive. They also require capital up front to place orders, and they need to update those orders constantly as prices change. They generally use algorithms and trading bots to make minor adjustments to manage risk, and maintaining those algorithms and bots requires expertise, diligence, and dedicated infrastructure. It's a lot to manage, and it's a fairly complicated process.

On Stellar, ledgers close every 5-8 seconds, which is fast for a decentralized exchange, but it's still slower than many traditional exchanges, so there's a risk that the price of an underlying asset could change more quickly than a market maker can update their SDEX orders. Each operation also incurs a network fee, and while per-operation fees are incredibly low, they start to add up if you are updating hundreds of thousands of orders every day.

Market makers weigh these costs and risks against profit potential to decide which asset pairs to support, and generally, they choose pairs that have high trading volumes because those have the highest profit potential. Currently, many key asset pairs on Stellar are attractive enough to garner that support, but as the ecosystem expands, there are a slew of new assets and new markets to bootstrap, each of which presents a whole new challenge. As payment flows increase, the network requires more and more liquidity for those new markets, and while market makers do a great job providing it for certain pairs, it is unlikely that they, on their own, will provide sufficient liquidity to match Stellar's potential.

If and when validators agree to accept it, Protocol 18 will add automated market maker functionality to Stellar, enabling developers to create AMMs that will coexist alongside the SDEX and provide an alternate source of liquidity. With an AMM, buyers and sellers trade against a liquidity pool rather than trading against existing orders others have placed on order books. An AMM uses an underlying formula to value two assets relative to one another, and as trades execute against the pool and alter the amount of each asset it contains, the relative prices shift based on that formula.

Anyone can provide liquidity by depositing into a liquidity pool — on Stellar, it will just take a single operation — and the pool adjusts prices programmatically, so it removes the need to manually update orders to manage risk. When trades execute against a liquidity pool, they incur a small fee, and the pool collects those fees and distributes them to liquidity providers to incentivize deposits. Those incentives — along with the relative ease of participation — have allowed AMMs on other networks to attract large amounts of capital and enable high volumes of trading, effectively crowdsourcing liquidity. Uniswap, for instance, has over $5 billion in Total Value Locked (i.e. capital deposited to provide liquidity), and facilitates billions of dollars worth of Ethereum-network transactions every week.

AMMs on Stellar have the potential to provide easy-to-access liquidity at scale, especially for new markets and markets currently overlooked by market makers. That's because asset issuers will no longer need to rely on market makers to stock order books: they can simply create liquidity pools, and allow individual users to provide liquidity by depositing into them.

The potential for AMMs to improve network liquidity has long been discussed in the Stellar ecosystem, and there have been ideas tossed around about how to introduce them to the protocol for years. As the network has continued to grow, the need for increased liquidity has become more and more apparent. Recently, two different Core Advancement Proposals were drafted — CAP-37 and CAP-38 — each of which took a slightly different approach to implementing AMMs to address that need.

There was a lot of back-and-forth on the Stellar Dev Mailing List and in Open Protocol Meetings about the merits of each, and after assessing both proposals, participating in those discussions, and collecting feedback, the CAP Committee — a group of protocol designers who evaluate proposed changes to the Stellar network — voted to move forward with the simpler proposal: CAP-38.

CAP-38 makes a specific design choice to implement the minimum changes necessary to add AMM functionality to Stellar. If implemented, it will:

• Introduce constant product liquidity pools, so AMMs will rely on simple, Uniswap-like formulas
• Allow liquidity pools to be created between any two assets
• Create new operations so users can deposit into and withdraw from liquidity pools
• Store pool shares, which can be exchanged for a portion of liquidity pool reserves, in depositor trustlines
• Change path payments so they execute against liquidity pools when they provide a better exchange rate than the DEX
• Have a fixed 0.3% fee
  

All of the CAP-38 configuration choices can be revised in subsequent versions of the protocol, and that's the idea: start simple, see how AMMs work on Stellar, gather information about ecosystem needs, and extend functionality and add complexity to address those needs. If the ecosystem requires more complex features, such as the interleaved order execution proposed in CAP-37, those features can be added to the protocol and voted on by validators later.

All network upgrades require validator consent, so ultimately, the network will decide whether to accept or reject the proposal to add AMM functionality to Stellar. But before the network upgrade vote can happen, there's a lot of work left to do.

Over the next few months, the Stellar Core team will take the CAP-38 spec and work to craft it into code, which they will rigorously test before releasing it as Stellar Core v18.0.0 this fall. In parallel, we will work with the ecosystem to ensure Horizon, the Stellar SDKs, and downstream applications including user interfaces are compatible with AMMs.

When Stellar Core v18.0.0 is stable, we will upgrade the testnet so that developers can begin to experiment with sandbox AMMs. About a month after the testnet upgrade, we will coordinate a date and time for validators to vote on the public network upgrade.

If validators vote to accept the new protocol, users will be able to create liquidity pools, which will coexist alongside orders on the books, and path payment operations will begin to compare the two and execute against whichever provides the best rate. We believe that introducing a parallel method for exchange will enable more cheap, fast, highly usable cross-asset payments and democratize market making by giving everyone the ability to participate in liquidity provision. But really, it's up to the ecosystem. What will you do with AMMs?