SNS Liquidity Pools - Design

[aterga]

Hi @HeliosFz

Thanks for waiting, I’m just back from vacation.

In this case, the steps of operations from multiple different deposits may be the same. Is the field identifying which deposit the operation belongs to ‘purpose’, or does it require adding a new field?

Good question.

The purpose field doesn’t really disambiguate different operation instances, as it just provides some context to the human auditor to hint at what this operation was trying to accomplish.

But should be able to disambiguate operations using timestamp_ns, since transactions do not interleave. At least that’s the case in our reference implementation.

We could consider adding another field, e.g., transaction_id. Do you think that would help?

So the deposit method is not simply transferring assets to the treasure manager, but directly recharging assets into DEX, right?

Short answer - yes.

Note that the treasury manager itself doesn’t have access to the treasury tokens, but when an SNS executes a deposit for a treasury manager extension, it ensures that the required assets are available to it. So the treasury manager extension’s deposit function serves as a notification endpoint for telling the extension that it’s now safe to assume that the tokens are made available to it, in which case, they are to be forwarded to the DEX.

I still don’t understand the meaning of fee_collector. Is it just a transfer fee for tokens, or does it need to be paid as a management fee to the treasure manager? What is the charging mechanism?

The treasury manager should not take up any fees for itself. As an extension canister, it should be registered with and controlled by the SNS, and it is thus part of the DAO.

The fee_collector is just the accumulated amount of all ledger fees along the execution of a particular operation, e.g., deposit. Since the low-level ledger transactions are an implementation detail, from the p.o.v. of the SNS, it would not be obvious to the end users how many ledger fees to expect. Taking into account the possibility that a ledger changes its fee mid-operation (unlikely, but still possible), keeping track of these internal fees aids the accounting for a human auditor.

So adding liquidity and other business logic needs to be written as SNS methods, and then registered by the project party into SNS, right?

I’m not 100% sure what you mean by SNS methods. If you refer to custom proposals (a.k.a. generic functions), then the answer is no. Instead, we will offer a new (hopefully, better) mechanism to call extension operations via a new proposal type called ExecuteExtensionOperation. When an extension is registered, its operations should be made available via ExecuteExtensionOperation proposals immediately. In particular, after registering a Treasury Manager extension, SNS users can submit ExecuteExtensionOperation proposals for its deposit and withdraw operations.

Timed refunding means that there will be no fund accumulation in the treasure manager, right?

Exactly.

Is the triggering frequency customized?

Not in the reference implementation we’re working on (we want to keep the configuration as simple as possible, as thus we plan to hard code the periodic task frequency to once an hour.

[jp-dfinity1]

Hi, would be nice if the extension supported a way to get the current token price in USD or ICP from the DEX. Or integrated with the XRC.

[HeliosFz]

Hi @aterga .
Thanks for your answers and hope you have had a happy vacation!

@aterga

We could consider adding another field, e.g., transaction_id. Do you think that would help?

Yes, an additional field could be helpful.

@aterga

Note that the treasury manager itself doesn’t have access to the treasury tokens, but when an SNS executes a deposit for a treasury manager extension, it ensures that the required assets are available to it.

In this case, though the treasury manager does not have access to the token, it still holds the positions which assets in them. This is acceptable, right?

@aterga

SNS users can submit ExecuteExtensionOperation proposals for its deposit and withdraw operations.

So adding & removing liquidity operations should be 2 steps: deposit+ExecuteExtensionOperation_Add, or ExecuteExtensionOperation_Remove + withdraw. Is this right?

@aterga

Not in the reference implementation we’re working on (we want to keep the configuration as simple as possible, as thus we plan to hard code the periodic task frequency to once an hour.

If there is no fund accumulation in treasury manager, why need the timed refunding? For situations like wrong direct transfer or something?

BTW, the examples I have seen so far are all based on Rust. Will there be a Motoko version released in the future, or at least two standards, Motoko and Rust, for the community to implement.

[ShahriarJavidi]

@HeliosFz

Yes, an additional field could be helpful.

Do you know of any use-cases, where having the transaction ID, could potentially help?

@HeliosFz

In this case, though the treasury manager does not have access to the token, it still holds the positions which assets in them. This is acceptable, right?

Indeed. The treasury manager acts as a trusted broker for the SNS DAO. It is the entity that deposits into and withdraws from the DEX. Since the code of the treasury manager must be whitelisted, we consider it trustless.

@HeliosFz

So adding & removing liquidity operations should be 2 steps: deposit+ExecuteExtensionOperation_Add, or ExecuteExtensionOperation_Remove + withdraw. Is this right?

Actually, the extension operation is already embodied in the extension proposal. So, when the proposals is adopted, its execution flow includes a call to the corresponding deposit endpoints of the exchange (e.g., add_pool or add_liquidity in case of kongswap).

@HeliosFz

If there is no fund accumulation in treasury manager, why need the timed refunding? For situations like wrong direct transfer or something?

Third party traders can use liquidity provided by the treasury manager in the pool in exchange for some amount of fee. It implies that

1. balance of the token-pair claimable by the treasury manager changes over time.
2. fee accumulate and can be claimed by the treasury manager.

That’s why we periodically run these background tasks.

@HeliosFz

BTW, the examples I have seen so far are all based on Rust. Will there be a Motoko version released in the future, or at least two standards, Motoko and Rust, for the community to implement.

We still have no plans of adding an official Motoko reference implementation.

[Lorimer]

Is there an estimate for when this API will be ready for use by SNSs? I’ve not been keeping close tabs on this discussion, but I am eagerly awaiting the feature.

[aterga]

Hi @jp-dfinity1

would be nice if the extension supported a way to get the current token price in USD or ICP from the DEX

Great suggestion. For instance, if an SNS has liquidity in multiple DEXs, a frontend could show the SNS token price in each of them. Did you have another use case in mind?

Unfortunately, this won’t be supported in the first API, mainly because we didn’t know yet how and who exactly will consume this data.

[aterga]

@Lorimer

Is there an estimate for when this API will be ready for use by SNSs?

The feature is already code complete (feature flag disabled on mainnet), and the new code is in the security review phase. I’ll try to give an ETA for proposing to toggle the feature flag later this week. Stay tuned!

[jp-dfinity1]

Use cases for price data:

1. SNS could show their own price on their website
2. https://snsgeek.app/ could show prices of all the SNS tokens
3. IC Dashboard show prices for SNS tokens (already in progress, but would be nice to have a more official way to get SNS token price)

Also, I know some SNS have secondary tokens, such as nICP for WTN. I’m curious how those might fit into this extension.

[Lorimer]

That’s great news, thanks.

Something I’m interested in understanding is if the API can be used to assist SNSs in implementing buy back and burn mechanisms. I haven’t had time to take a close look at the API though.

Looking forward to seeing it live.

[bitel911]

I was wondering the same, this could improve the Treasury states we see today, like the Recursive Loop from Sneed

[lixx]

First implement a basic function where a fixed proportion of funds raised through SNS is allocated to the swap pool to increase liquidity. At present, the ecosystem lacks liquidity, and just a few hundred ICP can sustain a market cap of several million, which is incomprehensible. This issue urgently needs to be resolved.

[aterga]

Thanks, everyone, for providing cool suggestions about how to approach this feature. We received even more feedback than anticipated, so while many suggestions are already taken into account, some will have to be postponed till a later refinement of the feature. Overall, I think this discussion indicates how much people care SNS DeFI and, in particular, having a secure and convenient way to add SNS liquidity to the DEXs.

To that end, I’m happy to announce that SNS Liquidity Pools are live, and the new feature has already been successfully used for the 1st time today (to deposit some tokens from the KongSwap SNS treasury into the respective KongSwap DEX’s liquidity pool). We will be publishing a detailed documentation for SNS Liquidity Pools shortly (spoiler: you only need to run 1 command in your shell to make the proposal). Feel free to DM me about this if you can’t wait.