Desmontando o processo de limpeza de dados Uniswap V3

Calculamos o patrimônio líquido do usuário e a taxa de retorno do Uniswap da perspectiva dos endereços dos usuários. Desta vez, nosso objetivo permanece o mesmo, mas incluímos o caixa desses endereços no cálculo para obter o patrimônio líquido total e o rendimento.

Escrito por: Zelos

Introdução

Na última edição, calculamos o patrimônio líquido e a taxa de retorno dos usuários no uniswap sob a perspectiva dos endereços dos usuários. Desta vez, nosso objetivo permanece o mesmo. Mas o dinheiro mantido por esses endereços deve ser contabilizado. Obtenha um patrimônio líquido total e uma taxa de retorno.

Existem dois pools para este objeto estatístico, incluindo

• usdc-weth(taxa:0,05) no polígono, endereço do pool: 0x45dda9cb7c25131df268515131f647d726f50608 [1] , este também é o pool usado na última análise
• ethereum por usdc-eth(taxa:0,05), endereço do pool: 0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640 [2] , como esse pool contém tokens nativos, traz alguns problemas ao processamento de dados.

Os dados finais obtidos são dados de nível horário. Nota: **Os dados de cada linha representam o valor do último momento da hora. **

Processo geral

1. Obtenha dados uniswap
2. Obtenha dados de caixa do usuário
3. Calcule a sequência de preços, que é o preço da eth.
4. Obtenha a taxa de manuseio por minuto e por tick
5. Obtenha a lista de todas as posições dentro do período estatístico
6. Obtenha a relação correspondente entre endereço e posição
7. Calcule a taxa de retorno de cada posição
8. Com base na relação correspondente entre posição e endereço, calcule a taxa de retorno de cada endereço de usuário como LP
9. Combine o dinheiro e o LP do usuário e calcule a taxa geral de retorno

1. Obtenha dados Uniswap

Para fornecer fontes de dados para o demeter, desenvolvemos a ferramenta demeter-fetch. Esta ferramenta pode obter logs do pool Uniswap de diferentes canais e analisá-los em diferentes formatos. As fontes de dados suportadas são:

• ethereum rpc: A interface rpc padrão do cliente eth. A eficiência de obtenção de dados é relativamente baixa. Mais threads precisam ser abertos.
• Google BigQuery: Baixe dados do conjunto de dados do BigQuery. Embora seja atualizado uma vez por dia, é fácil de usar e barato.
• Trueblocks chifra: O serviço Chifra pode coletar transações na cadeia e reorganizá-las. Isso permite exportar facilmente transações, saldos e outras informações. Mas isso requer a construção de seus próprios nós e serviços.

Os formatos de saída incluem:

• minuto: Reamostra as informações da transação de swap uniswap em dados minuto a minuto. Usado para backtesting
• tick: registra todas as transações no Pool, incluindo operações de swap e liquidez

Desta vez, obtemos principalmente dados de ticks, que são usados para contar informações de posição, incluindo valor do fundo/rendimento por minuto/ciclo de vida/detentores, etc.

Esses dados são obtidos através do log de eventos do pool. Como mint, burn, collect. swap. Porém, o log do pool não contém o id do token. Isso nos impossibilita localizar em qual posição está o funcionamento do pool. piscina é para.

Na verdade, os direitos e interesses do uniswap LP são gerenciados por meio de NFT, e o gerenciador desses tokens NFT é o contrato de proxy. O ID do token só existe no log de eventos do proxy. Portanto, se você deseja obter a posição LP completa informações, você deve obter o proxy. O log de eventos é então combinado com o log de eventos do pool.

troque isso [3] Por exemplo, precisamos prestar atenção aos dois logs com índice de log 227 e 229. Eles são mint lançado pelo contrato de pool e IncreaseLiquidity lançado pelo contrato de proxy. O valor (ou seja, liquidez) entre eles, amount0 e amount1 são o mesmo… Isso pode ser usado como base para a correlação. Ao correlacionar esses dois logs, podemos obter o intervalo de ticks, a liquidez, o ID do token e o valor correspondente aos dois tokens desse comportamento LP.

Para usuários avançados, especialmente alguns fundos, eles optarão por ignorar o proxy e operar diretamente o contrato de pool. Neste caso, a posição não terá um ID de token. Neste caso, usaremos o formato de endereço-LowerTick- UpperTick , crie um id para esta posição LP.

Para queimar e coletar, você também pode usar este método para encontrar o ID de posição correspondente para o evento de pool. Mas há um problema aqui. Às vezes, os valores dos dois eventos não são iguais e haverá um ligeiro desvio. Para por exemplo, esta transação

Haverá uma pequena diferença entre o valor 0 e o valor 1. Embora essa situação seja rara, também é muito comum. Portanto, quando combinamos queimar e coletar, deixamos alguma margem para erros nos valores.

A próxima questão a ser tratada é quem iniciou esta transação. Para liquidação, utilizaremos o recibo no evento de cobrança como titular da posição. Para mint, só podemos obter o remetente (ver foto com evento mint).

Se o usuário estiver operando o contrato de pool, o remetente será o provedor de LP, mas se for um usuário comum operando o contrato através de um proxy, o remetente será o endereço do proxy. Isso ocorre porque os fundos são de fato transferidos de o proxy para o pool. Mas a boa notícia é que o proxy gerará token NFT. E esse token NFT será definitivamente transferido para o provedor LP. Portanto, ao detectar a transferência do contrato de proxy (ou seja, o contrato de token NFT) , você pode encontrar o provedor de LP correspondente a esta casa da moeda.

Além disso, se o NFT for transferido, o titular da posição mudará. Fizemos estatísticas sobre isso e essa situação é rara. Para simplificar, não consideramos a transferência de NFT após a cunhagem.

2. Obtenha o dinheiro guardado no endereço

O objetivo desta etapa é obter o número de tokens mantidos por um endereço em cada momento do período estatístico. Para atingir esse objetivo, dois aspectos dos dados precisam ser obtidos,

1. O saldo do endereço no horário de início
2. Transferir registros do endereço durante o período estatístico.

Ao somar e subtrair o saldo utilizando os registros de transferência, pode-se inferir o saldo em cada momento.

O saldo no momento de início pode ser consultado através da interface rpc. Ao usar o nó de conquista, você pode definir a altura nos parâmetros de consulta para obter o saldo a qualquer momento. O saldo do token nativo e do erc20 pode ser obtido desta forma. .

A obtenção de registros de transferência erc20 é relativamente fácil e pode ser obtida através de qualquer canal (big query, rpc, chifra).

Os registros de transferência de eth precisam ser obtidos por meio de transações e rastreamentos. As transações são boas, mas a consulta e o processamento de rastreamentos são muito intensivos em termos computacionais. Felizmente, o chifra fornece a função de exportar o saldo de eth. Um registro pode ser gerado quando o alterações de saldo, embora só possa registrar alterações de quantidade, mas não possa registrar objetos de transferência, mas ainda possa atender aos requisitos.Este é o método de menor custo que atende aos requisitos.

3. Obtenha o preço

Uniswap é uma troca. Se ocorrer uma troca de token, um evento de troca será gerado. Podemos obter o preço do token no campo sqrtPriceX96. Obtenha a liquidez total naquele momento no campo de liquidez.

Como nosso pool tem uma moeda estável, é muito fácil obter o preço de u. Mas esse preço não é absolutamente preciso. Em primeiro lugar, é afetado pela frequência das transações. Se não houver transação de swap, o preço será Além disso, quando o stablecoin não está ancorado, também haverá uma lacuna entre esse preço e o preço para você. Mas, em circunstâncias normais, esse preço é preciso o suficiente e não há problema para a pesquisa de mercado.

Finalmente, o preço do token é reamostrado para obter uma lista de preços por minuto.

Além disso, como o campo de liquidez do evento também contém a liquidez total do pool atual, também adicionamos a liquidez total. Por fim, forma-se uma tabela da seguinte forma:

4. Tratamento de estatísticas de taxas

As taxas de movimentação são a principal fonte de receita da posição. Cada vez que um usuário realiza uma operação de swap no pool, a posição correspondente pode receber uma determinada taxa de movimentação (ou seja, inferior e superior incluem a posição do tick atual). O valor da renda é proporcional à liquidez. O índice, a taxa de pool e a faixa de ticks estão relacionados.

Para contar a receita de taxas do usuário, podemos registrar a quantidade de swap que ocorreu no pool em que tick a cada minuto e, em seguida, calcular a receita de taxas desse tick no minuto atual:

Finalmente, torna-se uma mesa como esta

Este método estatístico não leva em consideração a situação em que a liquidez atual do tick se esgota durante o swap. No entanto, como nosso objetivo estatístico é LP, usamos o intervalo de ticks para estatísticas. Este erro pode ser atenuado até certo ponto.

5. Obtenha lista de posições

Para obter uma lista de posições, você deve primeiro especificar o identificador da posição.

• Para LP investido através de Proxy, cada posição terá um NFT, ou seja, um token id, que poderá ser utilizado como id da posição.
• Para o LP que opera diretamente o investimento em pool, criaremos um ID para ele no formato address_LowerTick_UpperTick. Desta forma, todas as posições possuem seus próprios identificadores.

Através deste identificador, podemos integrar todas as operações do LP para formar uma lista descrevendo todo o ciclo de vida da posição. Por exemplo

No entanto, deve-se notar que o objeto desta estatística é durante o ano de 2023, e não a partir da criação do pool.Inevitavelmente, para algumas posições, não podemos obter suas operações antes de 1º de janeiro de 2023. Isso requer Especulamos quanta liquidez esta posição tem no início das estatísticas. Adotamos uma forma econômica de especular:

1. Adicione a liquidez da hortelã e queime para obter um número L
2. Se L>0, ou seja, mint>burn, considera-se que existe alguma liquidez antes do início das estatísticas, e uma operação mint será compensada no momento em que as estatísticas começarem (2023.1.1 0:0:0 ).
3. Se L<0, considera-se que a liquidez ainda é mantida no final das estatísticas.

Este método pode evitar o download de dados antes de 2023, economizando custos. Porém, enfrentará o problema de liquidez afundada, ou seja: se o LP não realizar nenhuma operação durante este ano, o LP não poderá ser encontrado. Mas esse problema não é sério. Como o período estatístico é de um ano, presumimos que os usuários geralmente ajustarão o LP durante esse período. Porque no período de um ano, o preço da eth mudará muito e os usuários terão muitos motivos para ajustar seu LP . Se o preço ultrapassar a faixa de tick, invista fundos em outro DEFI, etc. Portanto, como usuário ativo, você com certeza ajustará seu LP de acordo com o preço. Para quem deposita fundos no pool e nunca ajusta, consideramos isso usuário seja inativo e não incluído nas estatísticas.

Outra situação mais problemática é que a posição cunhou alguma liquidez antes de 2023 e, em seguida, realizou algumas operações de cunhagem/queima durante o ciclo. No final das estatísticas, toda a liquidez não foi queimada. Portanto, apenas uma parte da liquidez pode Neste caso, a liquidez irrecuperável terá impacto na estimativa de taxas da posição, causando retornos anormais. Os motivos específicos serão discutidos posteriormente.

Nas estatísticas finais, o polígono tem um total de 73.278 posições, enquanto o ethereum tem 21.210 posições.Não há mais de 10 retornos anormais para cada cadeia, provando que esta suposição é credível.

6. Obtenha a relação correspondente entre endereço e posição

Uma vez que o objectivo final das nossas estatísticas é o rendimento do endereço, também necessitamos de obter a relação correspondente entre o endereço e a posição.Através desta associação, podemos obter o comportamento de investimento específico do utilizador.

Na etapa 1, fizemos alguns trabalhos para encontrar os usuários associados da operação do fundo (mint/collect), portanto, desde que encontremos o remetente do mint e o destinatário da cobrança, podemos encontrar a relação correspondente entre posição e endereço .

7. Calcule o valor líquido e a taxa de retorno da posição

Nesta etapa, precisamos calcular o valor líquido de cada posição e, em seguida, calcular a taxa de retorno com base no valor líquido

Patrimônio Líquido

O valor líquido da Posição consiste em duas partes. Uma é a liquidez do LP, que é equivalente ao principal da criação de mercado. Depois que o usuário investir fundos na Posição, o valor da liquidez não mudará, mas o valor líquido flutuará conforme o preço muda. A outra parte Receita de taxas de manuseio, esta parte é independente da liquidez, é armazenada separadamente em dois campos, taxa 0 e taxa 1. O valor líquido das taxas de manuseio aumenta com o tempo.

Portanto, a qualquer minuto, a liquidez é combinada com o preço deste minuto para obter o valor líquido da parte principal.O cálculo da taxa de movimentação requer a utilização da tabela de taxas de movimentação calculada na quarta etapa.

Primeiro, divida a liquidez desta posição pela liquidez total do pool atual como o índice de compartilhamento e, em seguida, adicione as taxas de manuseio de todos os ticks incluídos na faixa de ticks desta posição para obter a receita da taxa de manuseio deste minuto.

Expresso como:

Por fim, adicione as taxas de manuseio de fee0 e fee1 para obter a taxa de manuseio líquida e, em seguida, adicione-a ao valor líquido da liquidez para obter o patrimônio líquido total.

Ao calcular o patrimônio líquido, dividimos o ciclo de vida da posição com base nas transações de cunhagem/queima/cobrança.

1. Quando ocorrem transações mint, deixe a liquidez aumentar
2. Quando ocorre uma transação de queima, reduza a liquidez e converta o valor da liquidez para o campo de taxa (o código do contrato de pool também funciona dessa forma)
3. Quando ocorre uma transação de cobrança, o cálculo será acionado. O intervalo de cálculo vai da última cobrança até o horário atual. Calcularemos o valor líquido e a receita de taxas a cada minuto e obteremos uma lista.

Por fim, resumir a lista de valores líquidos obtidos em cada coleta e, em seguida, realizar a reamostragem e outras estatísticas para obter o resultado final.

Além disso, para melhorar a precisão, fizemos duas otimizações.

Primeiro, para a hora em que ocorreu uma transação (mint/burn/collect), realizamos estatísticas em nível de minuto, e para a hora em que nenhuma transação ocorreu, realizamos estatísticas em nível de hora. Por fim, os resultados foram reamostrados em nível de hora. Estatisticas.

Em segundo lugar, no evento de cobrança, podemos obter a soma da liquidez + taxa de manuseio. Portanto, podemos comparar o valor real de cobrança com nosso valor de cálculo teórico para obter a diferença entre a taxa de manuseio teórica e a taxa de manuseio real (na verdade, esta diferença O valor também inclui a diferença do principal lp, mas o erro da diferença do principal lp é muito pequeno e pode ser basicamente considerado como 0). Compensaremos a diferença da taxa de manuseio para cada linha. Para melhorar a precisão do manuseio estimativa de taxa (também estes são os campos fee_modify0 e fee_modify1 na tabela acima).

Perceber:

1. No preenchimento, a distribuição das taxas de movimentação deve ser ponderada com base na liquidez da hora atual, caso contrário as taxas de movimentação desta hora serão elevadas.
2. Dado que os dados estatísticos são relativos a todo o ano de 2023, e não dados completos, verifica-se o fenómeno de liquidez irrecuperável mencionado na Secção 5. Isto fará com que as taxas de gestão reais sejam muito mais elevadas do que as taxas de gestão teóricas. de retorno tornam-se Anormalmente elevados.

Como cada linha são os dados do último momento desta hora, para a posição que foi totalmente fechada, o valor líquido será 0. Neste caso, o valor líquido no momento do fechamento da posição será perdido. para reter esse valor líquido, é criada uma linha no final do arquivo Os dados no momento de 2038-1-1 00:00:00 armazenam o valor líquido e outros dados no momento do fechamento da posição. necessidades estatísticas de outros projetos.

taxa de retorno

Normalmente, a taxa de retorno é calculada dividindo o patrimônio inicial pelo patrimônio final. Mas isso não se aplica aqui. As razões são as seguintes:

1. A taxa de retorno aqui precisa ser refinada para cada minuto,
2. Como a posição terá entrada e saída de recursos durante o processo, a simples divisão do valor líquido no início e no final não pode refletir o rendimento.

Para a questão 1, podemos dividir o valor líquido por minuto para obter a taxa de retorno por minuto e, em seguida, multiplicar a taxa de retorno por minuto para obter a taxa de retorno total.

Mas esse algoritmo tem um problema sério. Se houver um erro de cálculo de dados na taxa de retorno por minuto, isso levará a um grande desvio na taxa de retorno total. Dessa forma, o processo estatístico se torna uma caminhada na corda bamba, e nenhum erro pode ser cometido, mas é bom que, por um lado, isso não deixe margem para erros estatísticos.

Em relação à questão 2, se houver uma transferência de fundos para dentro e para fora neste minuto, a divisão direta pela taxa de retorno ainda resultará em uma taxa de retorno muito exorbitante.Portanto, é necessário refinar o algoritmo da taxa de retorno por minuto.

Nossa primeira tentativa foi decompor detalhadamente as mudanças no patrimônio líquido e, em seguida, eliminar as mudanças nos fundos. Dividimos as mudanças no patrimônio líquido em várias partes. 1 é a mudança no principal provocada pelo preço. 2 é o acumulado taxas de manuseio deste minuto. 3 é a entrada e saída de fundos. Obviamente, 3 deve ser excluído das estatísticas. Para isso, formulamos o seguinte método de cálculo:

1. Especifique que o minuto atual é n e o minuto anterior é n-1
2. Suponha que todas as operações de transferência no minuto atual ocorram no n:0,000 segundo. Então, no tempo restante, o valor líquido de LP permanece inalterado, ou seja, o valor líquido no n:0,001 segundo é igual ao valor líquido no n:59.999 segundo.
3. O acúmulo de taxas de movimentação ocorre ao final deste minuto, que é o n:59.999 segundo.
4. O preço e taxas de manuseio no final do minuto anterior (n-1:59.999) são os preços e taxas de manuseio no início deste minuto (n:0.000)

Com base nas premissas acima, a taxa de retorno por minuto é dividir a liquidez/preço/taxa de manuseio no final pela liquidez/preço/taxa de manuseio no final, expressa da seguinte forma, onde f se refere à conversão de liquidez em patrimônio líquido algoritmo.

Este método parece muito bom. Ele evita perfeitamente alterações na liquidez e reflete o impacto dos preços e taxas no patrimônio líquido. Isso é exatamente o que esperamos. No entanto, na prática, ocorrerá em algumas linhas Grande rendimento. Após investigação, descobrimos que o problema ocorre ao retirar liquidez. Lembre-se de nossas regras: o tempo representado por cada linha é o final do minuto/hora. Isso fornece uniformidade para as estatísticas da escala de dados, mas deve-se notar que o significado de cada coluna é diferente :

• Para a coluna de valor líquido, é o valor instantâneo, que é o último valor do minuto/hora atual.
• A coluna taxa de manuseio é o valor cumulativo, ou seja, as taxas de manuseio acumuladas durante o minuto/hora atual

Então, para aquela hora de queimar liquidez

*Quando o LP for queimado e o token for transferido, o valor líquido será 0 ao final desta hora *Quanto à taxa de movimentação, por ser cumulativa, ao final desta hora a taxa de movimentação será superior a 0.

Isso reduz a fórmula acima para:

Esta situação não ocorrerá apenas no final do ciclo de vida da posição, mas também quando parte da liquidez for queimada, provocará também uma alteração na relação entre o aumento das taxas de movimentação e o património líquido do LP.

Por uma questão de simplicidade, quando o valor líquido do LP muda, definimos a taxa de retorno para 1. Isso trará erros nos resultados do cálculo da taxa de retorno. Mas para uma posição de investimento contínua normal, a hora de geração da transação é relativo a Todo o ciclo de vida ainda é muito pequeno, portanto o impacto não é significativo.

8. Calcule a receita total de LP do endereço

Com a taxa de retorno de cada posição, mais a relação correspondente entre posição e endereço, podemos obter a taxa de retorno do endereço do usuário em cada posição.

O algoritmo aqui é relativamente simples. As posições deste endereço em diferentes períodos são conectadas em série. Não há período de investimento no meio, o valor líquido é definido como 0 e a taxa de retorno é definida como 1 (porque o valor líquido o valor antes e depois é 0, não há alteração, então a taxa de retorno é 1.)

Se houver múltiplas posições no mesmo período, some os valores líquidos nas partes sobrepostas para obter o valor líquido total. Ao combinar os retornos, ponderaremos a fusão de acordo com o valor líquido de cada posição.

9. Total combinado de retornos em dinheiro e LP

Por fim, desde que o caixa do endereço do usuário e o investimento em LP sejam combinados, o resultado final poderá ser obtido.

A fusão do patrimônio líquido é mais simples do que a etapa anterior (fusão de posições).Contanto que você encontre o intervalo de tempo no patrimônio líquido do LP, procure o dinheiro mantido no intervalo de tempo correspondente e, em seguida, descubra o preço da eth , você pode obter o patrimônio líquido total.

Para a taxa de retorno, também usamos o algoritmo para encontrar a taxa de retorno por minuto e depois multiplicá-la.No início, usamos o algoritmo de taxa de erro de retorno mencionado na Seção 7. Isso requer que a parte fixa deste minuto (incluindo dinheiro) A quantidade de dinheiro, liquidez em LP) e a parte variável (alterações de preços, acumulação de taxas, entradas e saídas de fundos) são separadas. Em comparação com as estatísticas de posição, sua complexidade é muito maior, porque para a entrada e saída de fundos uniswap, basta prestar atenção aos eventos de cunhagem e cobrança. A rastreabilidade do dinheiro é muito problemática. Temos que distinguir se os fundos são transferidos para LP ou transferidos para o exterior. Se for transferido para LP, o principal parte pode permanecer inalterada. Se for transferida para o exterior, para corrigir o valor do principal. Isso requer rastrear o endereço de destino da transferência de erc20 e eth. Este trabalho é muito problemático. Em primeiro lugar, durante mint/collect, a transferência O endereço pode ser um pool ou um proxy. O que é mais complicado é o eth. Para transferências, como eth é um token nativo, alguns registros de transferência só podem ser encontrados por meio de registros de rastreamento. No entanto, a quantidade de dados de rastreamento é muito grande e excede nossas capacidades de processamento.

A gota d’água que fez transbordar o copo foi quando descobrimos que o valor líquido de cada linha é o valor instantâneo desta hora, e a taxa de manuseio é o valor cumulativo desta hora, que não pode ser adicionado diretamente no sentido físico. o problema foi de fato descoberto muito tarde.

Portanto, desistimos desse algoritmo. Em vez disso, usamos o valor líquido do minuto seguinte, dividido pelo valor líquido do minuto anterior. Esse método é muito mais simples. Mas também há um problema com esse método. É quando os fundos são transferidos para dentro e para fora. , a taxa de retorno ainda será irracional. Através da discussão acima, sabemos que é muito difícil separar o fluxo de fundos. Portanto, aqui sacrificamos alguma precisão e definimos a taxa de retorno quando há é uma transferência de fundos para 1.

A questão restante é: como identificar a entrada e saída de fundos na hora atual? O algoritmo que pensei no início era muito simples. Usando o saldo simbólico da hora anterior e o preço atual, podemos calcular o valor líquido desta hora se mantivermos esses tokens. O que será? Em seguida, basta subtrair o valor estimado do valor real. Quando a diferença não é igual ao valor real, significa que há uma transferência de entrada e saída de fundos. A fórmula é expresso como:

No entanto, este algoritmo ignora a complexidade do LP uniswap. No LP, o número de tokens mudará conforme o preço muda, e o valor líquido também mudará de acordo. E este método não leva em conta as mudanças nas taxas de manuseio. Em última análise, o o valor estimado será diferente do valor real. O valor apresenta um erro de cerca de 0,1%.

Para melhorar a precisão, a estrutura dos fundos é refinada, a variação do valor do LP é calculada separadamente e a taxa de gestão também é tida em conta.

Desta forma, o erro do valor estimado pode ser controlado dentro de 0,001%.

Além disso, limitamos o decimal dos dados para evitar a divisão por números muito pequenos (geralmente abaixo de 10^-10). Esses números pequenos são erros acumulados de vários cálculos e reamostras. Se a correlação direta não for processada, a divisão causará o erro seja amplificado, distorcendo gravemente a taxa de retorno.

Outras perguntas

token nativo

Nestas estatísticas, foi adicionado o pool usdc-eth no ethereum, onde eth é um token nativo e requer algum processamento especial.

Eth não pode ser usado em defi e deve ser convertido em weth. Portanto, este pool é na verdade um pool usdc-weth. Para usuários que operam diretamente o pool, basta transferir weth para dentro e para fora deste pool. Isso é o mesmo que um pool comum piscina, é a mesma coisa.

Para usuários que adicionam LP por meio de proxy, eles precisam trazer eth para o valor da transação e transferi-lo para o contrato de proxy. O contrato então converte esses eth em weth e os coloca no pool. Ao coletar, usdc pode ser usado Transfira-o diretamente para o usuário, mas o eth não pode ser transferido diretamente para o usuário. Ele precisa ser transferido primeiro do pool para o proxy, depois convertido em eth pelo contrato de proxy e, finalmente, enviado ao usuário por meio de transferência interna. Para um exemplo, veja esta transação [4] .

Portanto, a única diferença entre o pool usdc-eth e o pool comum é a transferência de entrada e saída de fundos. Isso afeta apenas a posição e o endereço correspondentes. Para resolver esse problema, extraímos todos os dados de transferência NFT da criação do pool e, em seguida, encontre o titular da posição correspondente por meio do ID do token.

posição ausente

Nas estatísticas, alguns cargos não entraram na lista final e esses cargos possuem algumas particularidades.

Uma grande parte delas são transações MEV. MEV são transações de pura arbitragem e não são investidores normais, portanto não estão incluídos em nosso escopo estatístico. Além disso, é difícil contá-los em estatísticas reais, o que requer o uso de nível de rastreamento . dados. Aqui usamos uma estratégia simples para filtrar transações mev, ou seja, o tempo do início ao fim é inferior a um minuto. Na verdade, já que a maior precisão dos nossos dados é de 1 minuto. Se existir uma posição Se o tempo for inferior a um minuto, não pode ser contado.

Outra possibilidade é que não haja transação de cobrança nesta posição. Como pode ser visto no passo 7, nosso cálculo de receita é acionado por cobrança. Sem a operação de cobrança, o valor líquido anterior e a taxa de retorno não serão calculados. Em condições normais circunstâncias Nessa situação, os usuários optarão por colher a receita ou o principal do LP em tempo hábil. No entanto, alguns usuários especiais não são excluídos, ou seja, devem armazenar seus ativos nas taxas 0 e taxas 1 do pool uniswap. Para esses usuários, também os consideramos usuários especiais e não estão incluídos no âmbito estatístico.

Referência

[1] 0x45dda9cb7c25131df268515131f647d726f50608:

[2] 0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640:

[3] Esta transação:

[4] Esta transação: