वाउचर का व्यावहारिक उदाहरण
यह उदाहरण वाउचर को जारी करने से लेकर पूल स्वैप, भुनाने के लिए प्रस्तुति, वादा पूरा करने और निस्तारण तक की यात्रा दिखाता है। यह शामिल भूमिकाएँ समझाता है; यह वादा नहीं करता कि कोई खास वाउचर, पूल, route या outcome उपलब्ध होगा।
यहाँ इस्तेमाल हुई परिभाषाओं के लिए अवधारणाएँ और शब्दावली देखें।
1. जारीकर्ता एक वादा प्रकाशित करता है
मान लें कि एक सामुदायिक रसोई digital meal voucher बनाती है। वाउचर जारी करने से पहले रसोई वह जानकारी प्रकाशित करती है जिसकी धारक को सोच-समझकर फैसला करने के लिए ज़रूरत है:
- रसोई की पहचान और संपर्क विवरण;
- एक वाउचर से मिलने वाला भोजन या दूसरी पेशकश;
- supply, unit, बताया गया value और काम पूरा करने की रसोई की क्षमता;
- वाउचर कहाँ और किन समयों में पेश किया जा सकता है;
- expiry date, booking process, fees, taxes या transfer restrictions; और
- प्रस्तुति, वादा पूरा करने, complaints, refunds, substitutions और दूसरे remedies की प्रक्रिया।
रसोई जारीकर्ता है। उसे यह जानकारी सही रखनी चाहिए, अपनी उचित क्षमता से अधिक वाउचर जारी नहीं करने चाहिए और धारकों ने जिन शर्तों पर वाउचर पाए थे, उनके अनुसार उन्हें स्वीकार करना चाहिए। टोकन बनाने या पेशकश प्रकाशित करने से वह क्षमता साबित नहीं होती और GEF जारीकर्ता नहीं बनता।
2. पूल प्रबंधक वाउचर को स्वीकार करता है
खाद्य सुरक्षा का प्रतिबद्धता पूल रसोई, उसके वाउचर की शर्तों और पूल के उद्देश्य की जाँच करता है। वाउचर स्वीकार होने पर पूल प्रबंधक लागू नियम प्रकाशित करता है, जिनमें शामिल हैं:
- पूल के लिए कौन जवाबदेह है;
- मौजूदा
SwapPoolमालिक, proxy administrator और महत्वपूर्ण dependency controllers; - स्वीकार की गई संपत्तियाँ;
- exchange-rate या quote बनाने की विधियाँ;
- token-balance caps, जिन्हें ऐप में ‘क्रेडिट सीमाएँ’ कहा जाता है;
- pool और protocol fees;
- inventory और liquidity निकालने की शक्तियाँ; और
- अलग से funded guarantee, reserve या support arrangement।
स्वीकृति का मतलब है कि पूल के configured rules उस वाउचर को अनुमति देते हैं। इससे वादा पूरा करने की क्षमता, नकद मूल्य या insurance साबित नहीं होता।
3. प्रतिभागी भंडार देता है
समर्थक लागू प्रकाशित शर्तों के तहत meal vouchers या दूसरी समर्थित संपत्ति SwapPool में भेजता है। उस जमा से उपलब्ध inventory बढ़ती है।
हस्तांतरण अपने आप Pool share या repayment, withdrawal, reward या governance power नहीं बनाता। ऐसा अधिकार अलग से बताई गई व्यवस्था से ही आना चाहिए।
4. धारक पूल स्वैप करता है
धारक Pool के ज़रिए किसी समर्थित संपत्ति को meal vouchers से बदलता है। दिखाई गई quote configured quoter से बना transaction parameter है; वह voucher का cash value या रसोई का काम साबित नहीं करती।
सीधा Pool swap input, output, Pool fee और किसी अतिरिक्त protocol fee को भेजकर blockchain पर settle होता है। यह अपने आप loan, जारीकर्ता द्वारा voucher भुनाना या वास्तविक दुनिया में वादा पूरा करना नहीं है।
5. धारक वाउचर पेश करता है
मौजूदा App में ‘भुनाएँ’ चुनने पर सामान्य send flow खुलता है और token owner का address पहले से भरा होता है। वाउचर वापस भेजना जारीकर्ता को प्रस्तुति का प्रमाण है; इससे अपने आप यह साबित नहीं होता कि रसोई ने भोजन दिया।
रसोई प्रस्तुति की जाँच करती है और अपनी प्रकाशित शर्तों के तहत वादा किया गया भोजन देती है।
6. जारीकर्ता वादा पूरा होना और निस्तारण दर्ज करता है
भोजन देने के बाद जारीकर्ता पूरी की गई units दर्ज करता है, ताकि उन्हें दो बार पेश न किया जा सके। प्रकाशित प्रक्रिया के अनुसार लौटे हुए voucher को प्राप्त, जला, रद्द या किसी और तरह निष्क्रिय किया जा सकता है।
अगर रसोई अपना वादा पूरा नहीं करती, तो धारक जारीकर्ता की प्रकाशित complaint या remedy process और लागू कानून में उपलब्ध अधिकार इस्तेमाल करता है। सिर्फ इसलिए कि App ने voucher दिखाया या Pool ने swap संभव किया, GEF या Pool प्रबंधक वाउचर भुनाने वाला पक्ष नहीं बनता।
App में ‘रिटायर वाउचर’ चुनना अलग है: इससे catalog listing छिपती है, जबकि balances और history बने रहते हैं और administrator उसे वापस दिखा सकता है। यह वादा पूरा करना, निस्तारण, जलाना या रद्द करना नहीं है।
ज़िम्मेदारियाँ एक नज़र में
- जारीकर्ता: वाउचर का वर्णन करता है, उसका वादा पूरा करता है और निस्तारण दर्ज करता है।
- पूल प्रबंधक: Pool के rules, rates, fees, limits, controls और स्पष्ट रूप से स्वीकार की गई guarantee प्रकाशित और संचालित करता है।
- धारक: जारीकर्ता, voucher terms, Pool rules, quote, wallet authorization और लागू कानून की जाँच करता है।
- तकनीकी नियंत्रक: केवल उन्हें दी गई contract, dependency, upgrade, catalog या fee powers इस्तेमाल करते हैं।
- GEF: सेवा की शर्तों के तहत CLC App और सहायक infrastructure चलाता है; वह दूसरी भूमिकाएँ अपने आप नहीं लेता।
भविष्य की क्रेडिट व्यवस्थाएँ
भविष्य का Pool या दूसरा जवाबदेह पक्ष transaction को अलग से repayable advance, secured transaction या दूसरे credit product के रूप में दे सकता है। ऐसे product के लिए अलग से दी गई supplemental और transaction terms चाहिए, जिनमें parties, amounts, due dates, fees या interest, collateral treatment, assignment, default, remedies और discharge evidence बताए जाएँ।
साधारण send, Pool deposit, Pool swap, voucher presentment, वादा पूरा करना या निस्तारण अपने आप वे दायित्व नहीं बनाता।