Kantitatifler için Uniswap v3: Temel İlkelerden Konsantre Likidite ve Tick Matematiği

Uniswap v3'teki bir LP pozisyonu, kılık değiştirmiş bir limit-emir-defteri aralık emridir. İki fiyat arasına likidite yatırdığınızda, aralığınız boyunca fiyat düşerken varlığı satın almayı ve fiyat yükselirken satmayı taahhüt etmiş olursunuz — bu, tam olarak bir CLOB üzerinde bekleyen limit emirlerden oluşan bir ızgaranın yaptığı şeydir. Ama kontrat fiyatları, miktarları veya bir emir defterini saklamaz. Üç sayı saklar: Q64.96 sabit noktalı formatta bir karekök fiyat, bir tam sayı tick indeksi ve toplu bir likidite değeri $L$. Bir v3 pozisyonu hakkında, bir piyasa yapıcılığı modelinde kotasyonlar hakkında düşündüğünüz gibi düşünmek istiyorsanız — envanter, gerçekleşme fiyatları, olumsuz seçim — bu zincir üstü ilkellerle bunların kodladığı ticaret kavramları arasında çeviri yapabilmeniz gerekir. Bu makale, Uniswap v3 whitepaper'ını (Adams, Zinsmeister, Salem, Keefer, Robinson, 2021) ve temel kontratları izleyerek bu çeviriyi temel ilkelerden inşa eder ve her ciddi LP tartışmasının artık başladığı yerde biter: rebalans-göreli-kayıp (loss-versus-rebalancing).

x·y = k'dan sanal rezervlere

Uniswap v2, sabit çarpım piyasa yapıcısıdır: bir havuz token0'ın $x$ rezervini ve token1'in $y$ rezervini tutar ve her swap'ta

koşulunu zorunlu kılar. Token0'ın token1 cinsinden marjinal fiyatı $P = y/x$'tir ve likidite tüm fiyat ekseni $(0, \infty)$ üzerine düzgün biçimde yayılmıştır. Bu, aşırı derecede sermaye verimsizdir: 0.999 ile 1.001 arasında işlem gören bir stablecoin çifti, sermayesinin %99'undan fazlasını asla gerçekleşmeyecek fiyatlarda konumlandırmış olur.

v3'ün hamlesi, her LP'nin sermayesini bir $[p_a, p_b]$ aralığıyla sınırlamasına izin vermektir. Aralık içinde, pozisyon tam olarak bir v2 havuzu gibi davranmalıdır — aynı bağlanma eğrisi, aynı marjinal fiyatlama — ama yalnızca o aralığı kapsamak için gereken rezervleri kullanarak. Whitepaper bunu sanal rezervler ile formalize eder: pozisyon, $x_v \cdot y_v = L^2$ eğrisi üzerinde yer alan v2 tarzı rezervlere $(x_v, y_v)$ sahipmiş gibi davranırken, gerçek rezervler sanal rezervlerden aralık sınırlarında pozisyonun tutacağı miktarın çıkarılmasıyla elde edilir:

Bu, whitepaper'ın 2.2 numaralı denklemidir ve v3'teki en önemli tek denklemdir. Çevrilmiş eğri eksenlere değer: $P = p_b$'de gerçek $x$ rezervi sıfıra iner (pozisyon %100 token1'dir) ve $P = p_a$'da gerçek $y$ rezervi sıfıra iner (%100 token0). Aralığın dışında pozisyon hareketsiz hale gelir — tek bir tokenden oluşan sabit bir yığın, hiçbir şey kazanmaz.

Likidite olarak adlandırılan $L$ parametresi, $k$'nın yerini alan değişmezdir. $L = \sqrt{k}$ olarak tanımlanır ve whitepaper'ın açıkça belirttiği net bir yorumu vardır: likidite "karekök fiyat birimi başına sanal rezerv"dir. Aralık içindeki herhangi bir $P$ fiyatında, sanal rezervler şunlardır:

Durum değişkeni neden √P

v3'ün çekirdeği fiyatı takip etmez. sqrtPriceX96 olarak saklanan, işaretsiz bir Q64.96 sabit noktalı sayı olan $\sqrt{P}$'yi takip eder:

burada $P$ ham fiyattır: token0'ın taban birimi başına token1'in taban birimi, ondalıklar dahil (bununla ilgili daha fazlası aşağıda). Karekökün nedeni gaz optimizasyonu değil, cebirdir. Sanal rezerv özdeşliklerini türevleyin ve SqrtPriceMath kütüphanesinde uygulanan iki temel swap denklemini elde edersiniz:

Her iki token deltası da karekök fiyata (veya onun tersine) göre doğrusaldır, orantılılık sabiti olarak $L$ ile. Bu nedenle tek bir tick içindeki bir swap, eğri tersine çevirme veya Newton iterasyonu gerektirmez — $\sqrt{P}$'yi hareket ettirmek için tek bir çarpma, ardından miktarları hesaplamak için iki çarpma yeterlidir. Bir swap, fiyatı başlatılmış bir tick'in ötesine itecek kadar büyükse, havuz o tick'i geçer, orada referans verilen net likiditeyi (liquidityNet) ekler veya çıkarır ve yeni toplu $L$ ile devam eder. Küresel olarak havuz, parçalı-sabit-çarpımlı bir AMM'dir: başlatılmış tick'ler arasında sabit $L$, tick'lerde sıçramalar.

Bir piyasa yapıcı için doğru zihinsel model şudur: havuzun toplu $L(P)$ profili, emir defteri derinliğinin DEX karşılığıdır. CLOB derinliği fiyat seviyesi başına birim olarak kotalanırken, AMM derinliği tick başına $L$'dir — ve dönüşüm tam olarak yukarıdaki $\Delta y = L\Delta\sqrt{P}$ özdeşliğidir.

Tick'ler: logaritmik aralıklı bir fiyat ızgarası

Aralıklar keyfi fiyatlarda başlayıp bitemez; tick'lere oturmalıdır. Tick $i$, şu fiyata karşılık gelir:

böylece her tick komşularından bir baz puan uzaktadır — mutlak anlamda değil, göreli anlamda. Bu logaritmik aralıklama kasıtlıdır: sabit toplamalı bir ızgara, $0.0001'de işlem gören bir token için gülünç derecede kaba, $100.000'de ise gülünç derecede ince olurdu, oysa geometrik bir ızgara her fiyat ölçeğinde tekdüze 1 bp çözünürlük sağlar. TickMath kütüphanesi, üstel fonksiyon çağırmak yerine önceden hesaplanmış sabitler üzerinde bit manipülasyonu kullanarak her iki yönde de dönüşüm yapar — getSqrtRatioAtTick ve getTickAtSqrtRatio. Tick indeksleri MIN_TICK = -887272 ve MAX_TICK = 887272 ile sınırlıdır; bu, $[2^{-128}, 2^{128}]$ fiyat aralığını kapsar: uint256 aritmetiğinde var olabilecek herhangi bir token çifti için yeterince geniş.

Her tick kullanılabilir değildir. Her ücret katmanı bir tick aralığı dayatır ve pozisyonlar yalnızca buna bölünebilen tick'leri kullanabilir:

%0.05/%0.30/%1 katmanları Mayıs 2021'deki lansmanda kullanıma sunuldu; %0.01 katmanı Kasım 2021'de yönetişim oylamasıyla eklendi. Yüksek ücretli havuzlardaki daha kaba aralıklama, potansiyel olarak geçilebilecek tick sayısını ve swap gaz maliyetlerini sınırlı tutar.

Herkesi bir kez ısıran bir ondalık tuzağı: ham zincir üstü fiyat, taban birimlerinde token0 başına token1'dir. Mainnet USDC/WETH havuzunda token0 USDC'dir (6 ondalık) ve token1 WETH'tir (18 ondalık), böylece ETH başına $3.000'lık bir insan fiyatı, USDC-birimi başına yaklaşık $10^{12}/3000 \approx 3.333 \times 10^{8}$ WETH-wei'lik ham bir fiyata karşılık gelir ve şu tick'te yer alır:

$\texttt{sqrtPriceX96} \approx 1.4465 \times 10^{33}$ ile. İzleme panonuz USDC/WETH için 196k civarında bir tick gösteriyorsa, artık nedenini biliyorsunuz — ve insan fiyatının, gerektiği gibi ters çevrilmiş $\left(\texttt{sqrtPriceX96}/2^{96}\right)^2 \cdot 10^{\,\text{dec}_0 - \text{dec}_1}$ olduğunu.

(L, fiyat aralığı)'ndan token miktarları: kesin formüller

Bu bölümün temel çıktısı: $[p_a, p_b]$ üzerinde $L$ likiditesine sahip bir pozisyon ve mevcut fiyat $P$ verildiğinde, ne tutar? Swap denklemlerini aralık boyunca integralleştirmek üç durum verir:

Fiyat aralığın altında ($P \le p_a$) — pozisyon %100 token0'dır:

Fiyat aralığın üstünde ($P \ge p_b$) — pozisyon %100 token1'dir:

Fiyat aralık içinde ($p_a < P < p_b$):

Bunlar tam olarak SqrtPriceMath.getAmount0Delta ve getAmount1Delta'nın hesapladığı şeydir (yönlendirilmiş yuvarlama ile — kontrat her zaman kullanıcı aleyhine yuvarlar; bunu bir backtester'da yeniden üretip wei düzeyindeki tutarsızlıklar hakkında merak ediyorsanız önemli bir ayrıntı).

from math import sqrt

def position_amounts(L: float, pa: float, pb: float, P: float):
    """Token amounts held by a v3 position (float model; core uses Q96 ints)."""
    sa, sb, sp = sqrt(pa), sqrt(pb), sqrt(P)
    if P <= pa:
        return L * (1/sa - 1/sb), 0.0
    if P >= pb:
        return 0.0, L * (sb - sa)
    return L * (1/sp - 1/sb), L * (sp - sa)

Çözülmüş örnek: ETH/USDC, aralık [2500, 3500]

Diyelim ki ETH $P = 3000$ USDC'den işlem görüyor ve $[2500, 3500]$ aralığına 1 ETH yatırmak istiyorsunuz. Kareköller: $\sqrt{2500} = 50$, $\sqrt{3000} = 54.7723$, $\sqrt{3500} = 59.1608$.

ETH bacağı $L$'yi sabitler:

USDC bacağı ardından şu şekilde belirlenir:

Yani bu pozisyonu basmak 1 ETH + 3.523,69 USDC gerektirir, toplam değer $6.523,69 ve bacakların 50/50 olmadığına dikkat edin — bölünme, $P$'nin aralık içinde nerede oturduğuna bağlıdır (asimetrik bir aralık, tam olarak yönlü bir görüşü ifade etmenin veya tek bir tokenle saf bir "aralık emri" yerleştirmenin yoludur).

Şimdi fiyatı sınırlara doğru yürütün:

• $P = 2500$'de pozisyon tamamen ETH'ye dönüşmüştür: $x = 738.37 \times (1/50 - 1/59.1608) = 2.2867$ ETH, $5.716,68 değerinde. Düşüş sırasında 1,2867 ETH'yi yaklaşık 3523.69 / 1.2867 \approx \2{,}739$ likidite-ağırlıklı ortalama fiyattan satın aldınız.
• $P = 3500$'de tamamen USDC'ye dönüşmüştür: $y = 738.37 \times (59.1608 - 50) = 6{,}764.06$ USDC. ETH'nizi yükseliş sırasında ortalama $3.240'tan sattınız.

İşte aralık-emri okuması somutlaşmış hali: pozisyon aslında 3000'den 2500'e kadar bir alış merdiveni ve 3000'den 3500'e kadar bir satış merdivenidir, tick başına boyut $L$ ile orantılıdır. Ve konsantrasyon, size ödenen şeydir: aynı $6.523,69 sermayeye sahip tam aralıklı bir v2 tarzı pozisyon $L_{v2} = V/(2\sqrt{P}) = 59.55$ olurdu — konsantre pozisyon tick başına 12,4 kat daha fazla derinlik kotalar ve (aralık içindeyken) sermaye doları başına 12,4 kat oranında ücret kazanır.

Ücret muhasebesi: feeGrowthGlobal ve feeGrowthInside

v3 ücretleri pozisyona bileşik olarak eklenmez (fee'lerin $\sqrt{k}$'ye yeniden yatırıldığı v2'den kasıtlı bir kopuş). Bunlar token başına yan yana birikir ve muhasebe, her LP analitik hattının yeniden uyguladığı için anlaşılmaya değer küçük bir O(1) defter tutma başyapıtıdır.

Havuz iki küresel biriktirici tutar, feeGrowthGlobal0X128 ve feeGrowthGlobal1X128: havuzun kuruluşundan bu yana likidite birimi başına kümülatif ücretler, Q128.128 sabit noktalı formatta. Her swap'ta, ücret miktarı (girdi tokeninden alınır) mevcut aralık içi $L$'ye bölünür ve biriktiriciye eklenir. Bu, v3 ekonomisinin kardinal kuralının arkasındaki mekanizmadır: ücretler yalnızca swap anında aralık içinde olan likiditeye tahakkuk eder. Aralık dışı pozisyonlar yalnızca hareketsiz envanter değildir — etkin olmadıkları sürece tam olarak sıfır kazanırlar.

Küresel büyümenin doğru dilimini sonlu bir aralığa atfetmek için, başlatılmış her tick $i$, feeGrowthOutside0/1X128'i saklar — mevcut fiyata göre tick'in diğer tarafında meydana gelen ücret büyümesi (değer, tick her geçildiğinde yorumunu tersine çevirir, bu da şemayı O(1) yapan şeydir). Ardından $[i_\ell, i_u]$ üzerinde mevcut tick $i_c$'ye sahip bir pozisyon için:

Her pozisyon bir feeGrowthInsideLast anlık görüntüsü saklar ve tahsil edilmemiş ücretler basitçe

olarak, pozisyon her dokunulduğunda tembelce güncellenir. İki pratik sonuç var. Birincisi, feeGrowthInside deltaları, bir pozisyonun ücret gelirini ölçmenin tek dürüst yoludur — havuz düzeyindeki hacmi örnekleyip TVL'deki payınıza göre orantılamak, fiyat aralık sınırlarınızın etrafında dolaştığında her zaman yanlış sonuç verir. İkincisi, ücretler bileşik hale gelmek yerine tokensOwed olarak durduğundan, gerçekleşen LP getirilerinin v2'de olmayan bir nakit sürüklemesi (cash-drag) terimi vardır; otomatik bileşikleştiren kasalar tam olarak bunu arbitraj etmek için var olur (kendi ücretleri düşülerek).

Getiri: tutmanız için size (belki) ödenen bir kısa straddle

Aralık içinde, fiyatın bir fonksiyonu olarak pozisyon değeri şudur:

$P$'ye göre içbükeydir — $2L\sqrt{P}$ terimi tüm hikayedir. Aralığın dışında doğrusal hale gelir: altta eğim $x(p_a)$ (sabit bir ETH yığınında uzun pozisyondasınız), üstte eğim 0 (USDC'de düzsünüz). Çözülmüş örneğimizi aralık boyunca çalıştırıp, sadece yatırılan token'ları tutmakla karşılaştıralım:

LP, her iki yönde de HODL'den daha kötü performans gösterir ve yalnızca basım fiyatında ona denk gelir. Sınırlı yükseliş potansiyeli, güçlendirilmiş düşüş katılımı, striketa maksimum göreli değer... bu, bir kısa straddle'ın getirisidir (daha kesin olarak, doğrusal kuyruklar HODL kıyaslamasına karşı netleştirildikten sonra, $[p_a, p_b]$ boyunca vadeli bir opsiyon şeridinde kısa bir pozisyon). Ücret akışı primdir. Aralığı konsantre etmek, daha sıkı strike'lar seçmek demektir: aralık içindeyken zaman birimi başına daha fazla prim, fiyat hareket ettiğinde daha hızlı ve daha derin ayrışma. Her v3 LP'si, isteyerek veya istemeyerek bir kısa-volatilite tüccarıdır — bu, emir defteri piyasa yapıcıları için Avellaneda–Stoikov'un formalize ettiği envanter riski dengesinin zincir üstü kardeşidir, aralık genişliği kotalanan spread'in rolünü oynar.

Bu tablodaki açık için geleneksel isim geçici (ayrışma) kayıptır, ama IL-versus-HODL kusurlu bir kıyaslamadır: bir likidite sağlayıcı olarak aldığınız kaybı, zaten taşıyacağınız piyasa riskiyle birbirine karıştırır. Daha keskin ayrıştırma, Milionis, Moallemi, Roughgarden ve Zhang'in (2022) "Automated Market Making and Loss-Versus-Rebalancing" (arXiv:2208.06046) çalışmasından gelir. LP'yi HODL'e karşı değil, her an havuzla aynı token miktarlarını tutan ama arbitrajcılara karşı değil sürtünmesiz dış piyasa fiyatından işlem gören bir rebalans portföyüne karşı kıyaslayın. Fark LVR'dir ("kaldıraç"): LP kâr/zararının saf olumsuz seçim olan bileşeni, her fiyat hareketinden sonra AMM'nin bayat kotalarını avlayan arbitrajcılara ödenir. Volatilitesi $\sigma$ olan geometrik Brown hareketi altında, LVR anlık şu oranda tahakkuk eder:

— yazarların ifadesiyle "AMM'ler için bir Black–Scholes formülü", $|x'(P)|$ mevcut fiyattaki havuzun marjinal derinliği ile. Tam aralıklı sabit çarpım havuzu için bu, havuz değerinin zaman birimi başına ünlü $\frac{\sigma^2}{8}$'ine indirgenir: günlük %5 volatilitede, havuzun yaklaşık 3,1 baz puanı her gün arbitrajcılara kanar, ücretler olsun olmasın. Konsantrasyon $|x'(P)|$'yi çarpar — yukarıdaki 12,4 kat derinlik örneğimiz, aralık içindeyken aynı zamanda ~12,4 kat LVR makinesidir. Pozisyonun +EV olması için ücretlerin bu kanamayı geride bırakması gerekir ve LVR ("IL"in aksine) hedge edilebilir, öngörülebilir bir işletme maliyetidir — bu da onu doğru hesap birimi yapan şeydir. Tam kârlılık hesabı — ücret APR'sine karşı LVR'ye karşı gerçekleşen volatilite, LP yapmanın delta-hedge'li kısa opsiyonları ne zaman geçtiği — yaklaşan geçici kayıp ve LVR derin incelemesinin konusudur ve hedge mekanikleri kendi işlemesini v3 LP stratejileri ve hedge yazısında bulur.

Bir maliyet daha bir katman aşağıda yaşar: AMM kotaları yalnızca birisi işlem yaptığında güncellendiğinden, her LP pozisyonu aynı zamanda bu işlemlerin etrafında oynanan mempool oyunlarına da maruz kalır — ücretlerinizi ödeyen swapper'lara karşı sandviç saldırıları ve LVR'nizi blok blok gerçekleştiren arbitraj paketleri. Bu ekosistem MEV ve sandviç saldırısı yazısında haritalanmıştır.

Zincir üstünde havuz durumunu okumak

Yukarıdakilerin tümü, havuz kontratına karşı yapılan üç ucuz çağrıdan gözlemlenebilir.

slot0(), sıcak durumu tek bir depolama slotuna paketler: sqrtPriceX96, mevcut tick, oracle gözlem indeksleri ve protokol-ücreti/kilit bayrakları. liquidity(), mevcut aralık içi toplu $L$'yi döndürür — bunun TVL olmadığına dikkat edin; mevcut tick'te etkin olan derinlik parametresidir ve fiyat başlatılmış bir tick'i geçtiğinde süreksiz bir şekilde sıçrar. ticks(int24), tick başına durumu döndürür: liquidityGross (tick'e referans veren toplam $L$), liquidityNet (soldan sağa geçerken eklenen işaretli $L$) ve feeGrowthOutside biriktiricileri. Başlatılmış tick'ler üzerinde liquidityNet'i yineleme (tickBitmap, 1,7 milyon tick'in tümünü taramadan hangilerinin var olduğunu söyler), tam derinlik profilini $L(i)$'yi — emir defteri anlık görüntünüzü — yeniden inşa eder.

from web3 import Web3

w3 = Web3(Web3.HTTPProvider(RPC_URL))
pool = w3.eth.contract(address=POOL, abi=POOL_ABI)  # USDC/WETH 0.05%

sqrt_price_x96, tick, *_ = pool.functions.slot0().call()
L = pool.functions.liquidity().call()

raw_price = (sqrt_price_x96 / 2**96) ** 2          # token1/token0, base units
eth_usdc  = 1 / (raw_price * 10**(18 - 6))          # human USDC per ETH
depth_1tick = L * (1.0001**0.5 - 1) * (sqrt_price_x96 / 2**96)

Pozisyonların kendisi iki yerde yaşar. Çekirdek havuz onları (owner, tickLower, tickUpper) ile anahtarlar — sahip-aralık üçlüsü başına bir toplu slot. Perakende ve çoğu fon bunun yerine periferi NonfungiblePositionManager (mainnet: 0xC36442b4a4522E871399CD717aBDD847Ab11FE88) aracılığıyla basar; bu, her pozisyonu bir ERC-721 NFT'ye sarar ve tam demeti döndüren positions(tokenId)'yi ortaya çıkarır: token'lar, ücret katmanı, aralık, $L$, feeGrowthInsideLast ve tokensOwed. Portföy izleme için, bu tek çağrı artı havuzun mevcut feeGrowthInside'ı (önceki bölümdeki gibi ticks()'ten yeniden hesaplanır), bir indeksleyiciye dokunmadan size mark-to-market değer ve tahakkuk eden ücretler verir — ancak geçmişe dönük herhangi bir şey için swap-olay tekrarına veya bir subgraph'a ihtiyacınız olacak, çünkü ücret büyümesi yola bağımlıdır ve zincir yalnızca mevcut biriktiricileri saklar.

Sermaye dağıtmadan önce içselleştirmeye değer iki operasyonel ayrıntı var. Birincisi, tick aralığı strateji uzayınızı kuantalar: %0.05 katmanında 10 bp genişliğinde aralıklar yerleştirebilir ve gerçek bir limit emrine yakın bir şey çalıştırabilirsiniz (spot'un hemen üstüne/altına bas, ücreti topla, geçişten sonra yak — whitepaper bu "aralık emri" kullanım durumunu açıkça çerçeveler), oysa %1 katmanında minimum aralığınız ~%2 genişliğindedir ve LOB benzetmesi kabalaşır. İkincisi, bir aralık emri, iptal önceliği olmayan bir limit emirdir: fiyat aralığınızı geçip geri dönerse, envanteri gidiş-dönüş yaparsınız ve kenarı (edge) geri verirsiniz (ücretleri saklayarak). Pasif aralıklar, çekemeyeceğiniz kotalardır — bu, rebalans sıklığı sorusunun ve ona cevap vermek için LVR merceğinin bu kadar önemli olmasının tam nedenidir.

Sizi burada bırakan şey

v3 yığını, sıkıştırılmış haliyle: fiyatlar 1.0001-geometrik bir ızgara üzerindeki tick'lerdir; derinlik $L$'dir, karekök farklarından başka bir şey olmadan token miktarlarına dönüştürülebilir; ücretler, aralık sınırlarınız boyunca farkını aldığınız $L$ başına bir biriktiricidir; ve ortaya çıkan pozisyon, işletme maliyetinin bir adı, bir formülü ve bir arXiv numarası olan kısa-volatilite aralık emridir. İlkeler elinizdeyken, ilginç sorular kantitatif hale gelir: ne kadar geniş, ne sıklıkla rebalans yapılmalı ve belirli bir havuz ve rejim için ücretler LVR'yi karşılıyor mu — bu tam olarak bu serinin bundan sonra gideceği yerdir.

Kaynakça

• Adams, H., Zinsmeister, N., Salem, M., Keefer, R., Robinson, D. (2021). Uniswap v3 Core (whitepaper).
• Uniswap v3 çekirdek kütüphaneleri: TickMath.sol, SqrtPriceMath.sol, Position.sol, Tick.sol.
• Milionis, J., Moallemi, C., Roughgarden, T., Zhang, A. L. (2022). Automated Market Making and Loss-Versus-Rebalancing. arXiv:2208.06046.