gmx synthetics
V2.1
Kontrak untuk Sintetis GMX.
Bagian ini memberikan gambaran umum tentang cara kerja sistem.
Untuk Ikhtisar Teknis, silakan lihat bagian lebih lanjut di bawah.
Pasar mendukung perdagangan spot dan pelaku, keduanya dibuat dengan menentukan token jaminan panjang, token jaminan pendek, dan token indeks.
Contoh:
Penyedia likuiditas dapat menyetorkan token jaminan panjang atau pendek atau keduanya untuk mencetak token likuiditas.
Token agunan panjang digunakan untuk mendukung posisi panjang, sedangkan token agunan pendek digunakan untuk mendukung posisi pendek.
Penyedia likuiditas mengambil keuntungan dan kerugian pedagang untuk pasar yang mereka sediakan likuiditasnya.
Memiliki pasar terpisah memungkinkan isolasi risiko, penyedia likuiditas hanya terpapar pada pasar tempat mereka menyimpan dana, hal ini berpotensi memungkinkan pencatatan tanpa izin.
Pedagang dapat menggunakan token panjang atau pendek sebagai jaminan pasar.
Kontrak mendukung fitur-fitur utama berikut:
Untuk menghindari masalah yang terjadi di awal, sebagian besar tindakan memerlukan dua langkah untuk dijalankan:
Harga disediakan oleh sistem oracle off-chain, yang terus-menerus menandatangani harga berdasarkan waktu pertanyaan harga.
Baik harga minimum maupun harga maksimum ditandatangani, hal ini memungkinkan informasi tentang spread bid-ask disertakan.
Harga yang disimpan dalam kontrak Oracle mewakili harga satu unit token menggunakan nilai dengan presisi 30 desimal.
Mewakili harga dengan cara ini memungkinkan konversi antara jumlah token dan nilai fiat disederhanakan, misalnya untuk menghitung nilai fiat dari sejumlah token tertentu, perhitungannya adalah: jumlah token * harga oracle, untuk menghitung jumlah token untuk suatu nilai fiat akan menjadi: nilai fiat / harga oracle.
Biaya pendanaan dan dampak harga menjaga keseimbangan posisi long/short sekaligus mengurangi risiko manipulasi harga.
Ada beberapa penjaga dan node dalam sistem:
Ada beberapa jenis kontrak utama:
Kontrak dipisahkan ke dalam jenis-jenis ini untuk memungkinkan peningkatan bertahap.
Mayoritas data disimpan menggunakan kontrak DataStore.
*kontrak storeUtils menyimpan data struct menggunakan DataStore, ini memungkinkan kunci baru ditambahkan ke struct.
EnumberableSets digunakan untuk memungkinkan daftar pesanan dan daftar posisi agar mudah ditanyakan oleh antarmuka atau penjaga, ini digunakan pada pengindeks karena mungkin ada kelambatan bagi pengindeks untuk menyinkronkan blok terbaru. Menyimpan daftar secara langsung dalam kontrak juga membantu memastikan bahwa data yang akurat dapat diambil dan diverifikasi bila diperlukan.
*kontrak eventUtils memancarkan peristiwa menggunakan pemancar peristiwa, peristiwa tersebut digeneralisasikan untuk memungkinkan nilai kunci baru ditambahkan ke peristiwa tanpa memerlukan pembaruan ABI.
Kependekan dari GMX Liquidity Vault: pembungkus beberapa pasar dengan token panjang dan pendek yang sama. Likuiditas secara otomatis diseimbangkan kembali antara pasar-pasar yang mendasarinya berdasarkan pemanfaatan pasar.
Bagian ini memberikan gambaran teknis kontrak.
Pasar dibuat menggunakan MarketFactory.createMarket , ini menciptakan MarketToken dan menyimpan struct Market.Props di MarketStore.
MarketToken digunakan untuk melacak bagian penyedia likuiditas dari kumpulan pasar dan untuk menyimpan token untuk setiap pasar.
Kapan saja, harga MarketToken adalah (worth of market pool) / MarketToken.totalSupply() , fungsi MarketUtils.getMarketTokenPrice dapat digunakan untuk mengambil nilai ini.
Nilai dari kumpulan pasar adalah jumlah dari
Setoran menambahkan token panjang/pendek ke kumpulan pasar dan mencetak MarketToken ke deposan.
Permintaan setoran dibuat dengan memanggil ExchangeRouter.createDeposit, dengan menentukan:
Permintaan deposit dijalankan menggunakan DepositHandler.executeDeposit, jika deposit dibuat pada stempel waktu n , maka harus dieksekusi dengan harga Oracle setelah stempel waktu n .
Jumlah MarketToken yang akan dicetak, sebelum biaya dan dampak harga, dihitung sebagai (worth of tokens deposited) / (worth of market pool) * MarketToken.totalSupply() .
Penarikan membakar MarketToken sebagai ganti token panjang/pendek dari kumpulan pasar.
Permintaan penarikan dibuat dengan memanggil ExchangeRouter.createWithdrawal, dengan menentukan:
Permintaan penarikan dieksekusi menggunakan WithdrawalHandler.executeWithdrawal, jika penarikan dibuat pada stempel waktu n , penarikan tersebut harus dieksekusi dengan harga Oracle setelah stempel waktu n .
Jumlah token panjang atau pendek yang harus ditebus, sebelum biaya dan dampak harga, dihitung sebagai (worth of market tokens) / (long / short token price) .
Token pasar yang panjang dan pendek dapat ditukar satu sama lain.
Misalnya, jika pasar ETH/USD memiliki WETH sebagai token panjang dan USDC sebagai token pendek, WETH dapat dikirim ke pasar untuk ditukar dengan USDC dan USDC dapat dikirim ke pasar untuk ditukar dengan WETH.
Permintaan pesanan swap dibuat dengan memanggil ExchangeRouter.createOrder, dengan menentukan:
Jumlah keluaran swap, sebelum biaya dan dampak harga, (amount of tokens in) * (token in price) / (token out price) .
Permintaan pesanan pertukaran pasar dieksekusi menggunakan OrderHandler.executeOrder, jika pesanan dibuat pada stempel waktu n , pesanan harus dieksekusi dengan harga Oracle setelah stempel waktu n .
Perintah swap pasif yang harus dieksekusi ketika jumlah keluaran sesuai dengan jumlah keluaran minimum yang ditentukan oleh pengguna.
Permintaan pesanan limit swap dieksekusi menggunakan OrderHandler.executeOrder, jika pesanan dibuat pada stempel waktu n , pesanan harus dieksekusi dengan harga Oracle setelah stempel waktu n .
Membuka atau menambah posisi pelaku long/short.
Permintaan pesanan peningkatan pasar dibuat dengan memanggil ExchangeRouter.createOrder, dengan menentukan:
Permintaan pesanan peningkatan pasar dieksekusi menggunakan OrderHandler.executeOrder, jika pesanan dibuat pada stempel waktu n , pesanan harus dieksekusi dengan harga Oracle setelah stempel waktu n .
Perintah kenaikan posisi pasif yang harus dieksekusi ketika harga token indeks cocok dengan harga yang dapat diterima yang ditentukan oleh pengguna.
Contoh posisi panjang: jika harga token indeks saat ini adalah $5000, pesanan kenaikan batas dapat dibuat dengan harga yang dapat diterima sebesar $4990, pesanan dapat dieksekusi ketika harga token indeks <= $4990.
Contoh posisi pendek: jika harga token indeks saat ini adalah $5000, pesanan kenaikan batas dapat dibuat dengan harga yang dapat diterima sebesar $5010, pesanan dapat dieksekusi ketika harga token indeks >= $5010.
Permintaan pesanan peningkatan batas dieksekusi menggunakan OrderHandler.executeOrder, jika pesanan dibuat pada stempel waktu n , pesanan harus dieksekusi dengan harga Oracle setelah stempel waktu n .
Menutup atau mengurangi posisi pelaku long/short.
Permintaan pesanan penurunan pasar dibuat dengan memanggil ExchangeRouter.createOrder, dengan menentukan:
Permintaan pesanan penurunan pasar dieksekusi menggunakan OrderHandler.executeOrder, jika pesanan dibuat pada stempel waktu n , pesanan harus dieksekusi dengan harga Oracle setelah stempel waktu n .
Perintah penurunan posisi pasif yang harus dieksekusi ketika harga token indeks cocok dengan harga yang dapat diterima yang ditentukan oleh pengguna.
Contoh posisi panjang: jika harga token indeks saat ini adalah $5000, pesanan penurunan batas dapat dibuat dengan harga yang dapat diterima sebesar $5010, pesanan dapat dieksekusi ketika harga token indeks >= $5010.
Contoh posisi pendek: jika harga token indeks saat ini adalah $5000, pesanan penurunan batas dapat dibuat dengan harga yang dapat diterima sebesar $4990, pesanan dapat dieksekusi ketika harga token indeks <= $4990.
Permintaan pesanan penurunan batas dieksekusi menggunakan OrderHandler.executeOrder, jika pesanan dibuat pada stempel waktu n , pesanan harus dieksekusi dengan harga Oracle setelah stempel waktu n .
Perintah penurunan posisi pasif yang harus dieksekusi ketika harga token indeks melewati harga yang dapat diterima yang ditentukan oleh pengguna.
Contoh posisi panjang: jika harga token indeks saat ini adalah $5000, order penurunan stop-loss dapat dibuat dengan harga yang dapat diterima sebesar $4990, order dapat dieksekusi ketika harga token indeks <= $4990.
Contoh posisi short: jika harga token indeks saat ini adalah $5000, order penurunan stop-loss dapat dibuat dengan harga yang dapat diterima sebesar $5010, order dapat dieksekusi ketika harga token indeks >= $5010.
Permintaan order penurunan stop-loss dieksekusi menggunakan OrderHandler.executeOrder, jika order dibuat pada stempel waktu n , maka harus dieksekusi dengan harga oracle setelah stempel waktu n .
Harga ETH adalah 5000, dan ETH memiliki 18 desimal.
Harga satu unit ETH adalah 5000 / (10 ^ 18), 5 * (10 ^ -15) .
Untuk menangani desimal, kalikan nilainya dengan (10 ^ 30) .
Harga akan disimpan sebagai 5000 / (10 ^ 18) * (10 ^ 30) => 5000 * (10 ^ 12) .
Untuk optimalisasi gas, harga tersebut dikirimkan ke oracle dalam bentuk nilai pengali desimal uint8 dan nilai harga uint32.
Jika nilai pengali desimal diatur ke 8, nilai uint32 akan menjadi 5000 * (10 ^ 12) / (10 ^ 8) => 5000 * (10 ^ 4) .
Dengan konfigurasi ini, harga ETH dapat memiliki nilai maksimum (2 ^ 32) / (10 ^ 4) => 4,294,967,296 / (10 ^ 4) => 429,496.7296 dengan presisi 4 desimal.
Harga BTC adalah 60.000, dan BTC memiliki 8 desimal.
Harga satu unit BTC adalah 60,000 / (10 ^ 8), 6 * (10 ^ -4) .
Harga akan disimpan sebagai 60,000 / (10 ^ 8) * (10 ^ 30) => 6 * (10 ^ 26) => 60,000 * (10 ^ 22) .
Nilai maksimum harga BTC: (2 ^ 64) / (10 ^ 2) => 4,294,967,296 / (10 ^ 2) => 42,949,672.96 .
Desimal presisi: 2.
Harga USDC adalah 1, dan USDC memiliki 6 desimal.
Harga satu unit USDC adalah 1 / (10 ^ 6), 1 * (10 ^ -6) .
Harga akan disimpan sebagai 1 / (10 ^ 6) * (10 ^ 30) => 1 * (10 ^ 24) .
Nilai maksimum harga USDC: (2 ^ 64) / (10 ^ 6) => 4,294,967,296 / (10 ^ 6) => 4294.967296 .
Desimal presisi: 6.
Harga DG adalah 0,00000001, dan DG memiliki 18 desimal.
Harga satu unit DG adalah 0.00000001 / (10 ^ 18), 1 * (10 ^ -26) .
Harga akan disimpan sebagai 1 * (10 ^ -26) * (10 ^ 30) => 1 * (10 ^ 3) .
Nilai maksimal harga DG : (2 ^ 64) / (10 ^ 11) => 4,294,967,296 / (10 ^ 11) => 0.04294967296 .
Desimal presisi: 11.
Rumus untuk menghitung berapa nilai pengali desimal yang harus disetel:
Desimal: 30 - (tanda desimal) - (jumlah desimal yang diinginkan untuk presisi)
Contoh perhitungan untuk WNT:
dataStreamPrice / (10 ^ 8) / (10 ^ 18) * (10 ^ 30)(5000 * (10 ^ 8)) / (10 ^ 8) / (10 ^ 18) * (10 ^ 30) = 5000 * (10 ^ 12)dataStreamPrice * multiplier / (10 ^ 30)(5000 * (10 ^ 8)) * (10 ^ 34) / (10 ^ 30) = 5000 * (10 ^ 12)Contoh perhitungan untuk WBTC:
dataStreamPrice / (10 ^ 8) / (10 ^ 8) * (10 ^ 30)(50,000 * (10 ^ 8)) / (10 ^ 8) / (10 ^ 8) * (10 ^ 30) = 50,000 * (10 ^ 22)dataStreamPrice * multiplier / (10 ^ 30)(50,000 * (10 ^ 8)) * (10 ^ 44) / (10 ^ 30) = 50,000 * (10 ^ 22) Rumus pengalinya adalah: 10 ^ (60 - dataStreamDecimals - tokenDecimals)
Biaya pendanaan memberi insentif pada keseimbangan posisi long dan short, pihak dengan open interest yang lebih besar membayar biaya pendanaan kepada pihak dengan open interest yang lebih kecil.
Biaya pendanaan untuk sisi yang lebih besar dihitung sebagai (funding factor per second) * (open interest imbalance) ^ (funding exponent factor) / (total open interest) .
Misalnya jika faktor pendanaan per detik adalah 1 / 50.000, dan faktor eksponen pendanaan adalah 1, dan bunga terbuka panjang adalah $150.000 dan bunga terbuka pendek adalah $50.000 maka biaya pendanaan per detik untuk jangka panjang adalah (1 / 50,000) * 100,000 / 200,000 => 0.00001 => 0.001% .
Biaya pendanaan per detik untuk celana pendek adalah -0.00001 * 150,000 / 50,000 => 0.00003 => -0.003% .
Dimungkinkan juga untuk menetapkan nilai financingIncreaseFactorPerSecond, yang akan menghasilkan logika pendanaan berikut:
longShortImbalance dihitung sebagai [abs(longOpenInterest - shortOpenInterest) / totalOpenInterest] ^ fundingExponentFactorlongShortImbalance saat ini lebih dari thresholdForStableFunding , maka tingkat pendanaan akan meningkat sebesar longShortImbalance * fundingIncreaseFactorPerSecondlongShortImbalance saat ini lebih dari thresholdForDecreaseFunding dan kurang dari thresholdForStableFunding dan kemiringannya searah dengan pendanaan, maka tingkat pendanaan tidak akan berubahlongShortImbalance saat ini kurang dari thresholdForDecreaseFunding dan kemiringannya searah dengan pendanaan, maka tingkat pendanaan akan turun sebesar fundingDecreaseFactorPerSecond Karena longShortImbalance > ambang batasForStableFunding, savingFundingFactorPerSecond akan meningkat sebesar 0.0001% * 6% * 600 = 0.0036%
Karena posisi long sudah membayar posisi short, kemiringannya tetap sama, dan longShortImbalance <thresholdForStableFunding, savingFundingFactorPerSecond tidak boleh berubah
Karena longShortImbalance <thresholdForDecreaseFunding, savingFundingFactorPerSecond akan berkurang sebesar 0.000002% * 600 = 0.0012%
Karena kemiringannya berlawanan arah, savingFundingFactorPerSecond akan berkurang sebesar 0.0001% * 1% * 600 = 0.0006%
Perhatikan bahwa ada beberapa cara yang memungkinkan untuk mempermainkan biaya pendanaan, faktor pendanaan harus disesuaikan untuk meminimalkan kemungkinan ini:
Jika longOpenInterest > shortOpenInterest dan longShortImbalance berada dalam ambang batasForStableFunding, pengguna yang memegang posisi short dapat membuka posisi long untuk meningkatkan longShortImbalance dan berupaya menyebabkan biaya pendanaan meningkat. Di pasar yang aktif, akan sulit untuk memprediksi kapan posisi short yang berlawanan akan dibuka oleh orang lain untuk mendapatkan peningkatan biaya pendanaan yang akan membuat permainan ini menjadi sulit, faktor pendanaan juga dapat disesuaikan untuk membantu meminimalkan keuntungan dari permainan ini. .
Jika longOpenInterest > shortOpenInterest dan longShortImbalance >thresholdForStableFunding, trader yang memegang posisi long dapat melakukan beberapa perdagangan kecil selama waktu ini untuk memastikan bahwa faktor pendanaan terus diperbarui dan bukan nilai yang lebih besar yang digunakan untuk keseluruhan durasi, hal ini akan meminimalkan biaya pendanaan untuk posisi buy tetapi tidak boleh menurunkan biaya pendanaan di bawah tingkat yang diharapkan.
Ada biaya pinjaman yang dibayarkan kepada penyedia likuiditas, hal ini membantu mencegah pengguna membuka posisi panjang dan pendek untuk mengambil kapasitas kumpulan tanpa membayar biaya apa pun.
Biaya peminjaman dapat menggunakan model kurva atau model kink.
Untuk menggunakan model kurva, kunci yang dikonfigurasi adalah BORROWING_FACTOR dan BORROWING_EXPONENT_FACTOR , faktor peminjaman per detik akan dihitung sebagai:
// reservedUsd is the total USD value reserved for positions
reservedUsd = MarketUtils.getReservedUsd(...)
// poolUsd is the USD value of the pool excluding pending trader PnL
poolUsd = MarketUtils.getPoolUsdWithoutPnl(...)
// reservedUsdAfterExponent is the reservedUsd after applying the borrowingExponentFactor for the market
reservedUsdAfterExponent = applyExponentFactor(reservedUsd, borrowingExponentFactor)
borrowingFactorPerSecond = borrowingFactor * reservedUsdAfterExponent / poolUsd
Untuk menggunakan model kink, kunci yang dikonfigurasi adalah OPTIMAL_USAGE_FACTOR , BASE_BORROWING_FACTOR dan ABOVE_OPTIMAL_USAGE_BORROWING_FACTOR , faktor peminjaman per detik akan dihitung sebagai:
// usageFactor is the ratio of value reserved for positions to available value that can be reserved
usageFactor = MarketUtils.getUsageFactor(...)
borrowingFactorPerSecond = baseBorrowingFactor * usageFactor
if (usageFactor > optimalUsageFactor) {
diff = usageFactor - optimalUsageFactor
additionalBorrowingFactorPerSecond = aboveOptimalUsageBorrowingFactor - baseBorrowingFactor
borrowingFactorPerSecond += additionalBorrowingFactorPerSecond * diff / (Precision.FLOAT_PRECISION - optimalUsageFactor)
}
Ada juga opsi untuk menyetel tanda skipBorrowingFeeForSmallerSide, hal ini akan mengakibatkan biaya pinjaman untuk pihak yang lebih kecil ditetapkan ke nol. Misalnya, jika ada lebih banyak posisi long daripada short dan skipBorrowingFeeForSmallerSide benar, maka biaya pinjaman untuk posisi short akan menjadi nol.
Kode dampak harga dapat ditemukan di /pricing contracts.
Dampak harga dihitung sebagai:
(initial USD difference) ^ (price impact exponent) * (price impact factor) - (next USD difference) ^ (price impact exponent) * (price impact factor)
Untuk swap, ketidakseimbangan dihitung sebagai selisih nilai token panjang dan token pendek.
Misalnya:
price impact exponent ditetapkan ke 2 dan price impact factor ditetapkan ke 0.01 / 50,0000 ^ 2 * (0.01 / 50,000) - 50,000 ^ 2 * (0.01 / 50,000) => -$50050,000 ^ 2 * (0.01 / 50,000) - 25,000 ^ 2 * (0.01 / 50,000) => $375Untuk aksi posisi (menaikkan/menurunkan posisi), ketidakseimbangan dihitung sebagai selisih open interest long dan short.
price impact exponents dan price impact factors dikonfigurasi per pasar dan dapat berbeda untuk pergerakan spot dan posisi.
Perhatikan bahwa perhitungan ini adalah dampak harga pada perdagangan pengguna, bukan dampak harga pada kumpulan. Misalnya, perdagangan pengguna mungkin mempunyai dampak harga 0,25%, perdagangan berikutnya dengan jumlah yang sangat kecil mungkin mempunyai dampak harga 0,5%.
Tujuan dari dampak harga adalah untuk:
Karena kontraknya menggunakan harga oracle yang merupakan harga rata-rata atau median dari beberapa bursa referensi. Tanpa dampak harga, mungkin akan menguntungkan untuk memanipulasi harga di bursa referensi saat mengeksekusi pesanan pada kontrak.
Risiko ini juga akan muncul jika nilai dampak harga positif dan negatif serupa, oleh karena itu dampak harga positif harus ditetapkan ke nilai yang rendah pada saat terjadi volatilitas atau pergerakan harga yang tidak teratur.
Untuk dampak harga pada kenaikan/penurunan posisi, jika dampak harga negatif dikurangkan sebagai jaminan dari posisi, hal ini dapat menyebabkan posisi tersebut memiliki leverage yang berbeda dari yang dimaksudkan pengguna, jadi alih-alih mengurangi jaminan, harga masuk/keluar posisi adalah disesuaikan berdasarkan dampak harga.
Misalnya:
Jika token indeks berbeda dari token pasar jangka panjang dan pendek, maka ada kemungkinan bahwa nilai kumpulan menjadi terpengaruh secara signifikan oleh kumpulan dampak posisi, jika kumpulan dampak posisi sangat besar dan token indeks memiliki harga yang besar. meningkatkan. Opsi untuk secara bertahap mengurangi ukuran kumpulan dampak posisi dapat ditambahkan jika hal ini menjadi masalah.
Dampak harga juga dilacak menggunakan nilai inventaris virtual untuk posisi dan swap, ini melacak ketidakseimbangan token di pasar serupa, misalnya ETH/USDC, ETH/USDT.
Jika terjadi pergerakan harga yang besar, kemungkinan sejumlah besar posisi diturunkan atau dilikuidasi di satu sisi menyebabkan ketidakseimbangan yang signifikan antara open interest jangka panjang dan pendek, hal ini dapat menyebabkan nilai dampak harga yang sangat tinggi. Untuk memitigasi hal ini, nilai faktor dampak posisi maksimal dapat dikonfigurasi. Jika dampak harga saat ini melebihi dampak harga negatif maksimal, maka kelebihan agunan yang dikurangi di luar dampak harga negatif maksimal akan dimasukkan dalam kontrak, jika tidak terdeteksi adanya manipulasi harga, agunan ini dapat dilepaskan ke pengguna. Ketika dampak negatif terhadap harga dibatasi, akan menguntungkan untuk membuka dan segera menutup posisi, karena dampak positif terhadap harga sekarang mungkin lebih besar daripada dampak negatif terhadap harga yang dibatasi. Untuk menghindari hal ini, dampak harga positif maksimal harus dikonfigurasikan agar berada di bawah dampak harga negatif maksimal.
Ada biaya swap dan biaya posisi yang dapat dikonfigurasi dan per pasar.
Biaya eksekusi juga diperkirakan dan diperhitungkan pada pembuatan permintaan deposit, penarikan, pesanan sehingga penjaga dapat mengeksekusi transaksi dengan biaya mendekati nol bersih.
Jika pasar memiliki stablecoin sebagai token jaminan pendek, maka pasar harus dapat membayar keuntungan pendek secara penuh jika bunga terbuka pendek maksimal tidak melebihi jumlah stablecoin di kumpulan.
Jika pasar memiliki token jaminan panjang yang berbeda dari token indeks, keuntungan jangka panjang mungkin tidak dibayarkan sepenuhnya jika kenaikan harga token indeks melebihi kenaikan harga token jaminan panjang.
Pasar memiliki faktor cadangan yang memungkinkan bunga terbuka dibatasi hingga persentase dari ukuran kumpulan, hal ini mengurangi dampak keuntungan dari posisi pendek dan mengurangi risiko bahwa posisi panjang tidak dapat dibayarkan sepenuhnya.
Harga token pasar bergantung pada nilai aset dalam kumpulan, dan PnL bersih posisi terbuka pedagang.
PnL yang tertunda mungkin saja dibatasi, faktor-faktor yang digunakan untuk menghitung harga token pasar dapat berbeda tergantung pada aktivitas:
Keys.MAX_PNL_FACTOR_FOR_DEPOSITS: ini adalah batasan faktor PnL saat menghitung harga token pasar untuk deposit
Keys.MAX_PNL_FACTOR_FOR_WITHDRAWALS: ini adalah batasan faktor PnL saat menghitung harga token pasar untuk penarikan
Keys.MAX_PNL_FACTOR_FOR_TRADERS: ini adalah batasan faktor PnL saat menghitung harga token pasar untuk menutup posisi
Faktor-faktor yang berbeda ini dapat dikonfigurasi untuk membantu penyedia likuiditas mengelola risiko dan memberi insentif pada setoran bila diperlukan, misalnya pembatasan PnL pedagang membantu membatasi jumlah penurunan harga token pasar karena PnL pedagang, pembatasan PnL untuk penyetoran dan penarikan dapat menyebabkan ke harga token pasar yang lebih rendah untuk setoran dibandingkan dengan penarikan yang dapat memberi insentif pada setoran ketika PnL yang tertunda tinggi.
minCollateralFactor: Ini menentukan rasio minimum yang diperbolehkan (jaminan posisi) / (ukuran posisi)
maxPoolAmount: Jumlah maksimum token yang dapat disimpan ke pasar
maxOpenInterest: Open interest maksimum yang dapat dibuka untuk suatu pasar
ReserveFactor: Ini menentukan rasio maksimum yang diperbolehkan (senilai token yang dicadangkan untuk posisi) / (token dalam kumpulan)
maxPnlFactor: Rasio maksimum (PnL / nilai token di kumpulan)
positionFeeFactor: Ini menentukan persentase jumlah biaya yang akan dipotong untuk tindakan kenaikan/penurunan posisi, besaran biaya didasarkan pada perubahan ukuran posisi
positionImpactFactor: Ini adalah "faktor dampak harga" untuk posisi yang dijelaskan di bagian "Dampak Harga".
maxPositionImpactFactor: Ini adalah "dampak harga maksimal" untuk posisi yang dijelaskan di bagian "Dampak Harga"
positionImpactExponentFactor: Ini adalah nilai "eksponen dampak harga" untuk tindakan posisi, dijelaskan di bagian "Dampak Harga"
swapFeeFactor: Ini menentukan jumlah persentase biaya yang akan dipotong untuk swap, jumlah biaya didasarkan pada jumlah swap
swapImpactFactor: Ini adalah "faktor dampak harga" yang dijelaskan di bagian "Dampak Harga".
swapImpactExponentFactor: Ini adalah nilai "eksponen dampak harga" untuk deposit dan swap, dijelaskan di bagian "Dampak Harga" di atas
financingFactor: Ini adalah nilai "faktor pendanaan per detik" yang dijelaskan di bagian "Biaya Pendanaan".
peminjamanFactorForLongs: Ini adalah "faktor peminjaman" untuk posisi buy yang dijelaskan di bagian "Biaya Pinjaman"
peminjamanFactorForShorts: Ini adalah "faktor peminjaman" untuk posisi short yang dijelaskan di bagian "Biaya Pinjaman"
peminjamanExponentFactorForLongs: Ini adalah "faktor eksponen peminjaman" untuk posisi buy yang dijelaskan di bagian "Biaya Pinjaman"
peminjamanExponentFactorForShorts: Ini adalah "faktor eksponen peminjaman" untuk posisi buy yang dijelaskan di bagian "Biaya Pinjaman"
Peran dikelola di RoleStore, RoleAdmin memiliki akses untuk memberikan dan mencabut peran apa pun.
RoleAdmin akan menjadi penyebar pada awalnya, namun ini harus dihapus setelah peran disiapkan.
Setelah pengaturan awal:
Hanya kontrak Timelock yang boleh memiliki peran RoleAdmin
Peran baru dapat diberikan oleh admin timelock dengan penundaan waktu
Nilai sistem hanya boleh ditetapkan menggunakan kontrak Config
Tidak ada EOA yang boleh memiliki peran Pengendali
Penjaga konfigurasi dan admin timelock berpotensi mengganggu operasi reguler melalui penonaktifan fitur, pengaturan nilai yang salah, memasukkan token berbahaya ke dalam daftar putih, menyalahgunakan nilai dampak harga positif, dll.
Multisig timelock diharapkan mencabut izin akun jahat atau yang disusupi
Penjaga pesanan dan penjaga pesanan yang dibekukan berpotensi mengekstraksi nilai melalui pemesanan transaksi, penundaan eksekusi transaksi, eksekusi ADL, dll. Hal ini sebagian akan dimitigasi dengan jaringan penjaga
Penandatangan Oracle diharapkan melaporkan harga token secara akurat
Token jaminan harus masuk daftar putih dengan TOKEN_TRANSFER_GAS_LIMIT yang dikonfigurasi
Rebasing token, token yang mengubah saldo saat transfer, dengan token burn, token dengan callback misalnya token ERC-777, dll, tidak kompatibel dengan sistem dan tidak boleh masuk daftar putih
Penjaga pesanan dapat menggunakan harga dari stempel waktu yang berbeda untuk membatasi pesanan dengan swap, yang akan menghasilkan jumlah output yang berbeda
Penjaga pesanan diharapkan memvalidasi apakah suatu transaksi akan dikembalikan sebelum mengirim transaksi untuk meminimalkan pemborosan gas
Penjaga pesanan dapat menyebabkan permintaan dibatalkan alih-alih dilaksanakan dengan mengeksekusi permintaan dengan bahan bakar yang tidak mencukupi
Jika suatu transaksi eksekusi membutuhkan gas dalam jumlah besar yang mendekati batas maksimum gas blok, maka dimungkinkan untuk melakukan stuffing blok untuk mencegah transaksi dimasukkan ke dalam blok.
Dalam blockchain tertentu, penjaga dapat memiliki kendali atas tx.gasprice yang digunakan untuk mengeksekusi transaksi yang akan mempengaruhi biaya eksekusi yang dibayarkan kepada penjaga.
Eksekusi order mungkin dicegah oleh pengguna jahat yang dengan sengaja menyebabkan pasar menjadi tidak seimbang sehingga mengakibatkan dampak harga yang tinggi, hal ini akan memakan banyak biaya dan sulit untuk mendapatkan keuntungan darinya.
Dampak harga dapat dikurangi dengan menggunakan posisi dan swap serta perdagangan lintas pasar, rantai, fork, dan protokol lainnya. Hal ini sebagian dapat diatasi dengan pelacakan inventaris virtual
Pengguna dapat mengurangi dampak harga dengan menggunakan posisi leverage yang tinggi, hal ini sebagian dimitigasi dengan nilai MIN_COLLATERAL_FACTOR_FOR_OPEN_INTEREST_MULTIPLIER
Perhitungan nilai dampak harga tidak memperhitungkan biaya dan efek yang dihasilkan dari dampak harga itu sendiri, untuk sebagian besar kasus efek pada perhitungan dampak harga harus kecil
Jarang tetapi mungkin bagi nilai kolam untuk menjadi negatif, ini bisa terjadi karena ImpactPoolamount dan PNL yang tertunda dikurangi dari nilai token di kolam renang
Karena perbedaan dampak harga posisi positif dan negatif, mungkin ada penumpukan jumlah token virtual dalam kumpulan dampak posisi yang akan mempengaruhi penetapan harga token pasar, kumpulan dampak posisi harus didistribusikan secara bertahap jika diperlukan
Inventaris Virtual melacak jumlah token di kolam, harus dipastikan bahwa token di setiap pengelompokan adalah jenis yang sama dan memiliki desimal yang sama, yaitu token panjang di seluruh kolam dalam kelompok harus memiliki desimal yang sama, token pendek di seluruh kolam Dalam kelompok harus memiliki desimal yang sama, dengan asumsi USDC memiliki 6 desimal dan dai memiliki 18 desimal, pasar seperti ETH-USDC, ETH-DAI tidak boleh dikelompokkan
ID virtual harus ditetapkan sebelum pembuatan pasar / daftar putih token, jika ditetapkan setelah perdagangan untuk token / pasar selesai, pelacakan tidak akan akurat dan mungkin perlu disesuaikan
Untuk L2 dengan sequencer, tidak ada validasi kontrak untuk memeriksa apakah sequencer L2 aktif, Oracle Keepers harus berhenti menandatangani harga jika tidak ada blok yang dibuat oleh sequencer, jika sequencer melanjutkan operasi reguler, penjaga oracle harus menandatangani harga untuk tersebut Blok terbaru menggunakan harga yang diambil terbaru
Jika sequencer L2 turun, dapat mencegah deposit ke posisi untuk mencegah likuidasi
Untuk transaksi yang dapat dieksekusi sepenuhnya menggunakan umpan harga di rantai, dimungkinkan untuk memanfaatkan harga basi karena latensi harga atau rantai yang sedang turun, penggunaan pakan harga on-rantai harus menjadi umpan latensi sementara dan rendah seharusnya digunakan sebagai gantinya setelah semua token didukung
Blok Re-org dapat memungkinkan pengguna untuk secara surut membatalkan pesanan setelah dieksekusi jika harga tidak bergerak dengan baik untuk pengguna, perawatan harus diambil untuk menangani kasus ini jika menggunakan kontrak pada rantai di mana re-org yang lama dimungkinkan
Memperbarui dan pembatalan pesanan dapat dijalankan di depan untuk mencegah eksekusi pesanan, ini seharusnya tidak menjadi masalah jika probabilitas yang berhasil berjalan kurang dari atau sama dengan 50%, jika probabilitasnya lebih tinggi dari 50%, biaya dan biaya dan biaya Dampak harga harus disesuaikan untuk memastikan bahwa strategi itu tidak menguntungkan bersih, menyesuaikan biaya UI atau diskon rujukan dapat digunakan untuk menyebabkan pembatalan pesanan
Dalam hal downtime blockchain atau oracle, pesanan dapat dieksekusi dengan harga yang sangat berbeda atau mungkin tidak dieksekusi jika harga yang dapat diterima pesanan tidak dapat dipenuhi
Ada ketergantungan pada keakuratan cap waktu blok karena harga oracle divalidasi terhadap nilai ini, untuk blockchains di mana node blockchain memiliki beberapa kontrol atas cap waktu, perawatan harus diambil untuk mengatur oracletimestampadjustment ke nilai yang akan membuat manipulasi dari cap waktu tidak menguntungkan
Fitur pergeseran GLV dapat dieksploitasi dengan meningkatkan pemanfaatan sementara di pasar yang biasanya memiliki pemanfaatan rendah. Setelah penjaga menjalankan shift, penyerang dapat menurunkan pemanfaatan kembali ke tingkat normal. Biaya posisi dan dampak harga harus dikonfigurasi dengan cara yang membuat serangan ini cukup mahal untuk menutupi kerugian GLV.
Di GLV mungkin ada pasar GM yang berada di atas pnltopoolfactorFortraders maksimum. Jika maxpnlfactorfordeposits pasar GM ini lebih tinggi dari maxpnlfactorfortraders maka pasar GM bernilai lebih rendah selama deposito daripada begitu pedagang menyadari laba capped mereka. Pengguna jahat dapat mengamati pasar GM dalam kondisi seperti itu dan menyetor ke GLV yang mengandungnya untuk mendapatkan dari ADL yang akan segera menyusul. Untuk menghindari maxpnlfactorfordeposits ini harus kurang dari atau sama dengan maxpnlfactorfortraders.
Secara teknis dimungkinkan untuk nilai pasar menjadi negatif. Dalam hal ini GLV tidak dapat digunakan sampai nilai pasar menjadi positif.
Token GM bisa menjadi tidak likuid karena faktor PNL yang tinggi atau USD yang dipesan tinggi. Pengguna dapat menyetor token GM tidak likuid ke GVL dan menarik likuiditas dari pasar yang berbeda, meninggalkan GLV dengan token tidak likuid. Parameter GLVMAXMAXMarkEtokenanceUSD dan GLVMAXMARKETTOKOKNACEAMOUNT harus memperhitungkan risiko pasar untuk menghindari terlalu banyak token GM dari pasar yang berisiko.
scripts/verifyFallback.ts dapat digunakan untuk memverifikasi kontraknpx hardhat verify , setelah itu semua kontrak markettoken harus diverifikasi karena kode sumber akan sama Jika kontrak baru ditambahkan yang dapat menyebabkan perbedaan dalam penetapan harga, misalnya token pasar antara kontrak lama dan baru, maka perawatan harus diambil untuk menonaktifkan kontrak lama sebelum kontrak baru diaktifkan
Protokol eksternal apa pun yang menggunakan kontrak pembaca atau perhitungan yang berpotensi ketinggalan zaman untuk penetapan harga harus diingatkan untuk menggunakan kontrak dan perhitungan terbaru, misalnya umpan harga rantai untuk token GM
Disarankan untuk mempublikasikan upaya terbaik Changelog yang mendokumentasikan perubahan penting yang harus disadari oleh integrasi, misalnya jika suatu bidang ditambahkan ke struct yang diteruskan ke fungsi panggilan balik, perubahan ini mungkin tidak jelas untuk integrasi
Jika kontrak digunakan untuk mendukung pasar sintetis ekuitas, perawatan harus diambil untuk memastikan bahwa pemisahan stok dan perubahan serupa dapat ditangani
Kontrak dengan peran "pengontrol" memiliki akses ke fungsi -fungsi penting seperti mengatur nilai -nilai data, karena ini, perawatan harus diambil untuk memastikan bahwa kontrak tersebut tidak memiliki fungsi atau fungsi generik yang dapat digunakan untuk mengubah nilai -nilai penting
Tes harus ditambahkan untuk berbagai jenis pasar, misalnya pasar hanya spot, pasar token tunggal
Pemesanan nilai -nilai di eventData untuk panggilan balik tidak boleh dimodifikasi kecuali sangat diperlukan, karena kontrak callback dapat merujuk nilai dengan indeks tetap
Perhatikan bahwa jika struktur yang diteruskan ke callback diubah, misalnya setoran, penarikan, pesanan struct, ini akan menyebabkan fungsi kontrak callback mengharapkan struct sebelumnya berhenti bekerja, karena ini, perubahan struct harus disorot ke integrasi
Jika sistem rujukan sedang digunakan, OrderHandler harus diberikan akses untuk memperbarui kode rujukan untuk pedagang
Deposito, penarikan, dan pesanan dapat dibatalkan jika persyaratan yang ditentukan dalam permintaan tidak dapat dipenuhi, misalnya jumlah min. Periksa di mana dana dan pengembalian dana gas akan dikirim ke pembatalan pada saat memastikan itu cocok dengan harapan.
Mengurangi pesanan posisi dapat menghasilkan dua token alih -alih satu token, jika penurunan posisi pertukaran gagal, ada kemungkinan bahwa jumlah output dan agunan mungkin tidak cukup untuk menutup biaya, menyebabkan pesanan tidak dieksekusi
Jika ada penyebaran besar, ada kemungkinan bahwa membuka / menutup posisi dapat secara signifikan mengubah harga min dan maksimal dari token pasar, ini seharusnya tidak dimanipulasi dengan cara yang menguntungkan
Perubahan nilai konfigurasi seperti funding_factor, stabil_funding_factor, pinjaman_factor, skip_borrowing_fee_for_smaller_side, pinjaman_fee_receiver_factor, dapat mengarah pada biaya tambahan untuk pengguna, itu juga bisa mengakibatkan perubahan harga pasar ToKens TOKENS
Jika pedagang PNL dibatasi karena max_pnl_factor_for_traders, persentase laba yang dibayarkan kepada pedagang mungkin berbeda tergantung pada pemesanan ketika posisi menurun / ditutup karena batasnya dihitung ulang berdasarkan keadaan saat ini dari kelompok saat ini dari kelompok saat ini dari kumpulan pool saat ini pool saat ini pool saat ini dari pool saat ini dari pool saat ini saat pool saat ini dari pool saat ini saat pool saat ini dari pool saat ini saat ini dari pool saat ini dari Pool saat ini saat ini dari Pool saat ini dari Pool saat ini saat ini dari Pool saat ini dari Pool saat ini saat ini dari Pool saat ini dari Pool saat ini saat ini dari Pool
Data peristiwa dapat diteruskan ke kontrak callback, pemesanan params di eventData akan dicoba tidak berubah, sehingga params dapat diakses dengan indeks, untuk keselamatan kunci param masih harus divalidasi sebelum digunakan untuk memeriksa apakah cocok dengan cocok nilai yang diharapkan
Beberapa parameter seperti order.Sizedelta dan order.InitialCollateralDeltAamount dapat diperbarui selama pelaksanaan
Saat membuat kontrak callback, kontrak panggilan balik mungkin perlu membuat daftar putih Deposithandler, OrderHandler, atau penarikan penarikan, perlu dicatat bahwa versi baru dari penangan ini dapat digunakan karena kode baru ditambahkan ke penangan, juga dimungkinkan bagi dua penangan untuk untuk dikenakan Untuk sementara ada pada saat yang sama, misalnya OrderHandler (1), OrderHandler (2), karena ini, kontrak panggilan balik harus dapat membuat daftar putih dan secara bersamaan menerima panggilan balik dari beberapa Deposithandlers, pesanan dan penarikan penawaran
Untuk kontrak callback alih -alih mempertahankan daftar putih terpisah untuk depositandler, pesanan, penarikan penarikan, solusi yang mungkin adalah untuk memvalidasi peran msg.sender di rolestore, misalnya RoleStore.hasRole(msg.sender, Role.CONTROLLER) , ini akan Periksa apakah msg.sender adalah penangan yang valid
Jika menggunakan kontrak seperti penukar, Oracle atau pembaca mencatat bahwa alamat mereka akan berubah saat logika baru ditambahkan
Jika kontrak seperti penukar, oracle atau pembaca diperbarui, upaya harus dilakukan untuk menjaga parameter fungsi tetap sama, namun, ini mungkin tidak selalu mungkin, misalnya jika properti pesanan baru akan didukung, paramer crateerDer harus diubah
Rolestore dan Datastore untuk penempatan tidak boleh berubah, jika mereka diubah migrasi dana dari kontrak sebelumnya ke kontrak baru kemungkinan akan diperlukan
Sementara kode telah disusun untuk meminimalkan risiko reentrancy baca saja, perawatan harus diambil untuk menjaga terhadap kemungkinan ini
Token Airdrops dapat terjadi pada akun pemegang token GM, mengintegrasikan kontrak yang memegang token GM harus dapat mengklaim token ini jika tidak token akan dikunci, implementasi yang tepat untuk ini akan bervariasi tergantung pada kontrak yang mengintegrasikan, satu kemungkinan untuk memungkinkan klaim Token yang bukan token pasar, ini dapat diperiksa menggunakan nilai Keys.MARKET_LIST
Transfer ETH dikirim dengan native_token_transfer_gas_limit untuk batas gas, jika transfer gagal karena gas yang tidak mencukupi atau kesalahan lainnya, ETH dikirim sebagai Weth sebagai gantinya
Akun dapat menerima ETH untuk ADLS / Likuidasi, jika akun tidak dapat menerima ETH maka Weth akan dikirim sebagai gantinya
Dampak harga positif dibatasi oleh jumlah token di kumpulan dampak dan berdasarkan nilai yang dikonfigurasi
Dampak harga negatif dapat dibatasi oleh nilai yang dikonfigurasi
Jika dampak harga negatif dibatasi, jumlah tambahan akan disimpan di kumpulan jaminan yang dapat diklaim, ini perlu diklaim secara manual menggunakan penukar. Fungsi klaimcollateral
Biaya pendanaan positif perlu diklaim secara manual menggunakan fungsi penukar.
Hadiah Afiliasi Perlu diklaim secara manual menggunakan Fungsi Exchangerouter.
Pasar atau fitur dapat dinonaktifkan
Eksekusi masih akan berlanjut bahkan jika panggilan balik kembali
Pastikan panggilan balik memiliki gas yang cukup
Subaccount dapat membuat, memperbarui, dan membatalkan pesanan apa pun untuk akun
Subaccount dapat menghabiskan Wnt dan agunan dari akun
Biaya UI dapat diubah
Diskon rujukan dapat diubah
Dana untuk alamat daftar hitam akan disimpan dalam protokol
Token indeks tidak selalu dijamin menjadi token panjang
Perubahan tarif biaya tergantung pada apakah ada dampak positif atau negatif
Pertimbangkan faktor PNL saat memperkirakan harga GM
Menangani pembatalan setoran
Pastikan hanya penangan dengan peran controller yang dapat menghubungi afterDepositexecution dan afterDepositCancellation Callback Functions
Pastikan hanya eksekusi setoran yang benar yang dapat menghubungi fungsi panggilan balik
Pertimbangkan pasar dengan token panjang dan pendek yang sama, swap tidak didukung untuk pasar ini
Pertimbangkan dampak harga positif dan negatif
Ada periode pembatalan permintaan untuk penundaan yang dikonfigurasi di mana permintaan setoran tidak dapat dibatalkan
Jumlah output tunduk pada dampak harga dan biaya
Setoran tidak diizinkan di atas max_pnl_factor_for_deposits
Deposit pertama di pasar mana pun harus pergi ke receiver_for_first_deposit
Dua output minimum harus digunakan untuk penarikan
Menangani pembatalan penarikan
Pastikan hanya penangan dengan peran controller yang dapat menghubungi Fungsi Panggilan Balik AfterWithDrawalExecution dan AfterDrawalCancellation
Pastikan hanya eksekusi penarikan yang benar yang dapat menghubungi fungsi panggilan balik
Pertimbangkan pasar dengan token panjang dan pendek yang sama, swap tidak didukung untuk pasar ini
Pertimbangkan dampak harga positif dan negatif
Ada periode pembatalan permintaan untuk penundaan yang dikonfigurasi di mana permintaan penarikan tidak dapat dibatalkan
Jumlah output tunduk pada dampak harga dan biaya
Penarikan tidak diizinkan di atas max_pnl_factor_for_withdrawals
Menangani pembatalan pesanan
Likuidasi dan ADL dapat memicu kontrak panggilan balik yang disimpan
Pesanan bisa menjadi beku
Pastikan hanya penangan dengan peran pengontrol yang dapat menghubungi afterorderexecution, afterordercancellation dan fungsi panggilan balik afterorderfrozen
Pastikan hanya eksekusi pesanan yang benar yang dapat menghubungi fungsi panggilan balik
Pertimbangkan pasar dengan token panjang dan pendek yang sama, swap tidak didukung untuk pasar ini
Pertimbangkan dampak harga positif dan negatif
Kontrak panggilan balik yang disimpan dapat diubah
Ada periode pembatalan permintaan untuk penundaan yang dikonfigurasi di mana permintaan pesanan tidak dapat dibatalkan
Jumlah output tunduk pada dampak harga dan biaya
Kolam dampak posisi didistribusikan ke penyedia likuiditas dari waktu ke waktu
Jika mencoba menghitung dampak harga, inventaris virtual harus dikonsultasikan
Trader PNL dibatasi di atas max_pnl_factor_for_traders
Dampak harga negatif dapat dibatasi pada penurunan posisi
Kurangi pesanan berukuran berukuran dan kolateraldelta akan diperbarui secara otomatis jika mereka lebih besar dari posisi yang dapat ditangani
Pertimbangkan validasi WillpositionCollateralBesuicient
Pertimbangkan decreasepositionswaptypes
Pertimbangkan jumlah agunan minimum
Referensi masih dibayarkan selama likuidasi
Adalah mungkin bagi posisi untuk memiliki nol jaminan
Posisi dengan ukuran nol tidak ada
Untuk menyusun kontrak:
npx hardhat compile
Untuk menjalankan semua tes:
npx hardhat test
export NODE_OPTIONS=--max_old_space_size=4096 mungkin diperlukan untuk menjalankan tes.
Untuk mencetak metrik kode:
npx ts-node metrics.ts
Untuk mencetak cakupan tes:
npx hardhat coverage
