SNS Liquidity Pools - Design

Developers SNS Framework
, ,
1

:droplet::pool_8_ball: SNS Liquidity Pools

TL;DR

We propose to implement a Liquidity Pool Extension for SNSs that allows allocating some SNS treasury tokens in a DEX to support exchanging SNS tokens (for existing and new SNSs).

We’re looking for feedback on the high-level design.

Background

Participants of an SNS launch should be able to use decentralized exchanges (DEXs) to exchange liquid SNS tokens obtained after a successful swap. Currently, this requires a lot of manual work for each DEX: registering the new tokens, the desired exchange pair (e.g., SNS:ICP), and adding tokens to the corresponding liquidity pool (a pair of DEX-controlled accounts used to support instant exchanges).

Even then, it is not practically possible to exchange tokens freely until a substantial amount of liquidity is added. This requires either a large number of liquidity providers or multiple SNS treasury transfers to the liquidity pool; either way, the process is slow and requires some sort of off-chain coordination. As a result, many SNSs currently do not have a realistic and fair way to exchange their tokens, even months after the launch. This makes swap participation less attractive.

Currently, SNS DAOs mitigate the problem by using a combination of treasury transfer proposals and custom functions that are specific to each individual DEX. However, keeping track of multiple proposals to achieve a single goal (i.e., allocate part of the treasury funds in a liquidity pool) is complicated for the voters, and is thus error prone. Currently, SNSs cannot easily withdraw their tokens from liquidity pools.

An additional complication stems from the lack of a common DEX standard; each DEX on ICP has its own custom interface. On the one hand, this makes it challenging to support arbitrary DEXs in the SNS framework. On the other hand, there are different DEXs on ICP, so tailoring the SNS to work with just one DEX is insufficient.

Overview

The SNS Liquidity Pools feature will enable SNS DAOs to allocate some part of the treasury tokens into liquidity pools on specific DEXs. The liquidity will support a more stable and efficient market for the SNS ecosystem.

Key Components

Screenshot 2025-06-12 at 12.02.50
Screenshot 2025-06-12 at 12.02.501638×790 59.2 KB

At the core of the design is a new class of canisters that can directly integrate with SNSs to manage parts of the treasury, called the Liquidity Pool Extension (one for each supported DEX). This canister is deployed and controlled solely by the SNS, with its code being open source and thoroughly audited (we will list the exact technical requirements in the next iteration if we go forward with this design).

While all Liquidity Pool Extension canisters encapsulate DEX-specific code, they integrate into the SNS framework via the same simple API. This has the advantage that all proposals for allocating treasury funds into liquidity pools are the same, no matter the DEX they interact with, making it a lot easier for SNS users to understand and vote on them.

This design avoids tailoring the SNS framework to a fixed set of DEXs. Any DEXs, including existing and future ones, can provide its own Liquidity Pool Extension canister. DFINITY will build the first proof of concept, but subsequent Liquidity Pool Extensions can be built either by the DEX developers or any other party, so long as they meet the technical requirements and are approved by the NNS.

The Liquidity Pool Extension provides the following key functionality:

  • Deposits: An SNS can deposit some SNS and ICP tokens from its treasury into a DEX. For existing SNSs, this will require a critical proposal, while for a new SNS, its initial DEX deposit could be specified in the CreateSNS proposal. Each supported DEX will require its own Liquidity Pool Extension canister.
  • Observability: The Liquidity Pool Extension provides an audit trail API for clients to check their SNS’s balances and to perform audits based on all ledger transactions involved in managing SNS assets.
  • Efficiency: The Liquidity Pool Extension will automatically send all unused tokens back to the SNS treasury.
  • Withdrawals: An SNS can fully withdraw all remaining tokens from its DEX allocation via a critical proposal.

Benefits

The SNS Liquidity Pools feature will bring several benefits:

  • Increased Liquidity: Ensuring smoother token exchanging and price stability.
  • Simpler user flow: One proposal per DEX allocation; zero additional proposals for new SNSs to specify DEX allocations.
  • Better security: Transparent treasury management with a fully on-chain audit trail.
  • Transparency: Improved visibility for SNS owned assets, e.g., to indicate DAO health.

Next Steps

  • Prototype the Liquidity Pool Extension and refine the design.
  • Share the resulting prototype and detailed design with the community.
  • Extend the SNS API to support registering Liquidity Pool Extensions.

We’re committed to building a robust and user-friendly SNS Liquidity Pools feature that will benefit the entire ecosystem, including the SNS communities and DEXs. Please share your feedback on this high-level design to facilitate the discussion.

10 Likes
2

Yes, this is brilliant. Will have a more in-depth read later.

The critical part is that the CreateSNS call has the initial liquidity parameters. The aim here is to stop situations like ICPex, Fomo, Estate, FuelEV, where the tokens are artificially withheld from dexes to make it impossible to compete with the dev team.

This discrepancy in tokens is made even worse by gaming the age bonus so that by the time you’ve managed to get a decent stake, the initial dev neuron stake has grown (Alice for instance.)

4 Likes
3

Nice!This is a great approach, especially if the liquidity ratio can be determined at the early stage of SNS creation.

4

When will the feature go live?

5

Would it be possible to extend this to any ICRC-1 tokens? Such that a DAO could have a pair between their governance token and USDC, or their governance token and nICP.

1 Like
6

The critical part is that the CreateSNS call has the initial liquidity parameters …

… the liquidity ratio can be determined at the early stage of SNS creation

Indeed; I think good UX and and security are very much aligned in this case.

When will the feature go live?

The timeline is not yet fully defined, but this feature is a high priority for the Governance team right now, and we’re going to share the ETAs very soon. Stay tuned!

Would it be possible to extend this to any ICRC-1 tokens? Such that a DAO could have a pair between their governance token and USDC, or their governance token and nICP.

Great question; as you know, the SNS currently doesn’t officially support such tokens (apart from its native token and ICP), but we know there’s demand for it, and we’re looking into how to best support them. I don’t know yet whether this will be part of the first SNS Liquidity Pools feature, or maybe a follow-up.

I will say though, that the API we’re designing for the Liquidity Pool Extension canister is going to support arbitrary tokens in the ICP ecosystem (most likely, we will require the ICRC-1,2,3 standards).

More details will follow.

3 Likes
7

Dear @aterga and DFINITY Team

Thanks so much for all your great work!

After several rounds of discussion, it’s clear that implementing the SNS Liquidity Pool Extension via proxy canisters is the most suitable and scalable approach.

We fully support this initiative, as it streamlines the liquidity provision process and significantly improves the trading environment for SNS tokens.

Three quick questions:

  1. Will each SNS DAO need to create and manage its own dedicated Liquidity Pool Extension canister, including monitoring and topping it up with cycles?

  2. Once liquidity is added via the Liquidity Pool Extension, is it managed directly by the extension canister, or does control remain with the SNS DAO’s Governance Canister?

  3. If an SNS DAO later wants to adjust its liquidity settings, can it flexibly do so via the extension canister?

Thanks a lot!

1 Like
8

Sounds fantastic! I’m very much looking forward to seeing this sort of thing.

Given that these canisters will be about streamlining (and to some extent standardising) SNS integration with DEXs, it would be absolutely wonderful if you would consider making it easy for an SNS to establish an automated buy-back-and-burn mechanism via these canisters (helping to abstract away dex-specific details).

This would make it easy to launch SNSs with deflationary governance tokens, potentially facilitating SNSs to configure higher staking rewards (improving SNS governance incentives).

In an example setup, an SNS could stake part of the ICP recieved from the decentralisation swap in an NNS neuron. Maturity from that neuron could feed perpetual buying and burning of the SNS governance token. This is of course already possible, but making it easy to be DEX-agnostic would be great!

1 Like
9

Surely cICP would be a better choice due to the superior design.

3 Likes
11

@aterga

We express our strong support for the proposed SNS Liquidity Pool Extension.

It is evident that many SNS projects face a common challenge: even after launch and token distribution, a lack of standardized and streamlined liquidity provisioning mechanisms often results in SNS tokens remaining illiquid for extended periods. We believe this proposal is well thought out, balancing security, scalability, and maintainability.

As a core DEX infrastructure provider in the Internet Computer ecosystem, ICPEx fully embraces the direction of this proposal and is willing to collaborate with the Foundation and other DEX development teams to jointly advance the development of liquidity pool extension canister standards, SDK testing, and cross-DEX integration.

Meanwhile, we have completed the new architecture for ICPEx, supporting 2-second high-speed trading, multi-path routing, and MCP services. The platform’s core code has also been open-sourced and is available for public access:

https://next.icpex.org

If there is any related working group or discussion forum organized by the Foundation, we would be eager to join and contribute to the standardization of liquidity mechanisms within the SNS protocol.

12

Can’t imagine how it will work yet in detail, but it sounds great. I guess the main benefit here is the observability.
It will need to allow different types of liquidity provision inside one extension, if a DEX has multiple algorithms for that. I guess also, the configuration of existing positions, for example, moving a range.
I suppose in the future, part of the ICP from an SNS swap will go directly into a liquidity pool instead of treasury, and it will require a critical proposal to remove it.

13

Long needed feature - there should never be a situation where an SNS Swap completes & the end user has to wait to see if the DAO will come to consensus & prioritize liquidity provision.