-
Notifications
You must be signed in to change notification settings - Fork 2
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
Conversation
There was a problem hiding this 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).
cowamm/profitability/competitor_kpis/curve/curve_kpis_4232873.sql
Outdated
Show resolved
Hide resolved
cowamm/profitability/competitor_kpis/curve/curve_kpis_4232873.sql
Outdated
Show resolved
Hide resolved
cowamm/profitability/competitor_kpis/curve/curve_largest_2token_pools_4232976.sql
Outdated
Show resolved
Hide resolved
coin1 as token1, | ||
mid_fee*power(10,-10) as fee | ||
from curvefi_{{blockchain}}.view_pools | ||
where coin2 = 0x0000000000000000000000000000000000000000), |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
cowamm/profitability/competitor_kpis/pancakeswap/pancakeswap_largest_pools_4232597.sql
Outdated
Show resolved
Hide resolved
cowamm/profitability/competitor_kpis/pancakeswap/pancakeswap_largest_pools_4232597.sql
Outdated
Show resolved
Hide resolved
cowamm/profitability/competitor_kpis/pancakeswap/pancakeswap_largest_pools_4232597.sql
Outdated
Show resolved
Hide resolved
cowamm/profitability/competitor_kpis/pancakeswap/pancakeswap_kpis_4232738.sql
Outdated
Show resolved
Hide resolved
cowamm/profitability/competitor_kpis/pancakeswap/pancakeswap_syncs_4232660.sql
Outdated
Show resolved
Hide resolved
cowamm/profitability/competitor_kpis/sushiswap/sushiswap_kpis_4232588.sql
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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.
cowamm/kpi/competitors/curve/curve_largest_2token_pools_4232976.sql
Outdated
Show resolved
Hide resolved
cowamm/kpi/competitors/uni_swap_style/largest_uni_style_kpis_4304295.sql
Show resolved
Hide resolved
cowamm/kpi/competitors/uni_swap_style/largest_uni_style_syncs_4304212.sql
Outdated
Show resolved
Hide resolved
cowamm/kpi/competitors/uni_swap_style/largest_uni_style_kpis_4304295.sql
Outdated
Show resolved
Hide resolved
cowamm/kpi/competitors/uni_swap_style/largest_uni_style_kpis_4304295.sql
Outdated
Show resolved
Hide resolved
cowamm/kpi/competitors/uni_swap_style/largest_uni_style_syncs_4304212.sql
Outdated
Show resolved
Hide resolved
|
||
select | ||
contract_address, | ||
0.003 as fee, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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%.
There was a problem hiding this 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.
from "query_4232976(blockchain='{{blockchain}}')" as r | ||
inner join "query_4232976(blockchain='{{blockchain}}')" as r1 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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}} )
cowamm/kpi/competitors/curve/curve_largest_2token_pools_4232976.sql
Outdated
Show resolved
Hide resolved
cowamm/kpi/competitors/uni_swap_style/largest_uni_style_pools_4303563.sql
Outdated
Show resolved
Hide resolved
cowamm/kpi/competitors/uni_swap_style/largest_uni_style_kpis_4304295.sql
Outdated
Show resolved
Hide resolved
cowamm/kpi/competitors/uni_swap_style/largest_uni_style_kpis_4304295.sql
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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
sum(amount_usd) as volume, | ||
365 * sum(amount_usd * r.fee / r.tvl) as apr |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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...
Co-authored-by: Felix Leupold <[email protected]>
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.