Uniswap v3 untuk Quant: Concentrated Liquidity dan Tick Math dari Prinsip Dasar

Posisi LP di Uniswap v3 sejatinya adalah range order ala limit-order-book yang menyamar. Deposit liquidity di antara dua harga, dan Anda telah berkomitmen untuk membeli aset saat harga turun melewati range Anda, dan menjualnya saat harga naik — persis seperti yang dilakukan sekumpulan limit order yang menunggu di sebuah CLOB. Namun smart contract tidak menyimpan harga, kuantitas, atau order book. Ia hanya menyimpan tiga angka: sebuah square-root price dalam fixed point Q64.96, sebuah integer tick index, dan sebuah nilai agregat liquidity $L$. Jika Anda ingin bernalar tentang posisi v3 sebagaimana Anda bernalar tentang quote dalam sebuah model market making — inventory, harga fill, adverse selection — Anda harus mampu menerjemahkan antara primitif on-chain tersebut dengan konsep trading yang mereka kodekan. Artikel ini membangun terjemahan tersebut dari prinsip dasar, mengikuti Uniswap v3 whitepaper (Adams, Zinsmeister, Salem, Keefer, Robinson, 2021) dan core contract-nya, dan berakhir di titik yang kini menjadi awal setiap diskusi LP yang serius: loss-versus-rebalancing.

Dari x·y = k ke virtual reserves

Uniswap v2 adalah constant-product market maker: sebuah pool menyimpan reserve $x$ dari token0 dan $y$ dari token1 dan menegakkan

pada setiap swap. Harga marginal token0 dalam satuan token1 adalah $P = y/x$, dan liquidity tersebar merata di seluruh sumbu harga $(0, \infty)$. Ini sangat tidak efisien secara modal: sepasang stablecoin yang diperdagangkan antara 0,999 dan 1,001 menyimpan lebih dari 99% modalnya pada harga-harga yang tidak akan pernah tercetak.

Langkah v3 adalah membiarkan setiap LP membatasi modalnya pada sebuah range $[p_a, p_b]$. Di dalam range, posisi tersebut harus berperilaku persis seperti pool v2 — bonding curve yang sama, penetapan harga marginal yang sama — namun hanya menggunakan reserve yang diperlukan untuk mencakup range tersebut. Whitepaper memformalkan ini dengan virtual reserves: posisi bertindak seolah-olah ia memegang reserve gaya v2 $(x_v, y_v)$ yang terletak pada kurva $x_v \cdot y_v = L^2$, sementara real reserves adalah virtual reserves dikurangi apa yang akan dipegang posisi tersebut di batas range:

Ini adalah persamaan 2.2 dari whitepaper, dan merupakan persamaan tunggal paling penting di v3. Kurva yang ditranslasikan menyentuh sumbu: pada $P = p_b$ reserve $x$ riil mencapai nol (posisi 100% token1), dan pada $P = p_a$ reserve $y$ riil mencapai nol (100% token0). Di luar range, posisi menjadi inert — sekantong tetap satu token, tidak menghasilkan apa pun.

Parameter $L$, disebut liquidity, adalah invariant yang menggantikan $k$. Ia didefinisikan sebagai $L = \sqrt{k}$, dan memiliki interpretasi yang jelas seperti yang ditegaskan whitepaper: liquidity adalah "virtual reserves per unit square-root price". Pada harga $P$ berapa pun di dalam range, virtual reserves adalah

Mengapa state variable-nya adalah √P

Core v3 tidak melacak harga. Ia melacak $\sqrt{P}$, disimpan sebagai sqrtPriceX96, sebuah unsigned fixed-point number Q64.96:

di mana $P$ adalah harga mentah (raw): token1 base unit per token0 base unit, termasuk desimal (lebih lanjut soal ini di bawah). Alasan penggunaan square root bukan soal penghematan gas, melainkan soal aljabar. Diferensiasikan identitas virtual reserve dan Anda mendapatkan dua persamaan swap fundamental, yang diimplementasikan dalam library SqrtPriceMath:

Kedua delta token bersifat linear terhadap square-root price (atau kebalikannya), dengan $L$ sebagai konstanta proporsionalitas. Sebuah swap dalam satu tick karenanya tidak memerlukan inversi kurva, tidak perlu iterasi Newton — cukup satu perkalian untuk menggerakkan $\sqrt{P}$, lalu dua perkalian untuk menghitung jumlahnya. Ketika sebuah swap cukup besar untuk mendorong harga melintasi tick yang sudah diinisialisasi, pool melintasinya, menambah atau mengurangi net liquidity yang direferensikan di sana (liquidityNet), dan melanjutkan dengan agregat $L$ yang baru. Secara global, pool adalah AMM constant-product piecewise: $L$ konstan di antara tick yang diinisialisasi, melompat di tick-tick tersebut.

Bagi seorang market maker, inilah model mental yang tepat: profil agregat $L(P)$ pool adalah padanan DEX dari kedalaman order book. Jika kedalaman CLOB dikuotasikan dalam unit per level harga, kedalaman AMM adalah $L$ per tick — dan konversinya persis identitas $\Delta y = L\Delta\sqrt{P}$ di atas.

Tick: grid harga berjarak logaritmik

Range tidak bisa mulai dan berakhir pada harga sembarang; mereka harus snap ke tick. Tick $i$ berkorespondensi dengan harga

sehingga setiap tick berjarak satu basis point dari tetangganya — bukan dalam istilah absolut, melainkan istilah relatif. Penjarakan logaritmik ini disengaja: grid aditif tetap akan sangat kasar untuk token yang diperdagangkan pada $0,0001 dan sangat halus pada $100.000, sementara grid geometris memberikan resolusi 1 bp yang seragam pada setiap skala harga. Library TickMath mengkonversi kedua arah — getSqrtRatioAtTick dan getTickAtSqrtRatio — menggunakan bit-twiddling atas konstanta yang telah dihitung sebelumnya, bukan memanggil fungsi eksponensial. Tick index dibatasi oleh MIN_TICK = -887272 dan MAX_TICK = 887272, yang mencakup range harga $[2^{-128}, 2^{128}]$: cukup luas untuk pasangan token apa pun yang bisa eksis dalam aritmetika uint256.

Tidak semua tick dapat digunakan. Setiap fee tier menerapkan tick spacing, dan posisi hanya boleh menggunakan tick yang habis dibagi olehnya:

Tier 0,05%/0,30%/1% dirilis saat peluncuran pada Mei 2021; tier 0,01% ditambahkan lewat voting governance pada November 2021. Spacing yang lebih kasar pada pool berfee tinggi menjaga jumlah tick yang berpotensi terlintasi tetap rendah dan biaya gas swap tetap terbatas.

Satu jebakan desimal yang menggigit semua orang cepat atau lambat: harga mentah on-chain adalah token1 per token0 dalam base unit. Di pool mainnet USDC/WETH, token0 adalah USDC (6 desimal) dan token1 adalah WETH (18 desimal), sehingga harga manusiawi $3.000 per ETH berkorespondensi dengan harga mentah $10^{12}/3000 \approx 3.333 \times 10^{8}$ WETH-wei per unit-USDC, yang berada pada tick

dengan $\texttt{sqrtPriceX96} \approx 1.4465 \times 10^{33}$. Jika dashboard monitoring Anda menunjukkan tick di sekitar 196k untuk USDC/WETH, sekarang Anda tahu alasannya — dan bahwa harga manusiawi adalah $\left(\texttt{sqrtPriceX96}/2^{96}\right)^2 \cdot 10^{\,\text{dec}_0 - \text{dec}_1}$ yang dibalik sesuai kebutuhan.

Jumlah token dari (L, price range): formula eksak

Inti dari bagian ini: diberikan sebuah posisi dengan liquidity $L$ pada $[p_a, p_b]$ dan harga saat ini $P$, apa yang dipegangnya? Mengintegrasikan persamaan swap sepanjang range menghasilkan tiga kasus:

Harga di bawah range ($P \le p_a$) — posisi 100% token0:

Harga di atas range ($P \ge p_b$) — posisi 100% token1:

Harga di dalam range ($p_a < P < p_b$):

Ini persis apa yang dihitung SqrtPriceMath.getAmount0Delta dan getAmount1Delta (dengan directed rounding — contract selalu membulatkan yang merugikan user, detail yang penting jika Anda mereplikasi ini di sebuah backtester dan bertanya-tanya soal diskrepansi level-wei).

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)

Contoh yang dikerjakan: ETH/USDC, range [2500, 3500]

Misalkan ETH diperdagangkan pada $P = 3000$ USDC dan Anda ingin deposit 1 ETH ke dalam range $[2500, 3500]$. Square root: $\sqrt{2500} = 50$, $\sqrt{3000} = 54,7723$, $\sqrt{3500} = 59,1608$.

Kaki ETH menentukan $L$:

Kaki USDC kemudian mengikuti:

Jadi minting posisi ini membutuhkan 1 ETH + 3.523,69 USDC, total nilai $6.523,69, dan perhatikan kedua kaki tidak 50/50 — pembagiannya bergantung di mana $P$ berada di dalam range (range asimetris adalah cara persis untuk mengekspresikan pandangan directional, atau menempatkan "range order" murni dengan satu token).

Sekarang jalankan harga ke batas-batasnya:

• Pada $P = 2500$ posisi telah sepenuhnya berubah menjadi ETH: $x = 738,37 \times (1/50 - 1/59,1608) = 2,2867$ ETH, senilai $5.716,68. Anda membeli 1,2867 ETH pada saat harga turun dengan harga rata-rata tertimbang liquidity sekitar 3523,69 / 1,2867 \approx \2.739$.
• Pada $P = 3500$ ia telah sepenuhnya berubah menjadi USDC: $y = 738,37 \times (59,1608 - 50) = 6.764,06$ USDC. Anda menjual ETH Anda saat harga naik dengan rata-rata $3.240.

Itulah pembacaan range-order yang menjadi konkret: posisi adalah sebuah tangga bid dari 3000 turun ke 2500 dan ask dari 3000 naik ke 3500, dengan ukuran per tick proporsional terhadap $L$. Dan concentration adalah apa yang membuat Anda dibayar: sebuah posisi full-range gaya v2 dengan modal $6.523,69 yang sama akan memiliki $L_{v2} = V/(2\sqrt{P}) = 59,55$ — posisi terkonsentrasi mengkuotasikan kedalaman 12,4× lebih besar per tick, dan (selagi berada di dalam range) memperoleh fee pada tingkat 12,4× per dolar modal.

Fee accounting: feeGrowthGlobal dan feeGrowthInside

Fee v3 tidak compound ke dalam posisi (sebuah perpecahan yang disengaja dari v2, di mana fee diinvestasikan kembali ke $\sqrt{k}$). Mereka terakumulasi berdampingan, per token, dan accounting-nya adalah sebuah mahakarya kecil dari pembukuan O(1) yang layak dipahami karena setiap pipeline analitik LP mengimplementasikan ulang skema ini.

Pool memelihara dua akumulator global, feeGrowthGlobal0X128 dan feeGrowthGlobal1X128: fee kumulatif per unit liquidity sejak inception pool, dalam fixed point Q128.128. Pada setiap swap, jumlah fee (diambil dari token input) dibagi dengan $L$ in-range saat ini dan ditambahkan ke akumulator. Ini adalah mekanisme di balik aturan kardinal ekonomi v3: fee hanya terakumulasi ke liquidity yang berada di dalam range pada saat swap terjadi. Posisi out-of-range bukan sekadar inventory yang inert — mereka memperoleh persis nol selama tidak aktif.

Untuk mengatribusikan potongan yang tepat dari growth global ke sebuah range terbatas, setiap tick $i$ yang diinisialisasi menyimpan feeGrowthOutside0/1X128 — fee growth yang terjadi di sisi lain dari tick relatif terhadap harga saat ini (nilainya membalikkan interpretasinya setiap kali tick tersebut dilintasi, yang membuat skema ini menjadi O(1)). Kemudian untuk sebuah posisi pada $[i_\ell, i_u]$ dengan tick saat ini $i_c$:

Setiap posisi menyimpan sebuah snapshot feeGrowthInsideLast, dan fee yang belum diklaim secara sederhana adalah

diperbarui secara lazy setiap kali posisi disentuh. Dua konsekuensi praktis. Pertama, delta feeGrowthInside adalah satu-satunya cara jujur untuk mengukur pendapatan fee sebuah posisi — mengambil sampel volume tingkat pool dan meratakannya berdasarkan pangsa TVL Anda akan salah setiap kali harga bergerak di sekitar batas range Anda. Kedua, karena fee duduk sebagai tokensOwed alih-alih compound, realized return LP memiliki komponen cash-drag yang tidak dimiliki v2; vault auto-compounding hadir persis untuk mengarbitrase hal ini (dikurangi fee mereka sendiri).

Payoff: short straddle yang membayar Anda untuk memegangnya (mungkin)

Di dalam range, nilai posisi sebagai fungsi dari harga adalah

Cekung (concave) terhadap $P$ — suku $2L\sqrt{P}$ adalah keseluruhan ceritanya. Di luar range ia menjadi linear: slope $x(p_a)$ di bawah (Anda long sekantong ETH tetap), slope 0 di atas (Anda flat dalam USDC). Jalankan contoh yang dikerjakan tadi sepanjang range dan bandingkan dengan sekadar memegang (HODL) token yang dideposit:

LP underperform terhadap HODL di kedua arah dan hanya menyamainya pada harga saat minting. Upside yang terbatas, partisipasi downside yang diperkuat, nilai relatif maksimum pada strike... ini adalah payoff dari sebuah short straddle (lebih tepatnya, setelah ekor linear dinetokan terhadap benchmark HODL, sebuah posisi short pada sekumpulan opsi yang di-strike sepanjang $[p_a, p_b]$). Aliran fee adalah premiumnya. Mengonsentrasikan range berarti memilih strike yang lebih rapat: lebih banyak premium per unit waktu selagi di dalam range, divergensi yang lebih cepat dan lebih dalam ketika harga bergerak. Setiap LP v3 adalah trader short-volatility, entah mereka memilihnya atau tidak — saudara on-chain dari trade-off inventory-risk yang diformalkan Avellaneda–Stoikov untuk market maker order-book, dengan lebar range berperan sebagai spread yang dikuotasikan.

Nama tradisional untuk celah dalam tabel tersebut adalah impermanent (divergence) loss, tetapi IL-versus-HODL adalah benchmark yang cacat: ia mencampuradukkan kerugian yang Anda alami sebagai liquidity provider dengan risiko pasar yang toh akan Anda tanggung. Dekomposisi yang lebih tajam datang dari Milionis, Moallemi, Roughgarden, dan Zhang (2022), "Automated Market Making and Loss-Versus-Rebalancing" (arXiv:2208.06046). Benchmark-kan LP bukan terhadap HODL melainkan terhadap sebuah rebalancing portfolio yang memegang, di setiap instan, kuantitas token yang sama dengan pool — tetapi bertransaksi pada harga pasar eksternal yang frictionless alih-alih melawan arbitrageur. Selisihnya adalah LVR ("lever"): komponen P&L LP yang murni adverse selection, dibayarkan kepada arbitrageur yang mengambil quote basi AMM setelah setiap pergerakan harga. Di bawah harga geometric-Brownian dengan volatilitas $\sigma$, LVR terakumulasi pada laju instantan

— sebuah "formula Black–Scholes untuk AMM", seperti yang dikatakan para penulisnya, dengan $|x'(P)|$ adalah kedalaman marginal pool pada harga saat ini. Untuk pool constant-product full-range, ini menyusut menjadi $\frac{\sigma^2}{8}$ nilai pool per unit waktu yang terkenal itu: pada volatilitas harian 5%, sekitar 3,1 bp dari pool mengalir ke arbitrageur setiap hari, ada fee atau tidak. Concentration mengalikan $|x'(P)|$ — contoh kedalaman 12,4× kita di atas juga merupakan mesin LVR ~12,4×. Fee harus mengungguli pendarahan tersebut agar posisi menjadi +EV, dan LVR (tidak seperti "IL") adalah biaya berjalan yang dapat di-hedge dan diprediksi, yang membuatnya menjadi unit of account yang tepat. Kalkulus profitabilitas lengkap — fee APR versus LVR versus volatilitas realized, kapan LP-ing mengalahkan short options yang di-delta-hedge — adalah subjek dari pembahasan mendalam impermanent loss dan LVR yang akan datang, dan mekanika hedging mendapatkan pembahasannya sendiri di strategi LP v3 dan hedging.

Satu biaya lagi hidup selapis lebih dalam: karena quote AMM hanya diperbarui saat seseorang bertransaksi, setiap posisi LP juga terekspos pada permainan mempool di sekitar transaksi tersebut — sandwich attack terhadap swapper yang membayar fee Anda, dan bundle arbitrase yang merealisasikan LVR Anda blok demi blok. Ekosistem tersebut dipetakan di artikel MEV dan sandwich-attack.

Membaca state pool on-chain

Semua hal di atas dapat diamati dari tiga panggilan murah terhadap pool contract.

slot0() mengemas state panas ke dalam satu storage slot: sqrtPriceX96, tick saat ini, indeks observasi oracle, dan flag protocol-fee/lock. liquidity() mengembalikan agregat $L$ in-range saat ini — perhatikan ini bukan TVL; ini adalah parameter kedalaman yang aktif pada tick saat ini dan melompat secara diskontinu ketika harga melintasi tick yang diinisialisasi. ticks(int24) mengembalikan state per-tick: liquidityGross (total $L$ yang mereferensikan tick tersebut), liquidityNet (signed $L$ yang ditambahkan saat melintasi dari kiri ke kanan), dan akumulator feeGrowthOutside. Mengiterasi liquidityNet melalui tick yang diinisialisasi (tickBitmap memberi tahu Anda tick mana saja yang eksis tanpa memindai 1,7 juta tick semuanya) merekonstruksi profil kedalaman penuh $L(i)$ — snapshot order book Anda.

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)

Posisi sendiri hidup di dua tempat. Core pool mengunci mereka dengan kunci (owner, tickLower, tickUpper) — satu slot agregat per triple owner-range. Ritel dan sebagian besar fund malah melakukan minting melalui periphery NonfungiblePositionManager (mainnet: 0xC36442b4a4522E871399CD717aBDD847Ab11FE88), yang membungkus setiap posisi dalam sebuah NFT ERC-721 dan mengekspos positions(tokenId) yang mengembalikan tuple lengkap: token, fee tier, range, $L$, feeGrowthInsideLast, dan tokensOwed. Untuk pemantauan portofolio, satu panggilan itu ditambah feeGrowthInside pool saat ini (dihitung ulang dari ticks() seperti pada bagian sebelumnya) memberi Anda nilai mark-to-market dan fee yang terakumulasi tanpa menyentuh indexer — meski untuk apa pun yang bersifat historis Anda akan membutuhkan replay swap-event atau sebuah subgraph, karena fee growth bersifat path-dependent dan chain hanya menyimpan akumulator saat ini.

Dua detail operasional yang layak diinternalisasi sebelum menyalurkan modal. Pertama, tick spacing mengkuantisasi ruang strategi Anda: pada tier 0,05% Anda dapat menempatkan range selebar 10 bp dan menjalankan sesuatu yang mendekati limit order sungguhan (mint tepat di atas/bawah spot, kumpulkan fee, burn setelah crossing — whitepaper secara eksplisit membingkai use case "range order" ini), sementara pada tier 1% range minimum Anda ~2% lebar dan analogi LOB-nya menjadi kasar. Kedua, sebuah range order adalah limit order tanpa prioritas pembatalan: jika harga melintasi range Anda dan kembali lagi, Anda round-trip inventory dan memberikan kembali edge tersebut (sambil tetap menyimpan fee-nya). Range yang pasif adalah quote yang tidak bisa Anda tarik kembali — persis mengapa pertanyaan frekuensi rebalancing, dan lensa LVR untuk menjawabnya, begitu penting.

Ke mana ini membawa Anda

Stack v3, dipadatkan: harga adalah tick pada grid geometris 1,0001; kedalaman adalah $L$, yang dapat dikonversi ke jumlah token melalui tidak lebih dari selisih square root; fee adalah sebuah akumulator per-$L$ yang Anda selisihkan sepanjang batas range Anda; dan posisi yang dihasilkan adalah sebuah range order short-vol yang biaya berjalannya punya nama, formula, dan nomor arXiv. Dengan primitif-primitif ini di tangan, pertanyaan-pertanyaan menarik menjadi kuantitatif: seberapa lebar, seberapa sering rebalance, dan apakah fee mengungguli LVR untuk pool dan rezim tertentu — yang persis di sanalah seri ini akan melanjutkan berikutnya.

Referensi

• Adams, H., Zinsmeister, N., Salem, M., Keefer, R., Robinson, D. (2021). Uniswap v3 Core (whitepaper).
• Library core Uniswap v3: 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.