SCF #12
Award Completed

Comet is a weighted AMM protocol that offers soroban projects a flexible solution set when picking liquidity venues

Budget request:

Project Stage




Based in

Team size


Active since

Products & Services

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.

No items found.
Previous Project(s)
No items found.
Progress so far
To get there, we request a budget of  
Additional information

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.

Pitch deck
No items found.
First Deliverable

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.

Reviewer instructions

Architecture & Pseudocode Document:

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.



Kevin, Tempest, and Iggy are members of Squad, which is a curated collective of the best engineers in Web3. Squad is a community-owned marketplace that enables top independent tech builders to team up to work on Web3 missions.

Kevin Huo (kwhuo68#9196)

Smart Contract Engineer (Solidy & Rust)

- ex-Protocol Engineer at Sei Labs; early engineer supporting the chain’s development in preparation for mainnet launch
- ex-Protocol Engineer at Syndicate Protocol; early smart contract dev building no-code infrastructure to allow users to launch their own Investment DAO
- Before Web3, Kevin was a Machine Learning Engineer at Facebook and at a Hedge Fund

Github / LinkedIn

Sartaj Sandhu (prism#8821)

Backend & Smart Contract Engineer (Rust)

- 3x winner of the Solana Riptide Hackathon
- Built one of the first DeFi lending protocols on Solana and developed unit tests to improve error recognition before launch (using Mocha, Anchor, Javascript)
- He has also integrated REST API with deployed Solana programs, launched an algorithmic market-making bot, and built a user login authentication service for Solana.

Iggy (iggy gl#0929)

Coordination / Logistics

- Founder of Squad, a talent collective for the best independent Web3 engineers
- Previously worked at Bain (Private Equity & Strategy Consulting), Google (Data Analytics), and in a few other aerospace engineering roles
- Active contributor at Developer DAO, Krause House, Chainforest and Safary DAO

- Iggy wont be involved in the day-to-day of the product development but will support with some logistical coordination

Twitter / LinkedIn

Our team is set up for success because:

  • Comprehensive expertise in all crucial areas, including experience in building smart contract infrastructure on EVM, Solana, and Cosmos-based chains, and proficiency in Solidity & Rust.
  • Background in DeFi and previous founder experience in the field.
  • Strong working relationship, having collaborated previously.
  • We are all members of Squad. A Web3 talent collective that gives us the advantage of quick access to experts with specialized knowledge and the ability to expand our team with additional talented members as needed. In this case, we plan to engage with front-end devs and UI/UX designers as needed for the later stages of the project.