पर्कोलेटर प्रोटोकॉल: सोलाना पर पर्पेचुअल ट्रेडिंग

Solana पर Percolator perpetual प्रोटोकॉल को समझना — तकनीकी शब्दजाल के बिना।

Percolator क्या है?

Percolator एक ऑन-चेन perpetual futures प्रोटोकॉल है जो Solana पर बनाया गया है। सरल शब्दों में: यह लोगों को किसी एसेट (जैसे SOL) पर लीवरेज्ड लॉन्ग/शॉर्ट पोजीशन ट्रेड करने देता है जो कभी समाप्त नहीं होती, साझा वॉल्ट में संपार्श्विक रखते हुए और oracles (जैसे Chainlink, Pyth) से कीमतें आती हैं। यह प्रोटोकॉल प्रायोगिक और अनऑडिटेड है — केवल शैक्षिक और परीक्षण उद्देश्यों के लिए, प्रोडक्शन या वास्तविक फंड के लिए नहीं।

इसे एक विकेंद्रीकृत, प्रोग्रामेबल "perps engine" के रूप में सोचें: एक प्रोग्राम सभी मार्केट स्टेट को एक सिंगल स्लैब अकाउंट में रखता है, और बाहरी matcher प्रोग्राम यह परिभाषित करते हैं कि ट्रेड की कीमत कैसे लगाई जाती है।

यह पृथक्करण इसे लचीला बनाता है: आप स्टैंडर्ड या इनवर्टेड मार्केट, पैसिव LPs, या कस्टम AMM-स्टाइल प्राइसिंग चला सकते हैं।

Percolator प्रोटोकॉल — मुख्य विचार

1. स्लैब = एक मार्केट, एक बड़ा अकाउंट

एक सिंगल मार्केट के लिए सब कुछ एक ऑन-चेन अकाउंट में रहता है जिसे स्लैब कहा जाता है:

• हेडर — magic, version, admin, flags (जैसे बाइनरी मार्केट के लिए "resolved")।

• मार्केट कॉन्फिग — कोलैटरल मिंट, वॉल्ट, oracle फीड ID, invert/unit scale, फंडिंग और रिस्क-थ्रेशोल्ड पैरामीटर, वैकल्पिक oracle authority।

• रिस्क इंजन — वॉल्ट बैलेंस, इंश्योरेंस फंड, रिस्क params (मार्जिन, फीस, लिक्विडेशन), फंडिंग इंडेक्स, crank/sweep स्टेट, और 4096 तक अकाउंट (यूजर्स और LPs) का एक बिटमैप + ऐरे।

तो: एक स्लैब = एक perpetual (या एक बाइनरी) मार्केट।

एक और स्लैब डिप्लॉय करें = एक और मार्केट।

2. दो प्रकार के अकाउंट: यूजर्स और LPs

स्लैब में प्रत्येक अकाउंट या तो है:

• यूजर — एक ट्रेडर। वे संपार्श्विक जमा करते हैं, पोजीशन खोलते/बंद करते हैं (लॉन्ग = पॉजिटिव साइज, शॉर्ट = नेगेटिव साइज), और उनके पास PnL, मार्जिन, फंडिंग, आदि होता है।

• LP (लिक्विडिटी प्रोवाइडर) — लिक्विडिटी प्रदान करता है और ट्रेड के दूसरे पक्ष को लेता है। उनके पास भी पूंजी और एक पोजीशन है (यूजर पोजीशन के नेट के विपरीत जिन्हें उन्होंने मैच किया है)। LPs एक matcher (प्रोग्राम + कॉन्टेक्स्ट) से बंधे होते हैं जो यह परिभाषित करता है कि ट्रेड की कीमत कैसे लगाई जाती है।

अकाउंट इंडेक्स किए जाते हैं (0..N)। स्लैब एक बिटमैप के माध्यम से ट्रैक करता है कि कौन से इंडेक्स उपयोग किए जा रहे हैं और प्रत्येक अकाउंट की पूंजी, पोजीशन, एंट्री प्राइस, फंडिंग इंडेक्स, matcher program/context (LPs के लिए), और owner को स्टोर करता है।

3. Oracles प्राइस फीड करते हैं; वैकल्पिक Authority ओवरराइड करती है

कीमतें oracles (जैसे Pyth Pull feed ID या Chainlink) से आती हैं। स्लैब स्टोर करता है:

• मैक्स स्टेलनेस और कॉन्फिडेंस फिल्टर।

• वैकल्पिक oracle authority: यदि सेट है, तो एक admin कीमत पुश कर सकता है (परीक्षण, बाइनरी सेटलमेंट, या नियंत्रित वातावरण के लिए उपयोग किया जाता है)। जब authority प्राइस सेट और हाल की होती है, तो यह बाहरी फीड को ओवरराइड कर देती है।

तो: सामान्य ऑपरेशन = Pyth/Chainlink; विशेष मामले = admin-नियंत्रित प्राइस।

4. इनवर्टेड मार्केट्स

एक मार्केट इनवर्टेड हो सकता है: आंतरिक रूप से प्रोटोकॉल 1/price का उपयोग करता है (जैसे USD per SOL → SOL per USD)। यह तब उपयोगी है जब संपार्श्विक SOL है और आप "long USD / short USD" स्टाइल एक्सपोजर चाहते हैं: लॉन्ग = जब SOL नीचे जाता है तो लाभ, शॉर्ट = जब SOL ऊपर जाता है तो लाभ। वही रिस्क इंजन, अलग प्राइस व्याख्या।

5. Matchers: ट्रेड प्राइस कौन तय करता है?

ट्रेड दो तरीकों से हो सकते हैं:

• ट्रेड (no CPI) — केवल percolator प्रोग्राम चलता है। यूजर और LP साइन करते हैं; एक्जीक्यूशन और प्राइसिंग percolator के अंदर संभाली जाती है (जैसे ऑफ-चेन सहमत या एक सरल नियम द्वारा)। कोई अन्य प्रोग्राम कॉल नहीं किया जाता। परीक्षण या विश्वसनीय LP–यूजर पेयर के लिए अच्छा।
• ट्रेड (CPI) — Percolator CPI के माध्यम से एक बाहरी matcher प्रोग्राम को invoke करता है। Matcher (जैसे percolator-match) को oracle और उसका कॉन्टेक्स्ट पास किया जाता है, एक्जीक्यूशन प्राइस की गणना करता है, और इसे रिटर्न करता है। Percolator फिर उस प्राइस (साइज, फीस, मार्जिन) को लागू करता है और स्टेट अपडेट करता है।

CPI यहाँ Solana पर Cross-Program Invocation का मतलब है।

तो matchers "pricing layer" हैं: पैसिव (जैसे oracle ± 50 bps), vAMM-स्टाइल (spread + impact), या पूरी तरह कस्टम। प्रोटोकॉल लागू करता है कि LP का matcher program/context मैच करता है और matcher LP PDA को signer के रूप में वेरिफाई करता है (ताकि केवल उस LP की लिक्विडिटी का उपयोग किया जाए)।

6. Keeper Crank: फंडिंग, मार्क, और लिक्विडेशन

एक keeper crank एक परमिशनलेस इंस्ट्रक्शन है जो:

• Oracle और LP नेट पोजीशन से मार्क प्राइस और फंडिंग को अपडेट करता है।

• ओपन पोजीशन पर फंडिंग लागू करता है।

• लिक्विडेशन/फोर्स-क्लोज लॉजिक चलाता है (जैसे अंडर-मेंटेनेंस-मार्जिन अकाउंट oracle प्राइस पर लिक्विडेट हो जाते हैं; डस्ट पोजीशन साफ हो जाती हैं)।

फंडिंग की गणना LP इन्वेंटरी से ऑन-चेन की जाती है ताकि लॉन्ग/शॉर्ट एक-दूसरे को भुगतान करें (और प्रोटोकॉल एक कट ले सकता है)। रिस्क-बढ़ाने वाले ट्रेड के लिए "हाल ही" की crank (जैसे ~200 स्लॉट के भीतर) की आवश्यकता होती है ताकि मार्क और फंडिंग अप टू डेट हों।

7. इंश्योरेंस और रिस्क

• एक इंश्योरेंस फंड (admin या फीस द्वारा टॉप अप किया गया) नुकसान को अवशोषित करता है जब पोजीशन लिक्विडेट या फोर्स-क्लोज की जाती हैं। एक थ्रेशोल्ड है; इसके नीचे, मार्केट "risk reduction only" में प्रवेश कर सकता है (केवल पोजीशन-रिड्यूसिंग ट्रेड की अनुमति है)।

• Haircut-ratio लॉजिक (O(1) एग्रीगेट्स: टोटल कैपिटल, पॉजिटिव PnL) का उपयोग किया जाता है ताकि सिस्टम भारी ADL sweep के बिना इन्सॉल्वेंसी को संभाल सके। संरक्षण बनाए रखा जाता है: vault ≥ capital + insurance + positive PnL (छोटे राउंडिंग टॉलरेंस के साथ)।

8. बाइनरी / प्रीमार्केट्स

वही स्लैब एक बाइनरी (इवेंट) मार्केट के रूप में उपयोग किया जा सकता है: आउटकम YES/NO। Admin एक oracle authority सेट करता है, एक सेटलमेंट प्राइस पुश करता है (जैसे 1.0 = YES, ~0 = NO), फिर resolve-market कॉल करता है। उसके बाद, कोई नया ट्रेड/डिपॉजिट नहीं; keeper crank सभी पोजीशन को सेटलमेंट प्राइस पर फोर्स-क्लोज कर देता है। एक बार सब कुछ बंद होने के बाद, admin इंश्योरेंस निकाल सकता है और यूजर्स शेष पूंजी निकाल सकते हैं। तो: perpetuals और इवेंट सेटलमेंट दोनों के लिए एक कोडबेस।

उपयोग के मामले

1. Perpetual Futures (स्टैंडर्ड या इनवर्टेड)

• स्टैंडर्ड: जैसे SOL/USD perp जिसमें SOL या USDC संपार्श्विक के रूप में; long/short SOL।

• इनवर्टेड: जैसे SOL संपार्श्विक, प्राइस = USD शर्तों में 1/SOL; long = bullish USD (bearish SOL), short = bearish USD (bullish SOL)। अच्छा है जब आप SOL में संपार्श्विक रखना चाहते हैं और "SOL ऊपर या नीचे जाने" पर एक दृष्टिकोण व्यक्त करना चाहते हैं।

CLI (या SDK) का उपयोग करें: init market → init user → deposit → run keeper crank → trade (trade-cpi या trade-nocpi)। दोनों के लिए वही फ्लो, केवल invert और unit_scale init-market में अलग हैं।

2. लिक्विडिटी प्रोविजन (पैसिव या vAMM)

• पैसिव LP: एक matcher (जैसे percolator-match) एक फिक्स्ड spread (जैसे 50 bps) के साथ। LP संपार्श्विक जमा करता है, उस matcher कॉन्टेक्स्ट के साथ init-lp; ट्रेडर्स को oracle ± spread मिलता है।

• vAMM-स्टाइल LP: बेस spread + impact + fee के साथ matcher। छोटे साइज के लिए टाइटर spreads, बड़े के लिए वाइडर; आप ऐसे LPs को जोड़ने के लिए add-vamm-lp.ts जैसी स्क्रिप्ट चला सकते हैं। बॉट्स (जैसे random-traders.ts) सिम्युलेटेड प्राइस द्वारा सर्वश्रेष्ठ LP को रूट कर सकते हैं।

उपयोग का मामला: मार्केट-मेकिंग, spread/fees कमाना, या अपने खुद के matcher में एक कस्टम प्राइसिंग स्ट्रैटेजी चलाना।

3. Keeper / इन्फ्रास्ट्रक्चर

• Crank bot: हर कुछ सेकंड में keeper-crank कॉल करता है ताकि फंडिंग और मार्क फ्रेश हों और लिक्विडेशन चलें। रिस्क-बढ़ाने वाले ट्रेड के लिए आवश्यक (staleness चेक)।

• Liquidator: अकाउंट की निगरानी करता है और liquidate-at-oracle कॉल करता है जब एक अकाउंट मेंटेनेंस मार्जिन से कम हो। परमिशनलेस; liquidator एक फीस कमाता है।

उपयोग का मामला: पब्लिक गुड्स (crank) चलाएं या लिक्विडेशन फीस से लाभ कमाएं।

4. बाइनरी / इवेंट मार्केट्स (प्रीमार्केट्स)

• बिना बाहरी फीड के एक स्लैब बनाएं (जैसे Pyth feed ID = zeros, "Hyperp" मोड), इनिशियल मार्क प्राइस सेट करें (जैसे 0.5 = 50% implied), oracle authority को admin पर सेट करें।

• यूजर्स perp की तरह ट्रेड करते हैं; जब इवेंट resolve हो जाता है, admin push-oracle-price (YES=1e6, NO≈0), फिर resolve-market, फिर crank करें जब तक सभी पोजीशन फोर्स-क्लोज नहीं हो जातीं, फिर इंश्योरेंस और यूजर कैपिटल निकालें।

उपयोग का मामला: प्रेडिक्शन मार्केट्स, इवेंट कॉन्ट्रैक्ट्स, या कोई भी बाइनरी आउटकम जो एक सिंगल प्राइस पर सेटल होता है।

5. टेस्टिंग और स्ट्रेस टेस्टिंग

• Oracle authority: वास्तविक मार्केट को मूव किए बिना लिक्विडेशन, फंडिंग, या एज केसेज को टेस्ट करने के लिए फिक्स्ड या एक्सट्रीम प्राइसेज पुश करें।

• स्क्रिप्ट्स: जैसे stress-haircut-system.ts, stress-worst-case.ts, oracle-authority-stress.ts, pentest-oracle.ts सिक्योरिटी/स्ट्रेस के लिए; test-*.ts इनवेरिएंट्स और फ्लो के लिए।

• Devnet: setup-devnet-market.ts Chainlink और एक funded LP के साथ एक पूर्ण इनवर्टेड SOL/USD मार्केट बनाता है; आप इसके खिलाफ बॉट्स और टेस्ट चला सकते हैं।

उपयोग का मामला: प्रोटोकॉल टीमें, ऑडिटर्स, या इंटीग्रेटर्स mainnet से पहले व्यवहार को वैलिडेट कर रहे हैं।

6. Admin और पैरामीटर ट्यूनिंग

• update-config: फंडिंग horizon, K, scale, मैक्स premium, threshold floor/risk/interval/step/alpha/min/max (फंडिंग और risk-threshold व्यवहार) बदलें।

• set-risk-threshold, set-maintenance-fee: रिस्क और कॉस्ट को फाइन-ट्यून करें।

• topup-insurance, withdraw-insurance (जब resolved और empty हो): इंश्योरेंस फंड को मैनेज करें।

उपयोग का मामला: वोलैटिलिटी या डिमांड के अनुसार एडजस्ट करने वाले मार्केट ऑपरेटर्स।

संभावनाएं और दिशाएं

1. Solana पर Perpetuals

Percolator दिखाता है कि एक सिंगल-प्रोग्राम, सिंगल-स्लैब perpetual इंजन Pyth/Chainlink, मल्टिपल LPs, और परमिशनलेस crank/liquidators के साथ Solana पर रह सकता है। यह इसके लिए एक बेस है:

• पब्लिक perp मार्केट्स (जैसे SOL, BTC, ETH) SOL या stablecoin संपार्श्विक के साथ।

• इनवर्टेड मार्केट्स जहां संपार्श्विक नेटिव एसेट है और ट्रेडर्स पेयर के "दूसरी ओर" का लीवरेज्ड एक्सपोजर चाहते हैं।

2. Pluggable Matchers

क्योंकि प्राइसिंग बाहरी matcher प्रोग्राम में है, कोर प्रोटोकॉल मिनिमल और सिक्योर रहता है जबकि:

• टीमें रिस्क इंजन को बदले बिना नए matchers (जैसे order-book स्टाइल, RFQ, या hybrid) शिप कर सकती हैं।

• मल्टिपल matchers (passive, vAMM, आदि) एक मार्केट में सह-अस्तित्व में रह सकते हैं; ट्रेडर्स और बॉट्स सर्वश्रेष्ठ प्राइस चुनते हैं (जैसे best-price और random-traders में)।

संभावना: एक शेयर्ड perp इंजन के शीर्ष पर एक matcher ecosystem (सेंट्रल लिमिट ऑर्डर बुक, request-for-quote, volatility-sensitive spreads)।

3. बाइनरी और इवेंट मार्केट्स

वही स्लैब और रिस्क इंजन सेटलमेंट प्राइस पर resolve + force-close को सपोर्ट करता है, इसलिए:

• प्रेडिक्शन मार्केट्स और इवेंट कॉन्ट्रैक्ट्स उसी कोडबेस पर बनाए जा सकते हैं जैसे perps।

• ऑपरेटर्स एक डिप्लॉयमेंट और एक CLI/SDK के साथ perps और बाइनरी मार्केट्स दोनों चला सकते हैं।

संभावना: Solana पर यूनिफाइड "futures + events" लेयर।

4. कम्पोज़ेबिलिटी और ऑटोमेशन

• प्रोग्रामेटिक API: CLI इंस्ट्रक्शन और स्लैब पार्सिंग पर एक पतला wrapper है; रेपो के encode*, buildAccountMetas, और parse* फंक्शन एक छोटा SDK हैं। UIs, बॉट्स, और अन्य प्रोग्राम शीर्ष पर कंपोज़ कर सकते हैं।

• Keeper/liquidator इंसेंटिव्स: परमिशनलेस crank और liquidate-at-oracle तीसरे पक्षों को बिना अनुमति के इन्फ्रास्ट्रक्चर चलाने और फीस कमाने की अनुमति देते हैं।

संभावना: वॉलेट्स, aggregators, और ऑटोमेटेड स्ट्रैटेजीज के साथ इंटीग्रेशन।

केवल शैक्षिक उद्देश्यों के लिए। Percolator प्रोग्राम और यह CLI ऑडिट नहीं किए गए हैं। प्रोडक्शन या वास्तविक फंड के साथ उपयोग न करें। अपने जोखिम पर उपयोग करें।

स्रोत

यह लेख percolator-cli codebase (https://github.com/aeyakovenko/percolator-cli) और संबंधित repos (percolator, percolator-prog, percolator-match) पर आधारित है।

Percolator Protocol: Perpetual Trading on Solana मूल रूप से Medium पर Coinmonks में प्रकाशित हुआ था, जहां लोग इस कहानी को हाइलाइट करके और प्रतिक्रिया देकर बातचीत जारी रखे हुए हैं।