Comet v1 created a solid foundation for users to engage with a weighted AMM implementation. An efficient set of smart contracts with an example frontend users may easily fork and build on top of was introduced.

Comet v1 also set the stage for enhanced interoperability within the Soroban ecosystem, as our core smart contracts serve as a foundation for many other solutions to integrate/build on top of. This framework enables robust exchange of assets across a dynamic set of liquidity pools.

However, while Comet v1 offers robustness, it lacks fluidity in regards to cost optimization, this impacts end user experience.

Enter Comet v2, a major upgrade that optimizes for low fees via order routing and the implementation of stableswap pools within the weighted pool AMM.

Why router?

A router is a user-friendly way to interact with an AMM, it handles the routing logic for facilitating swap and order execution. Having an efficient router can lower fees for end users significantly.

This is especially important for a weighted pool AMM, as Comet will have a variety of pools with similar tokens of different weights. One pool may have XYZ token with a 20% weight, and another pool may also have XYZ token at a 50% weight. The router will find the most optimal path for swapping from token a to b, with the functionality of being able to route across a multitude of liquidity pools. This allows the user to have access to efficient swap routing without having to worry about using specific pools and thinking heavily about liquidity implications for simply swapping tokens. The router takes weight distribution, liquidity, fees, and efficient path finding into account when facilitating a swap.

Why stableswap?

Stablecoins have become a unique and integral part of capital liquidity throughout many DeFi ecosystems. Stableswap implementations allow for a novel approach to reducing fees and enhancing price stability. Having an efficient stableswap implementation with the Comet weighted pool AMM would also allow for greater real world value within the DeFi ecosystem, as stablecoin issuers and/or protocols can confidently allocate liquidity within a plethora of weighted liquidity pools. Users also gain access to distributed risk profiles across multiple stablecoin pools, with the ability to group various types of stablecoins by weight while still benefiting from the low slippage associated with a stableswap liquidity pool.

Stableswap pools also allow for more dynamic route pathing options within the router implementation.

In conclusion, Comet v2 introduces two major new features, a router and stableswap implementation. Users will have access to lower costs when they provide liquidity to and/or swap stablecoins (lower slippage and impermanent loss), as well as lower fees (efficient routing) via the router implementation.

The net result will mean that regardless of what tokens users choose to swap, they will incur lower fees, and thus will enjoy a much greater end user experience.

Upgraded smart contracts and frontend implementation to adhere to preview 10. Fixed primary breaking changes. Changes include state expiration implementation, upgrading contract code according to latest rs-soroban-sdk changes, and adding typescript binding support for the frontend.

This section will provide an in-depth analysis of the current main use cases for the router and stableswap pools.

Router:

Introducing the Dynamic Order Routing Engine (DORE). DORE, at its essence, is an off-chain linear optimization tool, designed for the Comet protocol. It efficiently routes orders across a myriad of liquidity pools to guarantee optimal price execution. Rather than singularly interacting with one pool, DORE spreads a trade across several pools, thereby reducing fees for users. An optimization approach is used due to being efficient in terms of computation cost and speed of execution.

Features:

Input: Desired amount of a specific token meant for trade.

Output: A list of pools and the respective amounts to engage with, ensuring maximization of the returned tokens.

Liquidity Aggregation: DORE serves as an effective tool to aggregate liquidity across all Comet pools off-chain.

Why DORE?

Optimized Trading:

In a DeFi ecosystem, solely interacting with the most liquid pool isn't necessarily the optimal strategy, often resulting in unrealized potential. DORE ensures trades are intelligently distributed.

Cost Efficiency:

Interacting with multiple liquidity pools has associated costs. DORE evaluates the benefits of trading with a new pool against these costs, ensuring each decision is profitable. This ensures that in environments with elevated transaction fees, DORE may selectively engage with fewer pools, always prioritizing the trader's net gain (lower fees).

How Does DORE Work?

Linearization:

DORE employs linearization to make its calculations more tractable. Recognizing that prices might rise post-trade due to slippage, DORE adopts a linearized function approach to approximate the post-trade spot price of a Comet pool.

(See figure 1)

Identifying Prices of Interest:

With linearization, DORE can interpolate prices and quantities. By pinpointing crucial price points where two pool prices intersect, or where a pool has that exact starting price, DORE refines its routing decisions.

(See figure 2)

Estimated price is the anticipated price after a trade, based on the approximation made via linearization.

Trade Distribution:

Illustratively, if we consider two pools, and trading a particular amount in the first one causes its price to align with the starting price of the second, DORE commences interactions with the second pool for amounts surpassing the initial threshold. This ensures traders consistently receive the best possible price for their trades.

For example, if you're trading an amount less than "A" tokens, it's best to trade solely with pool 1. However, for amounts exceeding "A", it's more efficient to include pool 2, ensuring you don't overpay. For combined trading amounts represented as B+C, the optimal approach involves trading across both pools, balancing their prices to achieve the best trading value. This can be extrapolated into a combination of utilizing a multitude of pools for routing.

(See figure 3)

Stableswap:

Ensuring minimal price impact and capital efficiency is essential. By incorporating stableswap into Comet's liquidity pools, we can significantly enhance the trading experience for assets that maintain a consistent swap ratio or operate at predictable rates.

What Are Stable Pools?

Stable pools leverage stable math (popularized by curve) to enable trades with a substantially reduced price impact, even for large trade sizes. This not only promotes capital efficiency but also provides a smoother trading experience for end users.

Key Features:

• Optimized for Pegged Tokens: Ideal for tokens that consistently swap near a 1:1 ratio, such as major stablecoins (USDC, USDT, DAI) or synthetic assets.
• Tailored for Aligned Tokens: Perfectly suited for tokens that swap near 1:1 but with a slow variation in exchange rate, like certain derivatives (liquid staking tokens such as stETH).

Stableswap is also more efficient at facilitating fiat token markets than standard x*y=k pools or base weighted pools due to how it utilizes liquidity in a more efficient manner. Users do not need to be concerned about massive volatility. This especially makes them a great fit for the Stellar and Soroban ecosystem, due to the prevalence of anchored fiat currencies.

Stable math formulas and implementations will be further discussed in detail within the architecture document.

This protocol will serve as a proof of concept and will not be deployed on Mainnet by the Comet team. Specifically, this proof of concept will be solely deployed to Futurenet, and released as open-source software.

As for plans after we develop a Futurenet proof of concept, there are none for now, but we are in discussion with the Blend team with regards to integrating Comet smart contracts into Blend’s mainnet deployment. 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.

‍

To check whether the first deliverables have been completed, a reviewer can check a notion document link that will be provided. 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 and any off-chain logic, which will give the reviewer a sense of how the project will function.