Comet is a Soroban implementation of Balancer’s weighted automated market maker protocol. It utilizes an N-dimensional surface-based cost function to enable the creation of arbitrary weight, arbitrary asset count, AMM pools. So instead of being limited to the standard 50/50 seen in classic XYK AMM pools, users could deploy 2-asset pools with asset weights of 80/20 or even 4-asset pools with weights of 10/15/15/60. This increased flexibility allows AMMs to serve a much wider array of use cases for users and projects.

These capabilities, and their effect on ecosystem liquidity, make weighted AMMs a natural fit for the Stellar ecosystem. Stellar has persistent issues maintaining liquidity. There are two main ways to address this. (1) you find more liquidity providers - weighted AMMs help here as they make passive token holders more likely to provide liquidity due to impermanent loss reduction. (2) you make liquidity provisioning more efficient – here, weighted AMMs help by enabling AMM pools with more than two assets, allowing asset pairs to share liquidity.

Comet’s codebase will serve as an important resource for the growth Stellar DeFi ecosystem. Balancer is the second most forked AMM protocol, with many forks expanding on the core technology. Providing a secure Soroban proof-of-concept implementation of the codebase will make it easier for new teams to enter the ecosystem and begin building.

We will get the protocol audited and release a basic user interface for those uncomfortable interacting with the smart contracts directly on Testnet. This protocol will serve as a proof of concept and will not be deployed on Mainnet. Specifically, this proof of concept will be solely deployed to Testnet, and released as open-source software.

As for plans after we develop a Testnet proof of concept, there are none. Comet is designed to be a public good. There will be no DAO or token, just an open-source protocol that any Soroban project can use as a building block.

This section will provide a more in-depth analysis of the current main use cases for weighted AMMs throughout the broader DeFi industry.

Reducing Impermanent Loss:

Impermanent loss is the main deterrent for users who want to provide liquidity for a certain token pair. If you're bullish on XLM, putting your XLM in a liquidity pool is fairly unattractive as, due to the nature of AMMs, you'll be selling XLM as it appreciates - resulting in impermanent loss. For these situations, liquidity pools with weights other than 50/50 make a ton of sense. If XLM appreciated 100%, liquidity providers in an 80/20 XLM/USDC AMM pool would only recognize a 3.27% impermanent loss. In contrast, a liquidity provider in a 50/50 XLM/USDC AMM pool would recognize a 5.7% impermanent loss, roughly 74% more.

This property of 80/20 pools is especially relevant when projects want to give utility to liquidity pools featuring their tokens. Project users who want to hold the token likely want to avoid impermanent loss, as they want to maximize exposure to the project's token. However, that doesn't mean they're inherently opposed to providing liquidity for the token, especially if the protocol has a specific utility for AMM pool shares. In these instances, 80/20 pools are a great compromise. They're used heavily throughout the Ethereum DeFi ecosystem, their usage in the Aave Security module and Balancer governance system being prime examples.

Multi-Token pools:

Because of the math they rely on, traditional XYK AMM protocols can only support two tokens in a pool. Weighted AMMs are able to support an arbitrary number of tokens making them an excellent fit for users and projects that want to share liquidity between more than two tokens. A 25/25/25/25 liquidity pool of four uncorrelated tokenized fiat currencies is an example of an excellent use case for this capability. Rather than each fiat currency having to maintain liquidity against every pair they're traded against, they can focus on maintaining liquidity in one shared liquidity pool.

Other Possibilities:

Due to the properties they inherit from being constant function market makers - weighted liquidity pools have several interesting properties that make them excellent tools for use cases beyond liquidity provision. One example is Indexed Finance using weighted AMMs to create index products.

Traditional index products have a portfolio of different assets and target weights for each asset. As the prices of their holdings fluctuate, they periodically sell and buy assets for the portfolio to return it to the goal weight. This system has a few issues. First, portfolio holding distribution can heavily deviate from goal distribution between rebalancing dates. This means investors often do not have the exposure they were promised - and receive returns that deviate from expectations. Second, on rebalance dates, it's often difficult to get good execution for rebalances if they're large - this leads to the index eating more slippage than necessary, harming investor returns. Finally - it's difficult to build a truly decentralized index product as a centralized manager needs to carry out periodic rebalances. Using a weighted AMM pool as the vault for an index (i.e. instead of being an account holding 33% BTC, 33% ETH, and 33% XLM, the vault is an ETH/BTC/XLM weighted AMM with 33/33/33 weights) solves all of these issues. Weighted liquidity pools constantly maintain their goal exposures because arbitrage opportunities mean traders constantly rebalance them. This mechanism also avoids large rebalances and does not require a centralized entity.

The first important step is designing the architecture. A diligent process will be followed to create the architecture and set up the project structure. Research will be conducted on Balancer and similar protocols in different ecosystems (Solana, Cosmos) to determine important elements such as core contracts, interfaces, and libraries. The end result of this first deliverable will be a summary of the specifications for contracts in pseudocode form, with a focus on the main interactions between contracts.

Architecture & Pseudocode Document: https://reinvented-society-29d.notion.site/Comet-Architecture-Doc-477a48c102cc4f479c2762fa487e6ed7

To check whether the first deliverables have been completed, a reviewer can check the notion link provided above. This document outlines the project's overall structure and key components, such as core contracts, interfaces, and libraries. This document will give the reviewer a clear understanding of the project's design and how different components fit together. The pseudocode component of the document should outline the main contract interactions, which will give the reviewer a sense of how the project will function.