Kami menghitung kekayaan bersih pengguna dan tingkat pengembalian di Uniswap dari perspektif alamat pengguna. Kali ini, tujuan kami tetap sama, namun kami memasukkan kepemilikan tunai dari alamat-alamat ini dalam perhitungan untuk mendapatkan total kekayaan bersih dan hasil.
Ditulis oleh: Zelos
Perkenalan
Pada edisi terakhir, kami menghitung kekayaan bersih dan tingkat pengembalian pengguna di uniswap dari perspektif alamat pengguna. Kali ini, tujuan kami tetap sama. Namun uang tunai yang disimpan di alamat-alamat ini harus dihitung. Dapatkan total kekayaan bersih dan tingkat pengembalian.
Ada dua kumpulan untuk objek statistik ini, termasuk
usdc-weth (biaya: 0,05) pada poligon, alamat kumpulan: 0x45dda9cb7c25131df268515131f647d726f50608 [1] , ini juga merupakan kumpulan yang digunakan dalam analisis terakhir
ethereum 上的 usdc-eth (biaya: 0,05), alamat kumpulan: 0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640 [2] , karena kumpulan ini berisi token asli, hal ini menimbulkan beberapa masalah pada pemrosesan data.
Data akhir yang diperoleh adalah data level per jam Catatan: **Data pada setiap baris mewakili nilai pada saat terakhir pada jam tersebut. **
Proses keseluruhan
Dapatkan data uniswap
Dapatkan data kas pengguna
Hitung urutan harga yaitu harga eth.
Dapatkan biaya penanganan per menit dan per tick
Dapatkan daftar semua posisi dalam periode statistik
Dapatkan hubungan yang sesuai antara alamat dan jabatan
Hitung tingkat pengembalian setiap posisi
Berdasarkan hubungan yang sesuai antara posisi dan alamat, hitung tingkat pengembalian setiap alamat pengguna sebagai LP
Gabungkan uang tunai dan LP pengguna, dan hitung tingkat pengembalian keseluruhan
1. Dapatkan data Uniswap
Untuk menyediakan sumber data bagi demeter, kami mengembangkan alat demeter-fetch. Alat ini dapat memperoleh log kumpulan Uniswap dari saluran berbeda dan menguraikannya ke dalam format berbeda. Sumber data yang didukung adalah:
ethereum rpc: Antarmuka rpc standar klien eth. Efisiensi memperoleh data relatif rendah. Lebih banyak thread perlu dibuka.
Google BigQuery: Mengunduh data dari kumpulan data BigQuery. Meskipun diperbarui sekali sehari, namun mudah digunakan dan murah.
Trueblocks chifra: Layanan Chifra dapat mengikis transaksi pada rantai dan mengaturnya kembali. Hal ini memungkinkan Anda mengekspor transaksi, saldo, dan informasi lainnya dengan mudah. Namun hal ini memerlukan pembuatan node dan layanan Anda sendiri.
Format keluaran meliputi:
menit: Contoh ulang informasi transaksi swap uniswap menjadi data menit demi menit, digunakan untuk backtesting
tick: mencatat setiap transaksi di Pool, termasuk operasi swap dan likuiditas
Kali ini kami terutama memperoleh data tick, yang digunakan untuk menghitung informasi posisi, termasuk jumlah dana/pendapatan per menit/siklus hidup/pemegang, dll.
Data ini diperoleh melalui event log pool. Seperti mint, burn, collector. swap. Namun, log pool tidak berisi id token. Hal ini membuat kami tidak dapat menemukan di mana posisi pengoperasian pool. kolam renang untuk.
Faktanya, hak dan kepentingan LP uniswap dikelola melalui nft, dan pengelola token nft ini adalah kontrak proxy. Id token hanya ada di log peristiwa proxy. Oleh karena itu, jika Anda ingin mendapatkan posisi LP yang lengkap informasi, Anda harus mendapatkan proxy. Log peristiwa kemudian digabungkan dengan log peristiwa kumpulan.
perdagangan ini [3] Sebagai contoh, kita perlu memperhatikan dua log dengan indeks log 227 dan 229. Mereka adalah mint yang dilemparkan oleh kontrak kumpulan dan Peningkatan Likuiditas yang dilemparkan oleh kontrak proksi. Jumlah (yaitu, likuiditas) di antara keduanya, jumlah0 dan jumlah1 adalah sama. . Ini dapat digunakan sebagai dasar untuk korelasi. Dengan mengkorelasikan kedua log ini, kita bisa mendapatkan rentang tick, likuiditas, id token, dan jumlah yang sesuai dengan dua token dari perilaku LP ini.
Untuk pengguna tingkat lanjut, terutama dana tertentu, mereka akan memilih untuk melewati proxy dan langsung mengoperasikan kontrak kumpulan. Dalam hal ini, posisi tidak akan memiliki id token. Dalam hal ini, kami akan menggunakan format alamat-LowerTick- UpperTick , buat id untuk posisi LP ini.
Untuk burn dan collection anda juga bisa menggunakan cara ini untuk mencari id posisi yang sesuai untuk event pool. Namun ada kendala disini. Terkadang jumlah kedua event tersebut tidak sama dan akan terjadi sedikit penyimpangan. Misalnya misalnya transaksi ini
Akan ada perbedaan kecil antara jumlah0 dan jumlah1. Meskipun situasi ini jarang terjadi, hal ini juga sangat umum. Jadi ketika kita mencocokkan bakar dan kumpulkan, kita menyisakan ruang untuk kesalahan dalam nilai.
Pertanyaan selanjutnya yang harus ditangani adalah siapa yang memulai transaksi ini. Untuk likuidasi, kami akan menggunakan kwitansi di acara pengumpulan sebagai pemegang posisi. Untuk mint, kami hanya bisa mendapatkan pengirimnya (Lihat gambar dengan acara mint).
Jika pengguna mengoperasikan kontrak pool maka pengirim akan menjadi penyedia LP, namun jika pengguna biasa mengoperasikan kontrak melalui proxy maka pengirim akan menjadi alamat proxy, hal ini dikarenakan dana memang ditransfer dari proxy ke pool. Tapi kabar baiknya adalah Proxy akan menghasilkan token nft. Dan token nft ini pasti akan ditransfer ke penyedia LP. Oleh karena itu, dengan mendeteksi transfer kontrak proxy (yaitu kontrak token nft) , Anda dapat menemukan penyedia LP yang sesuai dengan mint ini.
Selain itu, jika nft ditransfer, pemegang posisi akan berubah. Kami telah membuat statistik mengenai hal ini, dan situasi ini jarang terjadi. Untuk menyederhanakan, kami tidak mempertimbangkan transfer nft setelah mint.
2. Dapatkan uang tunai yang disimpan berdasarkan alamat
Tujuan dari tahap ini adalah untuk mendapatkan jumlah token yang dimiliki oleh suatu alamat pada setiap saat selama periode statistik. Untuk mencapai tujuan ini, perlu diperoleh dua aspek data,
Saldo alamat pada waktu mulai
Mentransfer catatan alamat selama periode statistik.
Dengan menjumlahkan dan mengurangi saldo menggunakan catatan transfer, saldo setiap saat dapat disimpulkan.
Saldo pada waktu mulai dapat ditanyakan melalui antarmuka rpc. Saat menggunakan node pencapaian, Anda dapat mengatur ketinggian parameter kueri untuk mendapatkan saldo kapan saja. Saldo token asli dan erc20 dapat diperoleh dengan cara ini. .
Mendapatkan catatan transfer erc20 relatif mudah dan dapat diperoleh melalui saluran apa pun (big query, rpc, chifra).
Catatan transfer eth perlu diperoleh melalui transaksi dan pelacakan. Transaksinya oke, tetapi kueri dan pemrosesan jejak sangat intensif secara komputasi. Untungnya, chifra menyediakan fungsi mengekspor saldo eth. Catatan dapat dihasilkan ketika perubahan saldo, walaupun hanya dapat mencatat perubahan kuantitas, tetapi tidak dapat mencatat objek perpindahan, namun tetap dapat memenuhi persyaratan.Ini adalah metode berbiaya terendah yang memenuhi persyaratan.
3. Dapatkan harga
Uniswap adalah sebuah pertukaran, jika terjadi pertukaran token maka akan dihasilkan event swap. Kita bisa mendapatkan harga token dari kolom sqrtPriceX96. Dapatkan total likuiditas pada saat itu dari kolom likuiditas.
Karena pool kami memiliki mata uang yang stabil, sangat mudah untuk mendapatkan harga u. Namun harga ini tidak sepenuhnya akurat. Pertama-tama, hal ini dipengaruhi oleh frekuensi transaksi. Jika tidak ada transaksi swap, harganya akan berubah. lag. Selain itu, ketika stablecoin tidak terikat, juga akan ada kesenjangan antara harga ini dan harga untuk Anda. Namun dalam keadaan normal, harga ini cukup akurat, dan tidak ada masalah untuk riset pasar.
Terakhir, harga token diambil sampelnya kembali untuk mendapatkan daftar harga per menit.
Selain itu, karena bidang likuiditas peristiwa juga berisi total likuiditas dari kumpulan saat ini, kami juga menambahkan total likuiditas. Akhirnya, sebuah tabel dibentuk sebagai berikut:
4. Statistik biaya penanganan
Biaya penanganan adalah sumber pendapatan utama untuk suatu posisi. Setiap kali pengguna melakukan operasi swap di pool, posisi terkait dapat menerima biaya penanganan tertentu (yaitu, bawah dan atas termasuk posisi tick saat ini). pendapatan sebanding dengan likuiditas.Rasio, tingkat biaya kumpulan, dan rentang tick saling terkait.
Untuk menghitung pendapatan biaya pengguna, kita dapat mencatat jumlah swap yang terjadi di pool yang dicentang setiap menitnya, lalu menghitung pendapatan biaya pada tick ini di menit saat ini:
Akhirnya menjadi tabel seperti ini
Metode statistik ini tidak memperhitungkan situasi ketika likuiditas tick saat ini habis selama swap. Namun, karena tujuan statistik kami adalah LP, kami menggunakan rentang tick untuk statistik. Kesalahan ini dapat diatasi sampai batas tertentu.
5. Dapatkan daftar posisi
Untuk mendapatkan daftar jabatan, Anda harus menentukan pengenal jabatan terlebih dahulu.
Untuk LP yang diinvestasikan melalui Proxy, setiap posisi akan memiliki nft, yaitu token id, yang dapat digunakan sebagai id posisi.
Bagi LP yang langsung mengoperasikan pool investment, kami akan membuatkan ID untuknya dengan format address_LowerTick_UpperTick. Dengan cara ini, semua posisi memiliki ID masing-masing.
Melalui pengidentifikasi ini, kita dapat mengintegrasikan seluruh operasi LP untuk membentuk daftar yang menggambarkan seluruh siklus hidup suatu posisi
Namun perlu diperhatikan bahwa objek statistik ini adalah selama tahun 2023, bukan dari pembuatan pool. Mau tidak mau, untuk beberapa posisi, kami tidak dapat memperoleh operasinya sebelum tanggal 1 Januari 2023. Hal ini memerlukan Kami berspekulasi berapa likuiditas posisi tersebut. ada di awal statistik. Kami mengadopsi cara yang ekonomis untuk berspekulasi:
Tambahkan likuiditas mint dan bakar untuk mendapatkan angka L
Jika L>0, yaitu mint>burn, dianggap ada likuiditas sebelum statistik dimulai, dan operasi pencetakan akan dikompensasi pada saat statistik dimulai (2023.1.1 0:0:0 ).
Jika L<0, maka likuiditas dianggap masih tertahan pada akhir statistik.
Cara ini dapat menghindari pengunduhan data sebelum tahun 2023 sehingga menghemat biaya, namun akan menghadapi masalah likuiditas yang tenggelam, yaitu: jika LP tidak melakukan operasi apa pun selama tahun ini, maka LP tidak dapat ditemukan. Namun masalah ini tidak serius. Karena periode statistik adalah satu tahun, kami berasumsi bahwa pengguna umumnya akan menyesuaikan LP selama periode ini. Karena dalam kurun waktu satu tahun, harga eth akan sangat berubah, dan pengguna memiliki banyak alasan untuk Menyesuaikan LP mereka .Jika harganya melebihi tick range, investasikan dana di DEFI lain, dll. Oleh karena itu, sebagai pengguna aktif pasti akan menyesuaikan LP Anda sesuai dengan harganya. Bagi yang menyimpan dana di pool dan tidak pernah melakukan penyesuaian, Kami pertimbangkan ini pengguna menjadi tidak aktif dan tidak disertakan dalam statistik.
Situasi lain yang lebih menyusahkan adalah posisi tersebut mencetak sejumlah likuiditas sebelum tahun 2023, dan kemudian melakukan beberapa operasi pencetakan/pembakaran selama siklus tersebut. Pada akhir statistik, semua likuiditas tidak dibakar. Oleh karena itu, kami hanya sebagian dari likuiditas yang dapat Dalam hal ini, likuiditas yang tenggelam akan berdampak pada estimasi biaya posisi sehingga menyebabkan abnormal return. Alasan spesifiknya akan dibahas nanti.
Dalam statistik akhir, poligon memiliki total 73,278 posisi, sedangkan ethereum memiliki 21,210 posisi.Tidak lebih dari 10 abnormal return untuk setiap rantai, membuktikan bahwa asumsi ini dapat dipercaya.
6. Dapatkan hubungan yang sesuai antara alamat dan posisi
Karena tujuan akhir statistik kita adalah pendapatan dari alamat tersebut, kita juga perlu mendapatkan hubungan yang sesuai antara alamat dan posisi.Melalui asosiasi ini, kita bisa mendapatkan perilaku investasi spesifik pengguna.
Pada langkah 1, kami melakukan beberapa upaya untuk menemukan pengguna terkait operasi dana (pencetakan/pengumpulan). Oleh karena itu, selama kami menemukan pengirim pencetak dan penerima pengumpulan, kami dapat menemukan hubungan yang sesuai antara posisi dan alamat .
7. Hitung nilai bersih dan tingkat pengembalian posisi
Pada langkah ini, kita perlu menghitung nilai bersih setiap posisi, lalu menghitung tingkat pengembalian berdasarkan nilai bersih tersebut
Kekayaan Bersih
Nilai bersih Posisi terdiri dari dua bagian, yang pertama adalah likuiditas LP yang setara dengan pokok pembuatan pasar. Setelah pengguna menginvestasikan dana pada Posisi, jumlah likuiditas tidak akan berubah, tetapi nilai bersih akan berfluktuasi seiring dengan perubahan posisi. bagian lainnya Pendapatan biaya penanganan, bagian ini tidak bergantung pada likuiditas, disimpan secara terpisah dalam dua bidang, biaya0 dan biaya1. Nilai bersih biaya penanganan meningkat seiring berjalannya waktu.
Oleh karena itu, setiap saat, likuiditas digabungkan dengan harga menit tersebut untuk mendapatkan nilai bersih bagian pokok.Perhitungan biaya penanganan memerlukan penggunaan tabel biaya penanganan yang dihitung pada langkah keempat.
Pertama, bagi likuiditas posisi ini dengan total likuiditas pool saat ini sebagai rasio pembagian, lalu tambahkan biaya penanganan semua tick yang termasuk dalam kisaran tick posisi ini untuk mendapatkan pendapatan biaya penanganan pada saat ini.
Diekspresikan sebagai:
Terakhir, tambahkan biaya penanganan fee0 dan fee1 untuk mendapatkan biaya penanganan bersih, lalu tambahkan ke nilai bersih likuiditas untuk mendapatkan total kekayaan bersih.
Saat menghitung kekayaan bersih, kami membagi siklus hidup posisi berdasarkan transaksi mint/burn/collect.
Ketika transaksi mint terjadi, biarkan likuiditas meningkat
Ketika terjadi transaksi burn, kurangi likuiditas dan konversikan nilai likuiditas ke kolom biaya (kode kontrak pool juga beroperasi dengan cara ini)
Ketika transaksi pengumpulan terjadi, perhitungan akan dipicu. Rentang perhitungan adalah dari pengumpulan terakhir hingga waktu saat ini. Kami akan menghitung nilai bersih dan pendapatan biaya setiap menit dan mendapatkan daftarnya.
Terakhir, rangkum daftar nilai bersih yang diperoleh dari setiap pengumpulan, lalu lakukan sampel ulang dan statistik lainnya untuk mendapatkan hasil akhir.
Selain itu, untuk meningkatkan akurasi, kami telah melakukan dua optimasi.
Pertama, untuk jam terjadinya transaksi (mint/burn/collect), kami melakukan statistik tingkat menit, dan untuk jam ketika tidak ada transaksi yang terjadi, kami melakukan statistik tingkat jam. Terakhir, hasilnya diambil sampelnya kembali ke tingkat jam statistik.
Kedua, pada peristiwa pengumpulan, kita bisa mendapatkan jumlah likuiditas + biaya penanganan, oleh karena itu, kita dapat membandingkan nilai pengumpulan aktual dengan nilai perhitungan teoritis kita untuk mendapatkan perbedaan antara biaya penanganan teoritis dan biaya penanganan sebenarnya (sebenarnya perbedaan ini Nilai tersebut juga mencakup selisih pokok lp, namun kesalahan selisih pokok lp sangat kecil dan pada dasarnya dapat dianggap 0). Kami akan mengkompensasi selisih biaya penanganan untuk setiap baris. Untuk meningkatkan akurasi penanganan estimasi biaya (juga merupakan kolom fee_modify0 dan fee_modify1 pada tabel di atas).
Melihat:
Pada saat penimbunan kembali, pembagian biaya penanganan harus ditimbang berdasarkan likuiditas jam berjalan, jika tidak maka biaya penanganan untuk jam tersebut akan tinggi.
Karena data statistik digunakan untuk keseluruhan tahun 2023, dan bukan data lengkap, terdapat fenomena tenggelamnya likuiditas yang disebutkan di Bagian 5. Hal ini akan membuat biaya penanganan aktual jauh lebih tinggi dibandingkan biaya penanganan teoritis. pengembalian menjadi sangat tinggi.
Karena setiap baris adalah data pada saat terakhir jam ini, maka untuk posisi yang telah ditutup seluruhnya, nilai bersihnya akan menjadi 0. Dalam hal ini, nilai bersih pada saat penutupan posisi akan hilang. untuk mempertahankan nilai bersih ini, sebuah baris dibuat di akhir file. Data pada waktu 1-1-2038 00:00:00 menyimpan nilai bersih dan data lainnya pada saat penutupan posisi. Untuk mempersiapkan kebutuhan statistik proyek lain.
tingkat pengembalian
Biasanya, tingkat pengembalian dihitung dengan membagi ekuitas awal dengan ekuitas akhir, namun hal ini tidak berlaku di sini, alasannya adalah sebagai berikut:
Tingkat pengembalian di sini perlu disempurnakan setiap menitnya,
Karena posisi tersebut akan memiliki dana yang ditransfer masuk dan keluar di tengah-tengah, membagi nilai bersih di awal dan akhir saja tidak dapat mencerminkan pendapatan.
Untuk pertanyaan 1, kita dapat membagi nilai bersih per menit untuk mendapatkan tingkat pengembalian per menit, lalu mengalikan tingkat pengembalian per menit untuk mendapatkan tingkat pengembalian total.
Namun algoritma ini mempunyai permasalahan yang cukup serius, jika terjadi kesalahan penghitungan data pada rate of return per menit, maka akan mengakibatkan deviasi yang besar pada total rate of return.Dengan demikian, proses statistik menjadi seperti berjalan di atas tali, dan tidak ada kesalahan yang bisa dibuat. Tapi bagus Di satu sisi, hal ini tidak memberikan ruang untuk kesalahan statistik.
Mengenai pertanyaan ke 2, jika terjadi transfer dana masuk dan keluar saat ini, langsung membaginya dengan rate of return tetap akan menghasilkan rate of return yang sangat keterlaluan, oleh karena itu perlu dilakukan penyempurnaan algoritma rate of return per menit.
Upaya pertama yang kami lakukan adalah menguraikan perubahan kekayaan bersih secara detail, kemudian menghilangkan perubahan dana, kami membagi perubahan kekayaan bersih menjadi beberapa bagian. 1 adalah perubahan pokok yang disebabkan oleh harga. 2 adalah Akumulasi biaya penanganan menit ini. 3 adalah arus masuk dan keluar dana. Tentunya 3 harus dikeluarkan dari statistik. Untuk itu kami rumuskan cara perhitungannya sebagai berikut:
Tentukan menit saat ini adalah n dan menit sebelumnya adalah n-1
Asumsikan seluruh operasi perpindahan pada menit saat ini terjadi pada detik ke-n:0,000, maka pada waktu yang tersisa, nilai bersih LP tidak berubah, artinya nilai bersih pada detik ke-n:0,001 adalah sama dengan nilai bersih pada detik ke-n:59.999. .
Akumulasi biaya penanganan terjadi pada akhir menit ini, yaitu detik ke-n:59.999.
Harga dan biaya penanganan pada akhir menit sebelumnya (n-1:59.999) adalah harga dan biaya penanganan pada awal menit ini (n:0.000)
Berdasarkan asumsi di atas, tingkat pengembalian per menit adalah membagi likuiditas/harga/biaya penanganan di akhir dengan likuiditas/harga/biaya penanganan di akhir, dinyatakan sebagai berikut, di mana f mengacu pada konversi likuiditas menjadi Kekayaan bersih algoritma.
Metode ini terlihat sangat bagus. Metode ini dengan sempurna menghindari perubahan likuiditas. Dan mencerminkan dampak harga dan biaya terhadap kekayaan bersih. Inilah yang kami harapkan. Namun, dalam praktiknya, ini akan terjadi di beberapa baris Hasil yang besar. Setelah diselidiki, kami menemukan bahwa masalah terjadi ketika menarik likuiditas. Ingat aturan kami: waktu yang diwakili oleh setiap baris adalah akhir menit/jam. Hal ini memberikan keseragaman untuk statistik skala data, namun perlu dicatat bahwa arti dari setiap kolom adalah berbeda:
Untuk kolom nilai bersih adalah nilai sesaat, yaitu nilai terakhir menit/jam saat ini.
*Kolom biaya penanganan adalah nilai kumulatif, yaitu akumulasi biaya penanganan selama menit/jam berjalan
Jadi untuk saat itu likuiditas terbakar
Ketika LP dibakar dan token ditransfer, nilai bersihnya akan menjadi 0 pada akhir jam ini
Sedangkan untuk biaya penanganan, karena bersifat kumulatif, maka pada akhir jam tersebut biaya penanganan akan lebih besar dari 0.
Ini mengurangi rumus di atas menjadi:
Situasi ini tidak hanya terjadi pada akhir siklus hidup posisi, tetapi juga ketika sebagian likuiditas habis, juga akan menyebabkan perubahan rasio kenaikan biaya penanganan terhadap kekayaan bersih LP.
Demi kesederhanaan, ketika nilai bersih LP berubah, kami menetapkan tingkat pengembalian menjadi 1. Hal ini akan menyebabkan kesalahan pada hasil perhitungan tingkat pengembalian.Tetapi untuk posisi investasi berkelanjutan yang normal, jam pembuatan transaksi relatif terhadap keseluruhan siklus hidup masih sangat kecil sehingga dampaknya tidak signifikan.
8. Hitung total pendapatan LP alamat tersebut
Dengan tingkat pengembalian setiap posisi, ditambah hubungan yang sesuai antara posisi dan alamat, kita bisa mendapatkan tingkat pengembalian alamat pengguna di setiap posisi.
Algoritme di sini relatif sederhana. Posisi alamat ini pada periode berbeda dihubungkan secara seri. Tidak ada periode investasi di tengahnya, nilai bersih ditetapkan ke 0, dan tingkat pengembalian ditetapkan ke 1 (karena nilai bersih nilai sebelum dan sesudahnya adalah 0, tidak ada perubahan, sehingga tingkat pengembaliannya adalah 1.)
Jika terdapat beberapa posisi dalam periode yang sama, maka nilai bersih dijumlahkan pada bagian yang tumpang tindih untuk mendapatkan total nilai bersih.Saat menggabungkan imbal hasil, penggabungan akan kami bobotkan sesuai dengan nilai bersih masing-masing posisi.
9. Gabungan total pengembalian uang tunai dan LP
Terakhir, selama uang tunai yang dimiliki oleh alamat pengguna dan investasi LP digabungkan, hasil akhirnya dapat diperoleh.
Penggabungan kekayaan bersih lebih sederhana dari langkah sebelumnya (penggabungan posisi). Selama Anda menemukan rentang waktu pada kekayaan bersih LP, cari uang tunai yang disimpan dalam rentang waktu yang sesuai, lalu cari tahu harga eth , Anda bisa mendapatkan total kekayaan bersih. .
Untuk tingkat pengembalian, kami juga menggunakan algoritma mencari tingkat pengembalian per menit dan kemudian mengalikannya.Pada awalnya, kami menggunakan algoritma tingkat kesalahan pengembalian yang disebutkan di Bagian 7. Ini mengharuskan bagian tetap dari menit ini (termasuk uang tunai) Jumlah uang tunai, likuiditas di LP) dan bagian variabel (perubahan harga, akumulasi biaya, transfer dana masuk dan keluar) dipisahkan Dibandingkan dengan statistik posisi, kompleksitasnya jauh lebih tinggi, karena untuk arus masuk dan keluarnya dana uniswap, perhatikan saja acara mint and collection. Ketertelusuran uang tunai sangat merepotkan. Kita harus membedakan apakah dana tersebut ditransfer ke LP atau ditransfer ke luar. Jika ditransfer ke LP, prinsipal bagian bisa tetap tidak berubah. Jika ditransfer ke luar, , untuk memperbaiki jumlah pokok. Ini memerlukan pelacakan alamat tujuan transfer erc20 dan eth. Pekerjaan ini sangat merepotkan. Pertama-tama, selama mint/collect, transfer Alamat bisa berupa kumpulan atau proksi. Yang lebih rumit adalah yang eth. Untuk transfer, karena eth adalah token asli, beberapa catatan transfer hanya dapat ditemukan melalui catatan jejak. Namun, jumlah data jejak terlalu besar dan melebihi kemampuan pemrosesan kami.
Hal terakhir yang mematahkan punggung unta adalah ketika kami menemukan bahwa nilai bersih setiap baris adalah nilai sesaat dari jam ini, dan biaya penanganan adalah nilai kumulatif dari jam ini, yang tidak dapat ditambahkan secara langsung dalam arti fisik. masalah memang ditemukan sangat terlambat.
Oleh karena itu, kami menghentikan algoritma ini. Sebagai gantinya, kami menggunakan nilai bersih menit berikutnya, dibagi dengan nilai bersih menit sebelumnya. Cara ini jauh lebih sederhana. Namun ada juga masalah dengan metode ini. Yaitu ketika dana ditransfer masuk dan keluar, tingkat pengembaliannya masih tidak masuk akal. Melalui pembahasan di atas kita tahu bahwa sangat sulit untuk memisahkan aliran dana. Oleh karena itu, di sini kita mengorbankan beberapa keakuratan dan menetapkan tingkat pengembalian ketika ada adalah transfer dana ke 1.
Pertanyaan yang tersisa adalah, bagaimana cara mengidentifikasi aliran dana masuk dan keluar pada jam saat ini? Algoritma yang saya pikirkan di awal sangat sederhana. Dengan menggunakan saldo token jam sebelumnya dan harga saat ini, kita dapat menghitung nilai bersihnya. jam ini kalau kita pegang token ini. Jadi apa? Lalu nilai taksirannya dikurangi saja dengan nilai sebenarnya. Bila selisihnya tidak sama dengan nilai sebenarnya berarti ada transfer dana masuk dan keluar. Rumusnya dinyatakan sebagai:
Namun, algoritma ini mengabaikan kompleksitas LP uniswap. Dalam LP, jumlah token akan berubah seiring perubahan harga, dan nilai bersih juga akan berubah. Dan metode ini tidak memperhitungkan perubahan biaya penanganan. Pada akhirnya, nilai perkiraan akan berbeda dengan nilai sebenarnya, nilai tersebut mempunyai kesalahan sekitar 0,1%.
Untuk meningkatkan akurasi, struktur dana disempurnakan, perubahan nilai LP dihitung secara terpisah, dan biaya penanganan juga diperhitungkan.
Dengan cara ini, kesalahan nilai estimasi dapat dikendalikan dalam kisaran 0,001%.
Selain itu, kami membatasi desimal data untuk menghindari pembagian dengan angka yang terlalu kecil (biasanya di bawah 10^-10). Angka kecil ini merupakan kesalahan yang terakumulasi dari berbagai perhitungan dan pengambilan sampel ulang. Jika korelasi langsung tidak diproses, Pembagian akan menyebabkan kesalahan menjadi lebih besar, sehingga secara serius mendistorsi tingkat pengembalian.
Pertanyaan Lain
token asli
Dalam statistik ini, kumpulan usdc-eth di ethereum telah ditambahkan, di mana eth adalah token asli dan memerlukan beberapa pemrosesan khusus.
Eth tidak dapat digunakan secara defi dan harus dikonversi ke weth, oleh karena itu pool ini sebenarnya adalah pool usdc-weth, bagi pengguna yang langsung mengoperasikan pool tersebut cukup mentransfer weth yang masuk dan keluar dari pool ini, sama saja dengan yang biasa kolam renang, sama saja.
Bagi pengguna yang menambahkan LP melalui proxy, mereka perlu memasukkan eth ke dalam nilai transaksi dan mentransfernya ke kontrak proxy. Kontrak tersebut kemudian mengubah eth ini menjadi weth dan kemudian memasukkannya ke dalam pool. Saat mengumpulkan, usdc dapat digunakan langsung Mentransfernya ke pengguna, tetapi eth tidak dapat ditransfer langsung ke pengguna. Ini harus ditransfer dari pool ke proxy terlebih dahulu, kemudian diubah menjadi eth melalui kontrak proxy, dan akhirnya dikirim ke pengguna melalui transfer internal. Untuk contohnya, lihat transaksi ini [4] .
Oleh karena itu, satu-satunya perbedaan antara pool usdc-eth dan pool biasa adalah transfer dana masuk dan keluar. Ini hanya mempengaruhi posisi dan alamat yang cocok. Untuk mengatasi masalah ini, kami menarik semua data transfer nft dari pembuatan dari pool, lalu Temukan pemegang posisi yang sesuai melalui id token.
posisi hilang
Secara statistik, beberapa posisi tidak masuk daftar final, karena posisi tersebut memiliki ciri-ciri khusus tertentu.
Sebagian besar adalah transaksi MEV. MEV adalah transaksi arbitrase murni dan bukan investor biasa, sehingga tidak termasuk dalam cakupan statistik kami. Selain itu, sulit untuk menghitungnya dalam statistik aktual, yang memerlukan penggunaan level jejak. .data. Di sini kami menggunakan strategi sederhana untuk memfilter mev transaksi, yaitu waktu dari awal hingga akhir kurang dari satu menit. Faktanya, karena akurasi tertinggi data kami adalah 1 menit. Jika suatu posisi ada Jika waktunya kurang dari satu menit, tidak dapat dihitung.
Kemungkinan lainnya adalah tidak ada transaksi penagihan pada posisi ini. Seperti terlihat pada langkah 7, perhitungan pendapatan kita dipicu oleh pengumpulan. Tanpa operasi pengumpulan, nilai bersih dan tingkat pengembalian sebelumnya tidak akan dihitung. Dalam keadaan normal Dalam situasi ini, pengguna akan memilih untuk memanen pendapatan atau pokok LP pada waktu yang tepat. Namun, beberapa pengguna khusus tidak dikecualikan, yaitu, mereka harus menyimpan aset mereka di fee0 dan fee1 dari kumpulan uniswap. Untuk pengguna seperti itu, kami juga menganggap mereka sebagai pengguna khusus dan tidak termasuk dalam cakupan statistik. .
Referensi
[1] 0x45dda9cb7c25131df268515131f647d726f50608:
[2] 0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640:
[3] Transaksi ini:
[4] Transaksi ini:
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Membongkar proses pembersihan data Uniswap V3
Ditulis oleh: Zelos
Perkenalan
Pada edisi terakhir, kami menghitung kekayaan bersih dan tingkat pengembalian pengguna di uniswap dari perspektif alamat pengguna. Kali ini, tujuan kami tetap sama. Namun uang tunai yang disimpan di alamat-alamat ini harus dihitung. Dapatkan total kekayaan bersih dan tingkat pengembalian.
Ada dua kumpulan untuk objek statistik ini, termasuk
Data akhir yang diperoleh adalah data level per jam Catatan: **Data pada setiap baris mewakili nilai pada saat terakhir pada jam tersebut. **
Proses keseluruhan
1. Dapatkan data Uniswap
Untuk menyediakan sumber data bagi demeter, kami mengembangkan alat demeter-fetch. Alat ini dapat memperoleh log kumpulan Uniswap dari saluran berbeda dan menguraikannya ke dalam format berbeda. Sumber data yang didukung adalah:
Format keluaran meliputi:
Kali ini kami terutama memperoleh data tick, yang digunakan untuk menghitung informasi posisi, termasuk jumlah dana/pendapatan per menit/siklus hidup/pemegang, dll.
Data ini diperoleh melalui event log pool. Seperti mint, burn, collector. swap. Namun, log pool tidak berisi id token. Hal ini membuat kami tidak dapat menemukan di mana posisi pengoperasian pool. kolam renang untuk.
Faktanya, hak dan kepentingan LP uniswap dikelola melalui nft, dan pengelola token nft ini adalah kontrak proxy. Id token hanya ada di log peristiwa proxy. Oleh karena itu, jika Anda ingin mendapatkan posisi LP yang lengkap informasi, Anda harus mendapatkan proxy. Log peristiwa kemudian digabungkan dengan log peristiwa kumpulan.
perdagangan ini [3] Sebagai contoh, kita perlu memperhatikan dua log dengan indeks log 227 dan 229. Mereka adalah mint yang dilemparkan oleh kontrak kumpulan dan Peningkatan Likuiditas yang dilemparkan oleh kontrak proksi. Jumlah (yaitu, likuiditas) di antara keduanya, jumlah0 dan jumlah1 adalah sama. . Ini dapat digunakan sebagai dasar untuk korelasi. Dengan mengkorelasikan kedua log ini, kita bisa mendapatkan rentang tick, likuiditas, id token, dan jumlah yang sesuai dengan dua token dari perilaku LP ini.
Untuk burn dan collection anda juga bisa menggunakan cara ini untuk mencari id posisi yang sesuai untuk event pool. Namun ada kendala disini. Terkadang jumlah kedua event tersebut tidak sama dan akan terjadi sedikit penyimpangan. Misalnya misalnya transaksi ini
Akan ada perbedaan kecil antara jumlah0 dan jumlah1. Meskipun situasi ini jarang terjadi, hal ini juga sangat umum. Jadi ketika kita mencocokkan bakar dan kumpulkan, kita menyisakan ruang untuk kesalahan dalam nilai.
Pertanyaan selanjutnya yang harus ditangani adalah siapa yang memulai transaksi ini. Untuk likuidasi, kami akan menggunakan kwitansi di acara pengumpulan sebagai pemegang posisi. Untuk mint, kami hanya bisa mendapatkan pengirimnya (Lihat gambar dengan acara mint).
Jika pengguna mengoperasikan kontrak pool maka pengirim akan menjadi penyedia LP, namun jika pengguna biasa mengoperasikan kontrak melalui proxy maka pengirim akan menjadi alamat proxy, hal ini dikarenakan dana memang ditransfer dari proxy ke pool. Tapi kabar baiknya adalah Proxy akan menghasilkan token nft. Dan token nft ini pasti akan ditransfer ke penyedia LP. Oleh karena itu, dengan mendeteksi transfer kontrak proxy (yaitu kontrak token nft) , Anda dapat menemukan penyedia LP yang sesuai dengan mint ini.
Selain itu, jika nft ditransfer, pemegang posisi akan berubah. Kami telah membuat statistik mengenai hal ini, dan situasi ini jarang terjadi. Untuk menyederhanakan, kami tidak mempertimbangkan transfer nft setelah mint.
2. Dapatkan uang tunai yang disimpan berdasarkan alamat
Tujuan dari tahap ini adalah untuk mendapatkan jumlah token yang dimiliki oleh suatu alamat pada setiap saat selama periode statistik. Untuk mencapai tujuan ini, perlu diperoleh dua aspek data,
Dengan menjumlahkan dan mengurangi saldo menggunakan catatan transfer, saldo setiap saat dapat disimpulkan.
Saldo pada waktu mulai dapat ditanyakan melalui antarmuka rpc. Saat menggunakan node pencapaian, Anda dapat mengatur ketinggian parameter kueri untuk mendapatkan saldo kapan saja. Saldo token asli dan erc20 dapat diperoleh dengan cara ini. .
Mendapatkan catatan transfer erc20 relatif mudah dan dapat diperoleh melalui saluran apa pun (big query, rpc, chifra).
Catatan transfer eth perlu diperoleh melalui transaksi dan pelacakan. Transaksinya oke, tetapi kueri dan pemrosesan jejak sangat intensif secara komputasi. Untungnya, chifra menyediakan fungsi mengekspor saldo eth. Catatan dapat dihasilkan ketika perubahan saldo, walaupun hanya dapat mencatat perubahan kuantitas, tetapi tidak dapat mencatat objek perpindahan, namun tetap dapat memenuhi persyaratan.Ini adalah metode berbiaya terendah yang memenuhi persyaratan.
3. Dapatkan harga
Uniswap adalah sebuah pertukaran, jika terjadi pertukaran token maka akan dihasilkan event swap. Kita bisa mendapatkan harga token dari kolom sqrtPriceX96. Dapatkan total likuiditas pada saat itu dari kolom likuiditas.
Karena pool kami memiliki mata uang yang stabil, sangat mudah untuk mendapatkan harga u. Namun harga ini tidak sepenuhnya akurat. Pertama-tama, hal ini dipengaruhi oleh frekuensi transaksi. Jika tidak ada transaksi swap, harganya akan berubah. lag. Selain itu, ketika stablecoin tidak terikat, juga akan ada kesenjangan antara harga ini dan harga untuk Anda. Namun dalam keadaan normal, harga ini cukup akurat, dan tidak ada masalah untuk riset pasar.
Terakhir, harga token diambil sampelnya kembali untuk mendapatkan daftar harga per menit.
Selain itu, karena bidang likuiditas peristiwa juga berisi total likuiditas dari kumpulan saat ini, kami juga menambahkan total likuiditas. Akhirnya, sebuah tabel dibentuk sebagai berikut:
4. Statistik biaya penanganan
Biaya penanganan adalah sumber pendapatan utama untuk suatu posisi. Setiap kali pengguna melakukan operasi swap di pool, posisi terkait dapat menerima biaya penanganan tertentu (yaitu, bawah dan atas termasuk posisi tick saat ini). pendapatan sebanding dengan likuiditas.Rasio, tingkat biaya kumpulan, dan rentang tick saling terkait.
Untuk menghitung pendapatan biaya pengguna, kita dapat mencatat jumlah swap yang terjadi di pool yang dicentang setiap menitnya, lalu menghitung pendapatan biaya pada tick ini di menit saat ini:
Akhirnya menjadi tabel seperti ini
Metode statistik ini tidak memperhitungkan situasi ketika likuiditas tick saat ini habis selama swap. Namun, karena tujuan statistik kami adalah LP, kami menggunakan rentang tick untuk statistik. Kesalahan ini dapat diatasi sampai batas tertentu.
5. Dapatkan daftar posisi
Untuk mendapatkan daftar jabatan, Anda harus menentukan pengenal jabatan terlebih dahulu.
Melalui pengidentifikasi ini, kita dapat mengintegrasikan seluruh operasi LP untuk membentuk daftar yang menggambarkan seluruh siklus hidup suatu posisi
Namun perlu diperhatikan bahwa objek statistik ini adalah selama tahun 2023, bukan dari pembuatan pool. Mau tidak mau, untuk beberapa posisi, kami tidak dapat memperoleh operasinya sebelum tanggal 1 Januari 2023. Hal ini memerlukan Kami berspekulasi berapa likuiditas posisi tersebut. ada di awal statistik. Kami mengadopsi cara yang ekonomis untuk berspekulasi:
Cara ini dapat menghindari pengunduhan data sebelum tahun 2023 sehingga menghemat biaya, namun akan menghadapi masalah likuiditas yang tenggelam, yaitu: jika LP tidak melakukan operasi apa pun selama tahun ini, maka LP tidak dapat ditemukan. Namun masalah ini tidak serius. Karena periode statistik adalah satu tahun, kami berasumsi bahwa pengguna umumnya akan menyesuaikan LP selama periode ini. Karena dalam kurun waktu satu tahun, harga eth akan sangat berubah, dan pengguna memiliki banyak alasan untuk Menyesuaikan LP mereka .Jika harganya melebihi tick range, investasikan dana di DEFI lain, dll. Oleh karena itu, sebagai pengguna aktif pasti akan menyesuaikan LP Anda sesuai dengan harganya. Bagi yang menyimpan dana di pool dan tidak pernah melakukan penyesuaian, Kami pertimbangkan ini pengguna menjadi tidak aktif dan tidak disertakan dalam statistik.
Situasi lain yang lebih menyusahkan adalah posisi tersebut mencetak sejumlah likuiditas sebelum tahun 2023, dan kemudian melakukan beberapa operasi pencetakan/pembakaran selama siklus tersebut. Pada akhir statistik, semua likuiditas tidak dibakar. Oleh karena itu, kami hanya sebagian dari likuiditas yang dapat Dalam hal ini, likuiditas yang tenggelam akan berdampak pada estimasi biaya posisi sehingga menyebabkan abnormal return. Alasan spesifiknya akan dibahas nanti.
Dalam statistik akhir, poligon memiliki total 73,278 posisi, sedangkan ethereum memiliki 21,210 posisi.Tidak lebih dari 10 abnormal return untuk setiap rantai, membuktikan bahwa asumsi ini dapat dipercaya.
6. Dapatkan hubungan yang sesuai antara alamat dan posisi
Karena tujuan akhir statistik kita adalah pendapatan dari alamat tersebut, kita juga perlu mendapatkan hubungan yang sesuai antara alamat dan posisi.Melalui asosiasi ini, kita bisa mendapatkan perilaku investasi spesifik pengguna.
Pada langkah 1, kami melakukan beberapa upaya untuk menemukan pengguna terkait operasi dana (pencetakan/pengumpulan). Oleh karena itu, selama kami menemukan pengirim pencetak dan penerima pengumpulan, kami dapat menemukan hubungan yang sesuai antara posisi dan alamat .
7. Hitung nilai bersih dan tingkat pengembalian posisi
Pada langkah ini, kita perlu menghitung nilai bersih setiap posisi, lalu menghitung tingkat pengembalian berdasarkan nilai bersih tersebut
Kekayaan Bersih
Nilai bersih Posisi terdiri dari dua bagian, yang pertama adalah likuiditas LP yang setara dengan pokok pembuatan pasar. Setelah pengguna menginvestasikan dana pada Posisi, jumlah likuiditas tidak akan berubah, tetapi nilai bersih akan berfluktuasi seiring dengan perubahan posisi. bagian lainnya Pendapatan biaya penanganan, bagian ini tidak bergantung pada likuiditas, disimpan secara terpisah dalam dua bidang, biaya0 dan biaya1. Nilai bersih biaya penanganan meningkat seiring berjalannya waktu.
Oleh karena itu, setiap saat, likuiditas digabungkan dengan harga menit tersebut untuk mendapatkan nilai bersih bagian pokok.Perhitungan biaya penanganan memerlukan penggunaan tabel biaya penanganan yang dihitung pada langkah keempat.
Pertama, bagi likuiditas posisi ini dengan total likuiditas pool saat ini sebagai rasio pembagian, lalu tambahkan biaya penanganan semua tick yang termasuk dalam kisaran tick posisi ini untuk mendapatkan pendapatan biaya penanganan pada saat ini.
Diekspresikan sebagai:
Terakhir, tambahkan biaya penanganan fee0 dan fee1 untuk mendapatkan biaya penanganan bersih, lalu tambahkan ke nilai bersih likuiditas untuk mendapatkan total kekayaan bersih.
Saat menghitung kekayaan bersih, kami membagi siklus hidup posisi berdasarkan transaksi mint/burn/collect.
Terakhir, rangkum daftar nilai bersih yang diperoleh dari setiap pengumpulan, lalu lakukan sampel ulang dan statistik lainnya untuk mendapatkan hasil akhir.
Selain itu, untuk meningkatkan akurasi, kami telah melakukan dua optimasi.
Pertama, untuk jam terjadinya transaksi (mint/burn/collect), kami melakukan statistik tingkat menit, dan untuk jam ketika tidak ada transaksi yang terjadi, kami melakukan statistik tingkat jam. Terakhir, hasilnya diambil sampelnya kembali ke tingkat jam statistik.
Kedua, pada peristiwa pengumpulan, kita bisa mendapatkan jumlah likuiditas + biaya penanganan, oleh karena itu, kita dapat membandingkan nilai pengumpulan aktual dengan nilai perhitungan teoritis kita untuk mendapatkan perbedaan antara biaya penanganan teoritis dan biaya penanganan sebenarnya (sebenarnya perbedaan ini Nilai tersebut juga mencakup selisih pokok lp, namun kesalahan selisih pokok lp sangat kecil dan pada dasarnya dapat dianggap 0). Kami akan mengkompensasi selisih biaya penanganan untuk setiap baris. Untuk meningkatkan akurasi penanganan estimasi biaya (juga merupakan kolom fee_modify0 dan fee_modify1 pada tabel di atas).
Melihat:
Karena setiap baris adalah data pada saat terakhir jam ini, maka untuk posisi yang telah ditutup seluruhnya, nilai bersihnya akan menjadi 0. Dalam hal ini, nilai bersih pada saat penutupan posisi akan hilang. untuk mempertahankan nilai bersih ini, sebuah baris dibuat di akhir file. Data pada waktu 1-1-2038 00:00:00 menyimpan nilai bersih dan data lainnya pada saat penutupan posisi. Untuk mempersiapkan kebutuhan statistik proyek lain.
tingkat pengembalian
Biasanya, tingkat pengembalian dihitung dengan membagi ekuitas awal dengan ekuitas akhir, namun hal ini tidak berlaku di sini, alasannya adalah sebagai berikut:
Untuk pertanyaan 1, kita dapat membagi nilai bersih per menit untuk mendapatkan tingkat pengembalian per menit, lalu mengalikan tingkat pengembalian per menit untuk mendapatkan tingkat pengembalian total.
Namun algoritma ini mempunyai permasalahan yang cukup serius, jika terjadi kesalahan penghitungan data pada rate of return per menit, maka akan mengakibatkan deviasi yang besar pada total rate of return.Dengan demikian, proses statistik menjadi seperti berjalan di atas tali, dan tidak ada kesalahan yang bisa dibuat. Tapi bagus Di satu sisi, hal ini tidak memberikan ruang untuk kesalahan statistik.
Mengenai pertanyaan ke 2, jika terjadi transfer dana masuk dan keluar saat ini, langsung membaginya dengan rate of return tetap akan menghasilkan rate of return yang sangat keterlaluan, oleh karena itu perlu dilakukan penyempurnaan algoritma rate of return per menit.
Upaya pertama yang kami lakukan adalah menguraikan perubahan kekayaan bersih secara detail, kemudian menghilangkan perubahan dana, kami membagi perubahan kekayaan bersih menjadi beberapa bagian. 1 adalah perubahan pokok yang disebabkan oleh harga. 2 adalah Akumulasi biaya penanganan menit ini. 3 adalah arus masuk dan keluar dana. Tentunya 3 harus dikeluarkan dari statistik. Untuk itu kami rumuskan cara perhitungannya sebagai berikut:
Berdasarkan asumsi di atas, tingkat pengembalian per menit adalah membagi likuiditas/harga/biaya penanganan di akhir dengan likuiditas/harga/biaya penanganan di akhir, dinyatakan sebagai berikut, di mana f mengacu pada konversi likuiditas menjadi Kekayaan bersih algoritma.
Metode ini terlihat sangat bagus. Metode ini dengan sempurna menghindari perubahan likuiditas. Dan mencerminkan dampak harga dan biaya terhadap kekayaan bersih. Inilah yang kami harapkan. Namun, dalam praktiknya, ini akan terjadi di beberapa baris Hasil yang besar. Setelah diselidiki, kami menemukan bahwa masalah terjadi ketika menarik likuiditas. Ingat aturan kami: waktu yang diwakili oleh setiap baris adalah akhir menit/jam. Hal ini memberikan keseragaman untuk statistik skala data, namun perlu dicatat bahwa arti dari setiap kolom adalah berbeda:
Jadi untuk saat itu likuiditas terbakar
Ini mengurangi rumus di atas menjadi:
Situasi ini tidak hanya terjadi pada akhir siklus hidup posisi, tetapi juga ketika sebagian likuiditas habis, juga akan menyebabkan perubahan rasio kenaikan biaya penanganan terhadap kekayaan bersih LP.
Demi kesederhanaan, ketika nilai bersih LP berubah, kami menetapkan tingkat pengembalian menjadi 1. Hal ini akan menyebabkan kesalahan pada hasil perhitungan tingkat pengembalian.Tetapi untuk posisi investasi berkelanjutan yang normal, jam pembuatan transaksi relatif terhadap keseluruhan siklus hidup masih sangat kecil sehingga dampaknya tidak signifikan.
8. Hitung total pendapatan LP alamat tersebut
Dengan tingkat pengembalian setiap posisi, ditambah hubungan yang sesuai antara posisi dan alamat, kita bisa mendapatkan tingkat pengembalian alamat pengguna di setiap posisi.
Algoritme di sini relatif sederhana. Posisi alamat ini pada periode berbeda dihubungkan secara seri. Tidak ada periode investasi di tengahnya, nilai bersih ditetapkan ke 0, dan tingkat pengembalian ditetapkan ke 1 (karena nilai bersih nilai sebelum dan sesudahnya adalah 0, tidak ada perubahan, sehingga tingkat pengembaliannya adalah 1.)
Jika terdapat beberapa posisi dalam periode yang sama, maka nilai bersih dijumlahkan pada bagian yang tumpang tindih untuk mendapatkan total nilai bersih.Saat menggabungkan imbal hasil, penggabungan akan kami bobotkan sesuai dengan nilai bersih masing-masing posisi.
9. Gabungan total pengembalian uang tunai dan LP
Terakhir, selama uang tunai yang dimiliki oleh alamat pengguna dan investasi LP digabungkan, hasil akhirnya dapat diperoleh.
Penggabungan kekayaan bersih lebih sederhana dari langkah sebelumnya (penggabungan posisi). Selama Anda menemukan rentang waktu pada kekayaan bersih LP, cari uang tunai yang disimpan dalam rentang waktu yang sesuai, lalu cari tahu harga eth , Anda bisa mendapatkan total kekayaan bersih. .
Untuk tingkat pengembalian, kami juga menggunakan algoritma mencari tingkat pengembalian per menit dan kemudian mengalikannya.Pada awalnya, kami menggunakan algoritma tingkat kesalahan pengembalian yang disebutkan di Bagian 7. Ini mengharuskan bagian tetap dari menit ini (termasuk uang tunai) Jumlah uang tunai, likuiditas di LP) dan bagian variabel (perubahan harga, akumulasi biaya, transfer dana masuk dan keluar) dipisahkan Dibandingkan dengan statistik posisi, kompleksitasnya jauh lebih tinggi, karena untuk arus masuk dan keluarnya dana uniswap, perhatikan saja acara mint and collection. Ketertelusuran uang tunai sangat merepotkan. Kita harus membedakan apakah dana tersebut ditransfer ke LP atau ditransfer ke luar. Jika ditransfer ke LP, prinsipal bagian bisa tetap tidak berubah. Jika ditransfer ke luar, , untuk memperbaiki jumlah pokok. Ini memerlukan pelacakan alamat tujuan transfer erc20 dan eth. Pekerjaan ini sangat merepotkan. Pertama-tama, selama mint/collect, transfer Alamat bisa berupa kumpulan atau proksi. Yang lebih rumit adalah yang eth. Untuk transfer, karena eth adalah token asli, beberapa catatan transfer hanya dapat ditemukan melalui catatan jejak. Namun, jumlah data jejak terlalu besar dan melebihi kemampuan pemrosesan kami.
Hal terakhir yang mematahkan punggung unta adalah ketika kami menemukan bahwa nilai bersih setiap baris adalah nilai sesaat dari jam ini, dan biaya penanganan adalah nilai kumulatif dari jam ini, yang tidak dapat ditambahkan secara langsung dalam arti fisik. masalah memang ditemukan sangat terlambat.
Oleh karena itu, kami menghentikan algoritma ini. Sebagai gantinya, kami menggunakan nilai bersih menit berikutnya, dibagi dengan nilai bersih menit sebelumnya. Cara ini jauh lebih sederhana. Namun ada juga masalah dengan metode ini. Yaitu ketika dana ditransfer masuk dan keluar, tingkat pengembaliannya masih tidak masuk akal. Melalui pembahasan di atas kita tahu bahwa sangat sulit untuk memisahkan aliran dana. Oleh karena itu, di sini kita mengorbankan beberapa keakuratan dan menetapkan tingkat pengembalian ketika ada adalah transfer dana ke 1.
Pertanyaan yang tersisa adalah, bagaimana cara mengidentifikasi aliran dana masuk dan keluar pada jam saat ini? Algoritma yang saya pikirkan di awal sangat sederhana. Dengan menggunakan saldo token jam sebelumnya dan harga saat ini, kita dapat menghitung nilai bersihnya. jam ini kalau kita pegang token ini. Jadi apa? Lalu nilai taksirannya dikurangi saja dengan nilai sebenarnya. Bila selisihnya tidak sama dengan nilai sebenarnya berarti ada transfer dana masuk dan keluar. Rumusnya dinyatakan sebagai:
Namun, algoritma ini mengabaikan kompleksitas LP uniswap. Dalam LP, jumlah token akan berubah seiring perubahan harga, dan nilai bersih juga akan berubah. Dan metode ini tidak memperhitungkan perubahan biaya penanganan. Pada akhirnya, nilai perkiraan akan berbeda dengan nilai sebenarnya, nilai tersebut mempunyai kesalahan sekitar 0,1%.
Untuk meningkatkan akurasi, struktur dana disempurnakan, perubahan nilai LP dihitung secara terpisah, dan biaya penanganan juga diperhitungkan.
Dengan cara ini, kesalahan nilai estimasi dapat dikendalikan dalam kisaran 0,001%.
Selain itu, kami membatasi desimal data untuk menghindari pembagian dengan angka yang terlalu kecil (biasanya di bawah 10^-10). Angka kecil ini merupakan kesalahan yang terakumulasi dari berbagai perhitungan dan pengambilan sampel ulang. Jika korelasi langsung tidak diproses, Pembagian akan menyebabkan kesalahan menjadi lebih besar, sehingga secara serius mendistorsi tingkat pengembalian.
Pertanyaan Lain
token asli
Dalam statistik ini, kumpulan usdc-eth di ethereum telah ditambahkan, di mana eth adalah token asli dan memerlukan beberapa pemrosesan khusus.
Eth tidak dapat digunakan secara defi dan harus dikonversi ke weth, oleh karena itu pool ini sebenarnya adalah pool usdc-weth, bagi pengguna yang langsung mengoperasikan pool tersebut cukup mentransfer weth yang masuk dan keluar dari pool ini, sama saja dengan yang biasa kolam renang, sama saja.
Bagi pengguna yang menambahkan LP melalui proxy, mereka perlu memasukkan eth ke dalam nilai transaksi dan mentransfernya ke kontrak proxy. Kontrak tersebut kemudian mengubah eth ini menjadi weth dan kemudian memasukkannya ke dalam pool. Saat mengumpulkan, usdc dapat digunakan langsung Mentransfernya ke pengguna, tetapi eth tidak dapat ditransfer langsung ke pengguna. Ini harus ditransfer dari pool ke proxy terlebih dahulu, kemudian diubah menjadi eth melalui kontrak proxy, dan akhirnya dikirim ke pengguna melalui transfer internal. Untuk contohnya, lihat transaksi ini [4] .
Oleh karena itu, satu-satunya perbedaan antara pool usdc-eth dan pool biasa adalah transfer dana masuk dan keluar. Ini hanya mempengaruhi posisi dan alamat yang cocok. Untuk mengatasi masalah ini, kami menarik semua data transfer nft dari pembuatan dari pool, lalu Temukan pemegang posisi yang sesuai melalui id token.
posisi hilang
Secara statistik, beberapa posisi tidak masuk daftar final, karena posisi tersebut memiliki ciri-ciri khusus tertentu.
Sebagian besar adalah transaksi MEV. MEV adalah transaksi arbitrase murni dan bukan investor biasa, sehingga tidak termasuk dalam cakupan statistik kami. Selain itu, sulit untuk menghitungnya dalam statistik aktual, yang memerlukan penggunaan level jejak. .data. Di sini kami menggunakan strategi sederhana untuk memfilter mev transaksi, yaitu waktu dari awal hingga akhir kurang dari satu menit. Faktanya, karena akurasi tertinggi data kami adalah 1 menit. Jika suatu posisi ada Jika waktunya kurang dari satu menit, tidak dapat dihitung.
Kemungkinan lainnya adalah tidak ada transaksi penagihan pada posisi ini. Seperti terlihat pada langkah 7, perhitungan pendapatan kita dipicu oleh pengumpulan. Tanpa operasi pengumpulan, nilai bersih dan tingkat pengembalian sebelumnya tidak akan dihitung. Dalam keadaan normal Dalam situasi ini, pengguna akan memilih untuk memanen pendapatan atau pokok LP pada waktu yang tepat. Namun, beberapa pengguna khusus tidak dikecualikan, yaitu, mereka harus menyimpan aset mereka di fee0 dan fee1 dari kumpulan uniswap. Untuk pengguna seperti itu, kami juga menganggap mereka sebagai pengguna khusus dan tidak termasuk dalam cakupan statistik. .