DeFi प्राइस ऑरेकल कीमतों को कैसे एकत्र और प्रकाशित करते हैं

ऑरेकल ब्लॉकचेन के बाहर की जानकारी को onchain कोड से जोड़ता है। ऋण प्रोटोकॉल collateral का मूल्य तय करने के लिए price feed पढ़ सकता है; derivative contract settlement या risk limit के लिए संदर्भ ले सकता है। कॉन्ट्रैक्ट प्रकाशित संख्या पढ़ता है, पर हर बाहरी exchange order book देखकर उचित बाजार मूल्य खुद नहीं चुनता।

“कीमत” asset/quote pair, protocol का redemption rate या कोई दूसरी माप हो सकती है। इसे बड़ी position के वास्तविक बिक्री भाव के समान न मानें। DEX swap price impact और slippage guide और mark price बनाम last trade अन्य अंतर बताते हैं। यहाँ सामान्य EVM push feeds पर ध्यान है, पूरे DeFi के एक नियम पर नहीं।

Chainlink के Offchain Reporting डिज़ाइन में oracle nodes offchain अवलोकन साझा कर रिपोर्ट पर सहमत होते हैं। Quorum रिपोर्ट पर हस्ताक्षर करता है; transmitter उसे transaction में भेजता है; aggregator हस्ताक्षर जाँचकर उत्तर, round ID और timestamp दिखाता है। Offchain Reporting docs इस डिज़ाइन में अवलोकनों का median प्रकाशित होने की व्याख्या करते हैं।

Consumer contract आम तौर पर पूरा aggregation दोबारा नहीं करता; वह feed proxy के latestRoundData() को call करता है। Proxy के पीछे aggregator बदल सकता है। सही नेटवर्क के लिए EVM guide और API reference देखें। अनेक nodes होना स्वतंत्र sources की गारंटी नहीं; वे उन्हीं exchanges या data providers पर निर्भर हो सकते हैं।

कई push feeds deviation threshold और heartbeat दोनों का उपयोग करते हैं। पिछली प्रकाशित कीमत से निर्धारित प्रतिशत बदलाव नया report trigger कर सकता है; बड़े बदलाव के बिना भी समय बीतने पर heartbeat update माँग सकता है। प्रत्येक feed का asset, network, threshold और heartbeat Data Feeds directory और feed address page पर देखें।

ये feed-specific शर्तें हैं, हर N सेकंड में update का वादा नहीं। छोटा बदलाव deviation threshold तक न पहुँचे; और report माँगे जाने के बाद भी उसे collect, transmit और block में include करना पड़ता है। इसलिए heartbeat सटीक arrival time या कभी stale न होने की गारंटी नहीं। Protocol को अपने उपयोग और asset की गति के अनुसार maximum age तय करनी चाहिए।

latestRoundData() round ID, answer, startedAt, updatedAt और answeredInRound देता है; API reference अंतिम field को deprecated बताता है। answer fixed-point integer है, सीधे dollar राशि नहीं। चुने feed का decimals() और description पढ़ें। यदि hypothetical BTC/USD feed 8 decimals के साथ 6,725,000,000,000 लौटाए, तो इसका अर्थ प्रति BTC $67,250 है।

Feed decimals और token decimals अलग हैं। ERC-20 मात्रा 18 decimals में हो सकती है जबकि price answer में 8; गुणा करने से पहले हर मान को अपनी इकाई के अनुसार scale करें। BTC/USD का अर्थ प्रति Bitcoin डॉलर है; USD/BTC उलटी इकाई है। Derived pair के लिए दोनों feeds को ठीक से scale करके सही क्रम में divide करें; denomination example BTC/USD और EUR/USD से BTC/EUR दिखाता है।

updatedAt नवीनतम round के update का समय है। Consumer इसे current block timestamp से तुलना कर application द्वारा तय अधिकतम आयु से पुराना उत्तर अस्वीकार कर सकता है। Feed के अनुसार nonzero timestamp, positive-price asset का positive answer और उचित bounds भी जाँचे जा सकते हैं। बहुत कसा हुआ bound वैध market move को रोक सकता है।

मान लें एक काल्पनिक lending market चार collateral tokens पर 75% factor देता है। 8 decimals के साथ पिछला answer 200,000,000,000, यानी प्रति token $2,000 है; borrowing ceiling 4 × $2,000 × 75% = $6,000 है। बाजार $1,820 पर आए तो गिरावट 9% है। उदाहरण के 10% deviation और 60-minute heartbeat के तहत update अभी न माँगा जाए; कम मूल्य से ceiling $5,460 बनती है।

यदि application पाँच मिनट से पुराने मूल्य अस्वीकार करती है और round बीस मिनट पुराना है, तो वह $2,000 answer के बजाय नया borrowing रोक सकती है। जाँच feed update नहीं करती; यह तय करती है कि stale data में कौन सी कार्रवाई होगी। Borrow, withdrawal, liquidation और repayment की प्रतिक्रिया अलग हो सकती है, क्योंकि सभी actions रोकना भी हानिकारक है। सभी संख्याएँ और triggers काल्पनिक हैं, वर्तमान feed config या सलाह नहीं।

कई L2 नेटवर्क में उपयोगकर्ता sequencer से transaction भेजते हैं। बंदी या वापसी पर लेनदेन देर से हो सकते हैं, सामान्य उपयोग रुक सकता है और orders बदले बाजार में बाद में execute हो सकते हैं। हाल का दिखने वाला price answer यह साबित नहीं करता कि execution path उपलब्ध था या सभी उपयोगकर्ता एक समय पर कार्य कर सके।

Chainlink अलग L2 Sequencer Uptime Feed बताता है: answer == 0 sequencer up और answer == 1 down है। startedAt status change का समय देता है; उदाहरण consumer status जाँचकर recovery के बाद तय grace period तक रुकता है, फिर price पढ़ता है। L2 Uptime Feed guide में सही address और network behavior देखें। Grace period न तो price refresh करता है, न pending transactions के पूरा होने की गारंटी देता है।

Quorum, median, deviation, heartbeat, age limit और sequencer status सीमित प्रश्नों का जवाब देते हैं। वे liquidity, asset की सही पहचान, source independence या किसी order size पर executable price की गारंटी नहीं देते। ताज़ा timestamp के साथ गलत या manipulated value हो सकती है; शांत बाजार में पुराना मूल्य फिर भी करीब हो सकता है।

कोई trigger price gap, congestion या scaling, pair selection, freshness और liquidation की code error खत्म नहीं करता। Quality Data Feeds guidance liquidity और dependencies जाँचने तथा stale, delayed, missing या unexpected data के लिए design करने को कहता है। Contract, governance, bridge, collateral और liquidation जोखिम बने रहते हैं। Stablecoin oracle price par redemption साबित नहीं करता; depeg guide पढ़ें।

सही chain, feed proxy, asset pair, quote currency, answer decimals और contract address पहचानें। Description को asset से मिलाएँ और दूसरे network का address copy न करें। जरूरत पड़ने पर source model और update history देखें। Chainlink बताता है कि aggregator नेटवर्क के अनुसार अलग हो सकते हैं, इसलिए contract code और config भी जाँचें।

फिर देखें answer कैसे इस्तेमाल होता है: amount/price scaling, updatedAt, maximum age और invalid value पर action। L2 में uptime feed, recovery timestamp, grace period और delayed transaction behavior जाँचें। असली contract logic पर stale-price और outage/recovery दोनों स्थितियाँ परखें। अलग price fields समझने के लिए mark price बनाम last trade देखें।