Create cow_amm_lp_and_tvl_4047078.sql

[olgafetisova]

The query find the relevant cow amm pool, get lp token balance based on the incoming and outgoing ethereum transfers.

Then we use the existing materialized table (result_balancer_cow_amm_base_query_v_2) to calculate TVL for the same pool.

[fleupold]

The file needs to end in .sql for it to be picked up. Also, please make sure formatting is correct (you can look at the other files in the rep). For this you likely need to edit the file in vscode or some other editor.

Also, given that the other folders are mevblocker and cowprotocol, the folder should probably be cowamm

[fleupold]

Can you comment the high level query file (documenting required parameters) and even the subqueries (I think the other files in the repo can serve as an example) so that it's clear what and how this query is doing things?

[fleupold]

This should be a parameter (start date of the analysis)

[olgafetisova]

This is the date when we added the first liquidity to balancer amm.
Ideally, I would start the chart from the first time someone added the liquidity to the pool, but this will add more logic (hence, will be a bit slower).
I can add a parameter as you mentioned.

[fleupold]

Yes, I think users should be able to chose a custom start date (we can set the default to the pool creation in the final visualisation)

[fleupold]

nit: These two seem unused

[fleupold]

Are we sure we want to rely on this materialized view for TVL? Is it updating reliably now (last time I checked it was stuck many days in the past)?

Have you tried using something like

select day, balance
from tokens_ethereum.balances_daily
where address = {{ cow_amm }}
and token_address = {{ token }}
and blockchain = 'ethereum'

to get the TVL?

[olgafetisova]

Yes, I did check that table. It is way heavier and takes longer to compute the values (takes ~4mins to get those values), hence, I was trying to avoid it, but if there is more confidence I can update it. Ultimately it gives the same values.

In the past few days, the table (dune.cowprotocol.result_balancer_cow_amm_base_query_v_2) didn't have any issues, but I did not find a way to check the historical view of the refreshes.

[fleupold]

Makes sense to not use balances_daily if it is too slow. I wonder if we can use a similar approach as for the LP tokens (summing up transfers of token1 and token2 in and out of this pool and multiply it with the price at the end of each day) to get the final balance efficiently without relying on the materialized view.

[fleupold]

What is this? It's the supply delta per day, isn't it? I don't think this is relevant in the final table (I find current name is confusing given there is total_lp which is supposed the be the total_lp_supply).

[fleupold]

This query should also move under version_control. Can you add it in a separate PR please?

[fleupold]

Suggested change

	, get_lp_balance as (
	, lp_balance_delta as (

[fleupold]

As mentioned on the other PR, dividing by 1e18 here causes rounding errors and will make it impossible to get exact results. If this is needed at all it should happen after all summation is done at the end of the query.

[fleupold]

This doesn't work when there is a gap of two days imo (cf. comment on other PR)

[fleupold]

Suggested change

	-- Compute tvl by multiplying each day's closing price with bet transfers in and out of the pool
	-- Compute tvl by multiplying each day's closing price with net transfers in and out of the pool

[fleupold]

Also here, I think basic math should be on raw integer amounts to avoid rounding errors you get from using division and floats.

[fleupold]

It doesn't really make sense to support any blockchain here if the table you query from is erc20_ethereum.evt_transfer (it won't have any records for gnosis).

We can make a PR later to make these queries multi-chain compatible (let's focus on getting mainnet data for now).

[fleupold]

What happens here if a token didn't trade for a day? TVL may have gaps.

[olgafetisova]

addressed that the same way as for the lp supply

[fleupold]

Looks good, but I think there are still two subtle issues with the tvl query that should be fixed before merging.

[fleupold]

This doesn't change anything compared to the logic before (you are still going into floating number before you are summing up all the in and out transfers thus creating imprecision).

Instead, this needs to become (first summing the whole wei amounts and only then dividing by decimals):

Suggested change

	sum(amount * price_close / pow(10, decimals)) as total_tvl
	sum(amount) * price_close / pow(10, decimals) as total_tvl

If you want to see an example of the floating imprecision you can run the two python lines which give different output:

(1/6)+(1/6)+(1/6)+(1/6)+(1/6)+(1/6)
(1+1+1+1+1+1)/6

[olgafetisova]

But this is not going to work in this query as price and decimals vary per token. So it either has to be done per day per token like this:

select day, sum(total_tvl)
from (
select 
        x.day,
        x.contract_address,
        decimals,
        price_close,
        sum(amount) * price_close / pow(10, decimals) as total_tvl

Or aggregated.

[fleupold]

Shouldn't we filter on the token here? Otherwise sending a random token to the USDC/WETH pool would increase its TVL which seems wrong. You can see that this did happen: https://etherscan.io/address/0xb4e16d0168e52d35cacd2c6185b44281ec28c9dc#code

[fleupold]

What happens here if there is more than one AMM per token pair?

[olgafetisova]

That should not be a problem, since we are not selecting a specific pool but rather a token pair, in the next steps we will sum all the tvl and lp supply for all these pools. This is actually the case with the token pair we are testing, so I find it find. Do you see any issues with such approach?

[fleupold]

Yes, I'm pretty sure the math doesn't check out when adding lp tokens across multiple pools, as lp tokens may have a different price per pool.

Take the following example

• pool a has $100 TVL and 100 LP tokens (1LP token = $1)
• pool b has $100 TVL and 10 LP tokens (1LP token = $10)

If we add this up, we would get $200 TVL for 110 LP tokens, making us believe on LP token is worth $1.8

Now let's say $10 are redeemed. Here it matters in which pool they are redeemed because:

• if redeemed in pool a, it will burn 10 LP tokens (leading to $190TVL and 100 LP tokens)
• if redeemed in pool b, it will burn 1LP token (leading to $190TVL and 109 LP tokens)

In each case we would end up with a different view of how much 1 LP token is worth.

So in summary, we need to fix ourselves to a specific pool (likely the biggest, for now I went with the most recently deployed one in the other query I wrote)

[fleupold]

Note that the / and * also need to be inverted here

[fleupold]

I created a helper query in #27 which we can use here instead of total_tvl_prep which should simplify this query quite a bit.

[olgafetisova]

Not sure it it makes sense to keep this complex logic to avoid empty test pools.
The previous query shows the test pools, but it should not affect the result as they are empty.

[fleupold]

What is this query doing (the comment was not updated to reflect the new logic)? It looks quite bizarre. We are taking some count of addresses of one query as a partitioning key in another one to count the token_1 reserve?

I would simply order by created_at (which is a column that was added to 3959044.