AMM या ऑर्डर बुक: DEX में कीमत कैसे बनती है

Decentralized exchange (DEX) को खरीद orders का उपलब्ध assets से मेल कराने के लिए कोई नियम चाहिए।

Automated market maker (AMM) में liquidity providers assets को pool या smart contract में रखते हैं और swap में मिलने वाली मात्रा pool की स्थिति से तय होती है।

Order-book market में प्रतिभागी तय कीमत और मात्रा के buy या sell प्रस्ताव डालते हैं; venue का matching engine उन्हें इकट्ठा करता है और अपने priority तथा execution नियम लागू करता है।

मुख्य अंतर यह है कि कीमत कौन तय करता है और liquidity कैसे उपलब्ध रहती है। Pool एक formula के अनुसार चलता है और हर swap के साथ reserves बदलते हैं।

Order book में लोग खुद चुनते हैं कि किस कीमत और कितनी मात्रा पर खरीदना या बेचना है; order उतनी ही कीमत और मात्रा पर liquidity देता है जितनी सचमुच पोस्ट की गई हो।

Uniswap का आधिकारिक overview AMM pools समझाता है।

HyperCore order book के दस्तावेज़ एक खास implementation का उदाहरण देते हैं।

सिर्फ़ venue का नाम नतीजा नहीं बताता। दो pools के reserves, fees और ranges अलग हो सकते हैं; एक ही asset की दो books में depth और नियम अलग दिख सकते हैं।

नीचे के आंकड़े price formation समझाने के लिए दो अलग, काल्पनिक liquidity profiles हैं। इनसे यह निष्कर्ष नहीं निकालना चाहिए कि एक market structure हमेशा बेहतर है।

सरल दो-asset v2 pool में x और y दोनों tokens के reserves हैं और x × y = k constant-product संबंध है। अगर x ETH और y USDC है, तो y ÷ x का अनुपात fees से पहले USDC प्रति ETH का अनुमानित marginal price देता है।

बड़ा swap pool को उसकी curve पर आगे ले जाता है: reserves का अनुपात बदलने पर अतिरिक्त token पाने के लिए दूसरे token की मात्रा बढ़ सकती है।

Quote किसी बाहरी exchange से आए ऐसे भाव पर निर्भर नहीं होता जिसे contract अपने-आप अपना ले।

Reserves की मौजूदा स्थिति और formula तय करते हैं कि दिए गए input में कितना output मिलेगा या किसी target output के लिए कितना input चाहिए।

यदि अलग-अलग pools और markets के बीच लाभकारी price gap हो तो arbitrage traders उनके बीच trade कर सकते हैं; लागत और प्रतिबंधों के बाद इससे relative prices पास आ सकती हैं।

Uniswap का protocol overview इस प्रक्रिया का वर्णन करता है। दूसरे AMM अलग curves या accounting नियम अपना सकते हैं।

AMM का अर्थ यह भी नहीं कि सभी liquidity positions समान हैं। Uniswap v2 में pool shares reserves का proportional हिस्सा दिखाते हैं; v3 में प्रत्येक provider अपनी price range चुन सकता है।

Uniswap v3 position guide range चुनने का तरीका बताती है।

Range तय करती है कि कौन-सी liquidity active है और price बाहर जाने पर position में कौन-से assets रह सकते हैं।

Order book कई price levels पर buy offers (bids) और sell offers (asks) दिखाती है। सबसे ऊँचा buy और सबसे कम sell क्रमशः best bid और best ask हैं।

इनके बीच का midpoint reference है; इसका अर्थ यह नहीं कि किसी भी आकार की trade उसी price पर execute हो जाएगी। Best ask पर उपलब्ध मात्रा से बड़ी खरीद अगले levels को खा सकती है और औसत execution price बढ़ा सकती है।

Limit order में प्रतिभागी market नियमों के अधीन price और size चुनता है।

Order पूरा भर सकता है, आंशिक रूप से भर सकता है या book में बना रह सकता है; venue और execution status के अनुसार उपयोगकर्ता उसका unfilled हिस्सा cancel कर सकता है।

Market order या aggressive limit order उपलब्ध offers को ले सकता है।

Hyperliquid के order-type दस्तावेज़ उसी venue के specific order types और शर्तें समझाते हैं। हर DEX में एक जैसे नियम मानकर न चलें।

HyperCore के लिए दस्तावेज़ price-time priority बताते हैं: एक ही price पर पहले आई order को पहले लिया जाता है। यह उस खास order book का sequencing rule है, सभी order markets का सार्वभौमिक नियम नहीं।

स्क्रीन पर दिखाई देने वाली offer भी transaction पहुँचने से पहले बदल या हट सकती है; visible depth एक समय-बद्ध snapshot है और market तथा latency पर निर्भर है।

नीचे की गणनाओं में fees और gas शामिल नहीं हैं। यह भी मानते हैं कि execution के दौरान दूसरी trades से reserves या दिखाए गए order sizes नहीं बदलते।

ये दो अलग liquidity profiles हैं, venues की निष्पक्ष ranking नहीं: हर उदाहरण में शुरुआत की depth अलग है।

बिना fees वाला AMM profile। Pool में शुरुआत में 1,000 ETH और 2,000,000 USDC हैं। शुरुआती marginal price 2,000,000 ÷ 1,000 = 2,000 USDC/ETH है और k = 1,000 × 2,000,000 = 2,000,000,000।

ठीक 100 ETH output लेने पर reserve में 900 ETH बचेंगे। x × y = k बनाए रखने के लिए USDC reserve 2,000,000,000 ÷ 900 = 2,222,222.22 USDC होना चाहिए।

इसलिए input 222,222.22 USDC है; औसत कीमत 222,222.22 ÷ 100 = 2,222.22 USDC/ETH होगी, जो शुरुआती 2,000 से 11.11% ऊपर है। Fees और gas शामिल नहीं हैं।

बिना fees वाला order-book profile। Midpoint 2,000 USDC/ETH मानें, best bid 1,999 और best ask 2,001 हो। उपलब्ध asks 20 ETH at 2,001, 30 ETH at 2,010, और 50 ETH at 2,030 हैं।

अगर दिखाए गए sizes उपलब्ध बने रहें तो 100 ETH की खरीद तीनों levels लेगी:

औसत कीमत 201,820 ÷ 100 = 2,018.20 USDC/ETH है, यानी midpoint से 0.91% अधिक। यहाँ भी fees और gas शामिल नहीं हैं और मानते हैं कि खरीद पूरी होने तक दिखाई गई मात्राएँ बनी रहती हैं।

11.11% और 0.91% का अंतर किसी winner का ऐलान नहीं करता। Pool और order-book levels अलग liquidity profiles हैं; reserves, offers या requested size बदलने से नतीजा बदल जाएगा।

वास्तविक तुलना में हर venue के लिए समान मात्रा, समय, units और सभी costs का उपयोग करना चाहिए।

Pool में liquidity provider (LP) assets जमा करता है ताकि दूसरे लोग reserves के विरुद्ध swap कर सकें। उसे version के नियमों और active liquidity के अनुसार swap fees का हिस्सा मिल सकता है।

Uniswap LP-fee guide समझाती है कि बँटवारा active position पर निर्भर करता है; pool fee कोई fixed return नहीं है।

v3 में range के बाहर position fee कमाने के लिए active नहीं रहती और उसमें एक ही asset का inventory जमा हो सकता है।

Order provider, जिसे कभी-कभी market maker कहते हैं, तय करता है कि कौन-सी price और size पोस्ट करनी है।

अगर सामने वाले उसकी offer का कुछ हिस्सा ही स्वीकारते हैं, तो partial fill होता है और बाकी inventory उसके पास रहती है; market नियमों के तहत वह unfilled हिस्सा edit या cancel कर सकता है।

Fill से पहले या तुरंत बाद market price बदलने पर order नुकसानदायक हो सकती है।

Inventory और adverse-selection का यह exposure उस token-mix बदलाव से अलग है जो pool curve LP की position में लाती है, हालांकि दोनों में price और execution risk है।

Market making manual, algorithmic या अलग-अलग प्रतिभागियों के जरिए हो सकती है। हर limit order professional strategy नहीं है और pool में deposit करने से asset composition समझने की जरूरत खत्म नहीं होती।

“Provider” की भूमिका liquidity देने का तरीका बताती है; इससे अलग protocols में custody, protection या आर्थिक नतीजे समान नहीं हो जाते।

v3 concentrated liquidity में provider price की lower और upper boundary चुन सकता है।

Price उस range के भीतर हो तो position active liquidity देती है; range से बाहर वह एक asset में बदल सकती है और price वापस आने तक fees कमाना रोक सकती है।

Uniswap का v3 position guide इस चुनाव को बताता है।

Narrow range अधिक कमाई की गारंटी नहीं है: इससे पूँजी मौजूदा price के करीब केंद्रित हो सकती है, पर monitoring, adjustment और अतिरिक्त transactions भी लग सकते हैं।

Order book में provider हर order का price और size चुनता है, साथ ही यह भी कि order कितनी देर या किन शर्तों पर active रहे।

Post-only, immediate-or-cancel और अन्य instructions का व्यवहार उसी venue की documented implementation पर निर्भर होता है।

Hyperliquid order types के नियम एक specific उदाहरण हैं; उन्हें दूसरी book पर लागू करने से पहले उसके नियम जाँचें।

Costs भी एक ही fee rate तक सीमित नहीं होते। Pool में swap fee, network, aggregator या interface cost हो सकती है; order book में product के अनुसार maker/taker fees, funding या दूसरे charges हो सकते हैं।

Routing एक trade को कई pools या venues में बाँट सकती है, जबकि custody और settlement उस system की architecture पर निर्भर करते हैं।

केवल AMM या order book होने से यह तय नहीं होता कि funds कौन रखता है, transaction कब final है या क्या protection है।

पहले अपना लक्ष्य तय करें: अभी निश्चित मात्रा swap करनी है, limit price लगानी है, कुछ समय liquidity देनी है या price range के आसपास inventory संभालनी है।

फिर curve या हर level पर उपलब्ध वास्तविक मात्रा, आपके size के लिए अनुमानित average price, liquidity की स्थिति और fill या withdrawal की शर्तें तुलना करें।

Uniswap का price impact और price slippage पर लेख quote का विश्लेषण करते समय उपयोगी execution concepts में फर्क बताता है।

Fees, gas, routing, latency, partial fills की संभावना और execution पूरा होने से पहले quote बदलने का जोखिम जोड़ें।

Ethereum पर transaction ordering और transactions को reorder, insert या exclude करके value निकालना MEV का हिस्सा है।

Ethereum की MEV guide इन mechanisms का वर्णन करती है।

वास्तविक असर chain, protocol, transaction और चुने हुए protections पर निर्भर है।

Liquidity देने से पहले यह भी आँकें कि price बदलने पर कौन-से assets आपके पास रहेंगे, position कब active है, fees कैसे गिनी जाती हैं और withdraw या adjust करने में कौन-सी transactions लगती हैं।

बिना अवधि, asset और size समान किए volume या headline fee rate की तुलना खरीद की औसत लागत से न करें। कोई भी market structure market या execution risk को guaranteed outcome में नहीं बदलता।

Trade से पहले venue, network या settlement system, exact market, price unit और order type पहचानें। AMM में assets, reserves, curve, range यदि हो और fees जाँचें।

Order book में bid, ask, हर level की depth, priority, order duration और partial fill होने पर नियम देखें। अगर interface aggregated quote दिखाता है तो पता करें कि वह कई sources जोड़ता है या कौन-सी costs शामिल नहीं हैं।

अपना requested size उपलब्ध depth से मिलाएँ, सिर्फ़ सबसे अच्छी displayed price से नहीं। Reference price, अनुमानित average price और अंत में settle हुई amount अलग रखें।

अगर liquidity दे रहे हैं, तो starting assets, range, management costs और tokens hold करने का alternative लिखें।

Custody, permissions, network, withdrawal mechanism और official docs की जाँच करें; यह न मानें कि quote mechanics उन दूसरे सवालों का जवाब भी देती है।

यह लेख mechanics समझाता है; यह किसी asset, exchange या strategy की recommendation नहीं है।

संबंधित विषयों के लिए ये guides पढ़ें:

LP pools, fees और impermanent loss.

DEX swap slippage.

Hyperliquid HIP-3 perps.