सबसे तेज़ Stellar स्वैप के अंदर: मल्टी-रूट मूल्यांकन की व्याख्या

अधिकांश Stellar पर DEX इंटरफ़ेस आपके स्वैप के लिए एक ही रूट चुनते हैं। वे orderbook चेक करते हैं, शायद एक liquidity pool पर नज़र डालते हैं, और आपको एक नंबर दे देते हैं। Shadow Pocket कुछ मूलभूत रूप से अलग करता है — यह हर संभव रूट का समानांतर मूल्यांकन करता है और आपके ट्रेड का 100% उसी रूट से भेजता है जो सबसे अधिक output लौटाता है।

सिंगल-रूट स्वैप की समस्या

जब आप Stellar पर Asset A को Asset B में स्वैप करते हैं, तो कई संभव execution venues हैं:

• SDEX orderbook — ट्रेडर्स और market makers द्वारा रखे गए limit ऑर्डर।
• AMM liquidity pools — constant-product pools जहाँ कीमत एल्गोरिदम से निर्धारित होती है।
• Cross-pair पाथ — ऐसे रूट जो A से C और फिर C से B जाते हैं, intermediate एसेट्स को bridge के रूप में उपयोग करते हुए।

सिंगल-रूट दृष्टिकोण एक चुनता है और उम्मीद करता है कि वह सबसे अच्छा है। लेकिन liquidity हर ledger close (लगभग हर 5 सेकंड) के साथ बदलती रहती है। orderbook में कम गहराई पर शानदार कीमत हो सकती है लेकिन बड़ी राशि के लिए टूट सकती है। एक pool अपने continuous liquidity curve के कारण बड़े स्वैप्स के लिए बेहतर रेट दे सकता है। और कभी-कभी XLM या USDC के ज़रिए एक cross-pair पाथ दोनों direct विकल्पों से बेहतर होता है।

ग़लत अनुमान लगाने पर उपयोगकर्ता के असली पैसे खर्च होते हैं।

पैरेलल मूल्यांकन कैसे काम करता है

Shadow Pocket का backend हर कोट रिक्वेस्ट के लिए सभी उपलब्ध रूट्स का स्वतंत्र रूप से मूल्यांकन करता है। यह रहा फ़्लो:

1. Discovery — सिस्टम सभी व्यवहार्य रूट्स की पहचान करता है: direct orderbook, हर प्रासंगिक AMM pool, और प्रमुख bridge एसेट्स के ज़रिए cross-pair पाथ।
2. पैरेलल सिमुलेशन — प्रत्येक रूट को सटीक input राशि के साथ स्वतंत्र रूप से सिमुलेट किया जाता है। orderbook सिमुलेशन बुक को walk करता है, हर प्राइस लेवल पर ऑर्डर fill करता है। pool सिमुलेशन constant-product फ़ॉर्मूला का उपयोग करता है। path सिमुलेशन कई ऑपरेशंस को चेन करता है।
3. Output तुलना — प्रत्येक रूट विशिष्ट input साइज़ पर slippage को ध्यान में रखते हुए एक सिमुलेटेड output राशि लौटाता है।
4. विजेता चयन — सबसे अधिक output वाला रूट चुना जाता है। कोई splitting नहीं, कोई partial fills नहीं — ट्रेड का 100% सर्वश्रेष्ठ पाथ से होकर जाता है।

Backend हमेशा response में orderbook परिणाम पहले लौटाता है, उसके बाद pool रूट्स, ताकि frontend प्रति-रूट liquidity जानकारी प्रदर्शित कर सके, भले ही केवल सर्वश्रेष्ठ रूट ही निष्पादित हो।

100% एक रूट में क्यों (split क्यों नहीं)

Split routing सिद्धांत में समझदारी लगती है — अपने ट्रेड का कुछ हिस्सा orderbook से और कुछ pool से भेजें ताकि price impact कम हो। व्यवहार में, Stellar पर, यह ऐसी जटिलता लाती है जो शायद ही कभी फ़ायदेमंद हो:

• ट्रांज़ैक्शन फ़ीस नगण्य है — बैचिंग के लिए कोई gas ऑप्टिमाइज़ेशन कारण नहीं है।
• Atomic execution — Stellar ट्रांज़ैक्शन या तो पूरी तरह सफल होते हैं या पूरी तरह विफल। splitting ऑपरेशंस जोड़ती है जो partial failure की संभावना बढ़ाते हैं।
• Ledger timing — कीमतें हर 5 सेकंड बदलती हैं। जब तक split ऑर्डर निष्पादित होता है, optimal split अनुपात बदल चुका हो सकता है।

Stellar पर अधिकांश ट्रेड साइज़ के लिए, सिंगल सर्वश्रेष्ठ रूट से 100% भेजना किसी भी splitting रणनीति से बेहतर प्रदर्शन करता है। गणित सीधा है: सभी विकल्पों को सिमुलेट करो, विजेता चुनो।

SSE के ज़रिए लेजर-ट्रिगर रिफ्रेश

स्वैप कोट्स तेज़ी से पुराने होते हैं। Shadow Pocket उन्हें Stellar की ledger स्ट्रीम से जुड़े Server-Sent Events (SSE) का उपयोग करके ताज़ा रखता है:

1. Frontend /ledgers?cursor=now endpoint से एक SSE कनेक्शन खोलता है।
2. हर बार जब एक नया ledger close होता है (~5 सेकंड), event fire होता है।
3. Frontend debounce करता है और एक ताज़ा कोट रिक्वेस्ट ट्रिगर करता है।
4. Backend वर्तमान orderbook और pool स्थिति के साथ सभी रूट्स का पुनर्मूल्यांकन करता है।
5. UI प्रदर्शित रेट, output राशि, और प्रति-रूट ब्रेकडाउन अपडेट करता है।

इसका मतलब है कि उपयोगकर्ता हमेशा एक ऐसा कोट देखता है जो वर्तमान ledger स्थिति को दर्शाता है — 30 सेकंड पुराना कोई कोट नहीं जो काफ़ी बदल चुका हो।

कार्यान्वयन विवरण

कुछ इंजीनियरिंग निर्णय जो इसे विश्वसनीय रूप से काम करने योग्य बनाते हैं:

Debounce timer प्रबंधन — कोट रिफ्रेश debounce timer को setTimeout callback में ठीक से null किया जाना चाहिए। अगर timer reference stale है, तो UI अनिश्चित काल तक loading स्थिति दिखाते हुए अटक सकता है।

Loading state की स्वतंत्रता — स्वैप कोट loading इंडिकेटर abort signal चेक के बाहर reset किया जाता है। यह एक deadlock को रोकता है जहाँ एक aborted रिक्वेस्ट UI को स्थायी रूप से loading स्थिति में छोड़ देती है।

Service Worker bypass — SSE text/event-stream content type को Service Worker की precache लॉजिक से बाहर रखा गया है। इस bypass के बिना, Service Worker streaming कनेक्शन को इंटरसेप्ट कर लेता और रियल-टाइम अपडेट्स को तोड़ देता।

स्वतंत्र रूट मूल्यांकन — backend greedy दृष्टिकोण का उपयोग नहीं करता (पहले orderbook चेक करो, फिर शेष pool से भरो)। हर रूट का पूरी राशि के लिए स्वतंत्र रूप से मूल्यांकन किया जाता है, जिससे तुलना निष्पक्ष रहती है।

परिणाम

उपयोगकर्ता को एक स्वैप इंटरफ़ेस दिखता है जो रियल टाइम में अपडेट होता है, ठीक-ठीक दिखाता है कि उनका ट्रेड कौन सा रूट लेगा, और Stellar पर सभी execution venues में सर्वोत्तम उपलब्ध रेट की गारंटी देता है। कोई मैनुअल रूट चयन नहीं, कोई पुराने कोट्स नहीं, कोई splitting का अनुमान नहीं।

तेज़ स्वैप्स कच्ची स्पीड के बारे में नहीं हैं — ये इस बारे में हैं कि जब आप "Swap" दबाते हैं तो आपके पास हमेशा सबसे ताज़ी और सबसे सटीक जानकारी हो।