Rename the first Swap pool UI column and add tool tip

[prayagd]

Context

Currently, the few columns of the Swap pool UI are not very clear, this ticket is to update them in a way that it is simpler to understand for the majority of DeFi / AMM users with knowledge of 2-asset pool AMMs.

Requirement

• Rename the first column of the swap UI to "Asset"
• Add a tooltip next to "Pool liabilities" and "Reserves" titles
• Tool tip message for Pool liabilities - Amount of liquidity provided initially by LPs
• Tool tip message for Reserves - Amount of tokens in the pool

Note

• This is both for the Pendulum and Foucoco deployment

[prayagd]

Hey team! Please add your planning poker estimate with Zenhub @ebma @Sharqiewicz

[ebma]

Instead of showing name's of the asset, show tickers of the assets for ex. instead of Stellar BRL show BRL.s

A note for the implementation of this. Instead of showing the value of the 'name' field, we should then instead show the 'symbol' field. For the current set of deployed contracts this means that 'Mock BRL' will show as 'BRL'. @prayagd if you want this to say 'BRL.s' instead, we would need to redeploy the contracts on Foucoco yet again.

[prayagd]

Please add your planning poker estimate with Zenhub @TorstenStueber

[TorstenStueber]

@prayagd it is not correct to rename "Pool liabilities" to "Deposits". What even is a deposit? The number of LP tokens in circulation or the number of pool tokens deposited into the pool. The latter is the "reserves".

If you intend to express the number of LP tokens in circulation: That isn't the "total liabilities" either, instead it is the "total supply", a different value managed by the pool. Total liabilities and total supply are similar but will deviate further and further over time.

[prayagd]

@TorstenStueber Fair point, should we instead add tooltips to these titles? so the end user understands this term.
What is the definition Pool liabilites? as i consider Reserves to be Number of tokens in the pool.

[TorstenStueber]

Pool liability is a mathematical term defined in Nabla, it is Nabla specific. Pool liabilities are mostly used to calculate the slippage by comparing the liabilities against the reserves (i.e., the amount of tokens in the pool).

We might just not expose this number to the end user and leave it to Nabla as an internal accounting mechanism.

[prayagd]

We might just not expose this number to the end user and leave it to Nabla as an internal accounting mechanism.

didnt get you, currently the pool liabilites are shown on the UI

[ebma]

IIUC @TorstenStueber suggested removing the pool liabilities item from the table. Removing the whole column and not replacing it with anything else.

[prayagd]

Sorry but i dont get the why, attached is the screenshot of Nabla live version with liabilites and also new parameter i.e caps. As per my understanding this is an extra data point for arbitragers to know how skewed the pool is currently. Let me know if i understand it wrong

[ebma]

Okay but didn't you put the requirement into the ticket that you want to change away from that? The ticket says we should 'Rename the "Pool liabilities" column to "Deposits"'. As @TorstenStueber pointed out, this renaming would make it inaccurate as liabilities don't equate to deposits. So we either leave it the way it is or remove the column.

[prayagd]

You are right, so i suggest we add tooltips to Pool liabilites. So the user knows what it exactly it is. I will change the ticket description.

[vadaynujra]

@TorstenStueber @ebma does the updated requirement make sense? Or would we still be saying something inaccurate to the user (tooltip)?

[TorstenStueber]

So my reasoning is as follows: even for me it would be hard to understand what these numbers mean, an I defined them in the first place when I specified Nabla.

Maybe they make sense for arbitrageurs but I would not even know how they get their knowledge about how these numbers work. The only documentation that comes close to explaining it is our blog post (not even the official Nabla docs go into details). Neither the spec that defines it in all detail nor the source code is publicly available currently.

If we want to indicate anything more meaningful why don't we just display the a) coverate ratio and b) the current amount of pool tokens (which is strictly not the "reserve" but the "reserve + slippage")?

[prayagd]

The only documentation that comes close to explaining it is our blog post (not even the official Nabla docs go into details). Neither the spec that defines it in all detail nor the source code is publicly available currently

We are working on getting the first version of the docs ready for Forex AMM

If we want to indicate anything more meaningful why don't we just display the a) coverate ratio and b) the current amount of pool tokens (which is strictly not the "reserve" but the "reserve + slippage")?

Personally don't think we should share CR as it is technical for the end user and would also clutter the table there, but curious to know why do you think this information would be helfpul.

[TorstenStueber]

@prayagd This was just a response to your sentence:

As per my understanding this is an extra data point for arbitragers to know how skewed the pool is currently.

So how does an arbitrageur understand how skewed the pool is if it is not clear what "liability" means? If we really want to indicate the skewness, then the CR is the exact parameter that express this. CR = 100% => balanced: CR < 100% => skewed to one side (incentive to fill the pool), CR > 100% => skewed to the other side (incentive to empty the pool).

Anyway, we can also just show the liability and the reserves (without slippage) as you propose. At the end CR = liability/reserve and they could calculate the CR themselves. We need to educate our users either way about what liability or what CR means.

[vadaynujra]

@TorstenStueber could you suggest a short but more accurate description of both Liabilities and Reserves in the context of Nabla? Maybe on the lines of Total liquidity provisioned and Current liquidity available? I can already imagine my suggestion for Reserves is not accurate.

@prayagd any reasoning for adding 'Pool' only for liabilities and not for reserves? Since both are pool-related terms, we should either add the word to both or neither. I would go with neither.

Also, let's include showing the pool caps / limits as this would be very relevant information for the user. I'd suggest keeping it in the same column as Liabilities (see screenshot) in this way 'Liabilities / Cap' because it's quite closely related to the liabilities i.e. the LP can go up to the cap, whereas the reserves can be lesser or more than both - liabilities and caps.

[TorstenStueber]

There is no simple way to explain what liability. It is an internally used accounting mechanism to determine the current slippage. See my comment here. It is something like provided liquidity plus accumulated fees and partly altered by accumulated slippage.

Reserves is the amount of "usable" pool tokens (usable for swap outs). It is less than the actual tokens in the pool (the pool balance) but the rest of the tokens are not available for swaps. So this is a very meaningful term to the end user.

The term liability is probably only useful to the end user to indicate whether the pool is unbalanced to a certain side. Liability < reserve => you will get a reward for swapping into the pool and bringing it back to equilibrium. Liability > reserve => you will get a reward for swapping out of the pool and bringing it back to equilibrium. This can likewise be expressed by showing the coverage ratio.

[vadaynujra]

partly altered by accumulated slippage.

Could you try explaining this a bit more? I am trying to asset why the definition - Total liquidity provisioned - is wrong. If there is only one LPer on pool A with 100 units, and then there is fees accrued due to many swap and result in the amount becoming 102 units, and then this LPer comes and takes all their liquidity, then my understanding is that they would get the whole 102 units (with 0 remaining), and not 100 units (with 2 remaining). If that's the case, then it doesn't seem wrong to define it as the total liquidity provided (because once the provided liquidity has been removed, this value becomes 0). I see why defining it as Initial Liquidity Provided might be incorrect, but the former is fine isn't it?

Could my logic be applied to the definition of Reserves (Current liquidity available) as well, in that it might not be complete, but at least not accurate?

[TorstenStueber]

Yes, that's a way to characterize it: if the pool is perfectly balanced (CR = 100%), then the "total liability" is the amount of pool tokens all liquidity providers together are eligible to withdraw (if they all together redeem all their LP tokens).

If the pool is not balanced (either CR < 100% or CR > 100%), then this amount is less, i.e., adjusted for slippage.

So, to keep it simple: for perfectly balanced pools: "total liability = amount of pool tokens available for withdrawals".

But this definition is almost tautologic: "perfectly balanced" means that "total liability = reserve" and I already wrote above that "reserve = usable pool tokens". So in this sense: usable for swaps or usable for liquidity providers to withdraw.

[prayagd]

@TorstenStueber @vadaynujra i think so we are going in circles
I suggest we remove tool tips for both Liabilities and Reserves and keep it as is and focus on documenting the various scenarios when liability is less than and greater than reserve.
wdyt?

[TorstenStueber]

@prayagd can you give a reasoning for the advantage for keeping the notion "liability" instead of, e.g., CR.

[prayagd]

@prayagd can you give a reasoning for the advantage for keeping the notion "liability" instead of, e.g., CR.

Two reasons

• Assuming we would need to introduce more calculations on the UI to show that right? and i think its the same if we keep Liability we would document different scenarios and if we show CR we would still have to document what happens at various CR's or when CR drop below 100, goes above 100 and stays 100
• Just because Nabla is showing it 😅🙈

[TorstenStueber]

Just because Nabla is showing it

I thought that this is the reason. I reached out to them whether they had any particular reasoning behind this.

[TorstenStueber]

@vadaynujra to continue the conversation here. The pool cap is only relevant for deposits. For that reason I would just show it when someone wants to make a swap pool deposit instead of showing it in the table.

[vadaynujra]

@TorstenStueber In that case the depositor would need to click the Deposit button, and then be told that they cannot because of some limit being reached. On the table it saves them that click and also provides context about how liabilities can only go as high as the cap / limit. Probably why the Nabla team also did it like that. I also checked Hydration which is another single sided liq DEX (and so also has limits on pools), and they also show it one step before the user clicks the button to add liquidity (in screenshot - Add and Join Farms).

[TorstenStueber]

@vadaynujra Liabilities are not limited by the cap.

The cap measures is a cap on the pool tokens when doing deposits. Liabilities are a different unit, particularly with accumulated fees.

[vadaynujra]

I've asked the Nabla team why they did it like this. Let's make a decision after.