Protocol 18, if it is accepted by a quorum of validators, will introduce automated market makers to the Stellar network. It's a big new feature. We've already published posts explaining how automated market makers will work and how the ecosystem moved quickly to support them. While those posts were focused on the future of this feature, this post is going to reminisce about that (not so) long ago time when the vision for automated market makers on Stellar was just beginning to come into focus. My role at SDF is to design and implement changes to the protocol, and the goal of this post is to explore some aspects of the design process. I want you to understand not only what we built, but why we decided to build it this way.Two Proposals, Two Goals
In April 2021, two different draft proposals for automated market makers were published. It was a rare event — there have never been multiple proposals for the same feature drafted at the same time — and it demonstrated a widespread interest in adding AMMs to Stellar. The two proposals differed in a few key ways, and this immediately exposed tension between two competing goals. First, the initial version of automated market makers should be as simple as possible. Second, automated market makers should be deeply integrated into the Stellar protocol.
The simplicity goal sounds, well, simple enough. But simple means different things to different people. From my perspective as an implementer of stellar-core, a simple design is one that is easier to implement and test. From the perspective of people who build on Stellar, however, a simple design is one that is easier to work with. When a design is simple in both of these ways, users benefit by getting access to high quality products quickly. And in an ideal world, there is a design which satisfies both desires. But the real world is often messy.
Consider the following high-level design concept: automated market makers are entirely independent of ...