Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Competitor AMMs KPIs #61

Merged
merged 25 commits into from
Nov 27, 2024
Merged

Competitor AMMs KPIs #61

merged 25 commits into from
Nov 27, 2024

Conversation

PoloX2021
Copy link
Contributor

This PR measures TVL, 24H Volume and 24H APR for 4 existing AMMs (Uniswap, Sushiswap, Pancakeswap and curve)
The 24H APR is defined as sum(volume*feePct/TVL)*365 over the past 24H.

Uni, Sushi and Pancake are based on the same code. The queries are very similar to one another with only differences in the tables to look into.
For each, there is one first query which looks at the reserves of each pool, to find the largest ones.
Then the query sync comes from previous code and kpis is a modified version of the 10k comparison to measure only the 24H APR.

For Curve, there are less tables available and information in the events. So, we calculate the reserves based on all transfers of the 2 tokens involved in the pools.
The trades are dervived from a dedicated dune table.
There might be one issue with ETH transfer which seems to impact only one pool with appears to have a negative TVL.

@harisang harisang changed the title Comptetitor AMMs KPIs Competitor AMMs KPIs Nov 8, 2024
Copy link
Contributor

@fleupold fleupold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please run sqlfluff fix to make sure the sql is formatted nicely (this makes it easier for me to review). Also, I'd personally prefer smaller PRs (e.g. one per project) as then I can review them 1 by 1 in 20 minutes each (rather than having to block 1h for the whole PR, which at least for me happens less frequently).

As for the structure, the /cowamm currently contains two folders (kip and profitability). Inside profitibality, we now add competitor_kpis. I find this confusing.

Can we either create /cowamm/competitors/kpi or /comamm/kpi/competitors?

More comments (mainly about semantic inconsistencies inline).

coin1 as token1,
mid_fee*power(10,-10) as fee
from curvefi_{{blockchain}}.view_pools
where coin2 = 0x0000000000000000000000000000000000000000),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed? Intuitively this looks to me as if this is an invalid pool (with coin2 being the 0 address). Could you add a comment in code please?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curve can have multi-tokens pools, which would not make sense to compare with CoW AMM for now

Copy link
Contributor

@fleupold fleupold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking very good. Would like to see a way to distinguish between different uni v2 like protocols though as this is very likely something the UI wants to display.


select
contract_address,
0.003 as fee,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fee is hardcoded to 0.003 here, but some pools might have different fee values, don't they?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comment! Pancake Swap is only .25%
For Sushi and Uni swap it is harcoded to .3%.

Copy link
Contributor

@fleupold fleupold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very close. I just don't understand the self join in the curve query. The rest are nits.

Comment on lines 12 to 13
from "query_4232976(blockchain='{{blockchain}}')" as r
inner join "query_4232976(blockchain='{{blockchain}}')" as r1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this self join needed? Can you please document it in the code.

and r.tx_hash = t.tx_hash
where
t.block_time >= date_add('day', -1, (case when '{{end_time}}' = '2024-01-01' then now() else timestamp '{{end_time}}' end))
and r1.latest = 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4232976 already filters for latest = 1 doesn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it might feel confusing in the last part of the code: it filters by latest_per_pool only to find the largest pools, then it includes all of the tvls after every event which happened

select * from recent_tvl where contract_address in ( select contract_address from recent_tvl where latest_per_pool = 1 order by tvl desc limit {{number_of_pools}} )

Copy link
Contributor

@fleupold fleupold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👏 Looks great, only nits remaining

cowamm/kpi/competitors/all_competitors_4335231.sql Outdated Show resolved Hide resolved
cowamm/kpi/competitors/all_competitors_4335231.sql Outdated Show resolved Hide resolved
Comment on lines 10 to 11
sum(amount_usd) as volume,
365 * sum(amount_usd * r.fee / r.tvl) as apr
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation, I get it now. Just as a comment (not actionable assuming performance of the join isn't an issue), but this could also be computed using a "rolling sum" which would avoid the self join.

Something like

select
    contract_address,
    fee,
    tvl,
    sum(amount_usd) over (partition by contract_address order by latest_per_pool) as volume,
    365 * sum(amount_usd * fee / tvl) over (partition by contract_address order by latest_per_pool) as apr

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is indeed a performance issue overall for all queries. So I implemented it. Result: it divides by 2 the execution time

Comment on lines +59 to +60
sum(transfer0) over (partition by contract_address order by block_time, evt_index) as reserve0,
sum(transfer1) over (partition by contract_address order by block_time, evt_index) as reserve1,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the performance of the query and the fact that we are already joining with prices for sell and buy token here, I wonder if we wouldn't dramatically speed up this query by also computing the amount_usd per tx_hash here instead of computing it in the other query.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it would speed up or not, because we would have to look for the transaction events and not simply the transfers


--Curve
select
contract_address,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

surprised you don't need the token addresses as well here (would make sense imo)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sasha was happy with all the columns in the table...

@PoloX2021 PoloX2021 merged commit 7b60835 into main Nov 27, 2024
1 check passed
@PoloX2021 PoloX2021 deleted the comptetitor-APRs branch November 27, 2024 13:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants