क्या मल्टीसिग वॉलेट्स वास्तव में सुरक्षा बढ़ाते हैं? एक थ्रेट-मॉडल दृष्टिकोण
मल्टीसिग्नेचर वॉलेट्स को क्रिप्टो में डिफ़ॉल्ट सुरक्षित कस्टडी पैटर्न माना जाता है, लेकिन "क्या वे वास्तव में सुरक्षा बढ़ाते हैं?" इसका उत्तर पूरी तरह से थ्रेट मॉडल पर निर्भर करता है। यह पोस्ट बताती है कि मल्टीसिग किन चीज़ों से बचाता है, किनसे नहीं, और यह कहाँ चीज़ों को बदतर बना सकता है।
- security
- wallets
- multisig
- web3
- key-management
मल्टीसिग्नेचर वॉलेट्स (Multisignature wallets)—ऐसे वॉलेट्स जहां किसी ट्रांज़ैक्शन को मान्य होने से पहले M-of-N कीज़ (keys) का साइन करना आवश्यक होता है—को आमतौर पर सिंगल-की हॉट वॉलेट के एक स्पष्ट अपग्रेड के रूप में प्रस्तुत किया जाता है। DAO, एक्सचेंजों और गंभीर क्रिप्टो-नेटिव कंपनियों में अधिकांश ट्रेजरी सेटअप किसी न किसी प्रकार के मल्टीसिग (जैसे Safe, Squads, Multisig.js, थ्रेसहोल्ड-सिग्नेचर वेरिएंट) के माध्यम से संचालित होते हैं।
यह प्रतिष्ठा योग्य है, लेकिन केवल एक विशिष्ट थ्रेट मॉडल (threat model) के खिलाफ। मल्टीसिग फंड चोरी होने के कुछ सबसे आम तरीकों को विफल करता है, लेकिन अन्य के खिलाफ लगभग कुछ नहीं करता। नीचे इसका एक स्पष्ट और ईमानदार विवरण दिया गया है: मल्टीसिग वास्तव में किसमें अच्छा है, यह कहाँ कम पड़ जाता है, और किन मामलों में इसे अपनाना सेटअप को कम सुरक्षित बना सकता है।
मल्टीसिग क्या है, संक्षेप में
एक 2-of-3 मल्टीसिग में, तीन प्राइवेट कीज़ (private keys) होती हैं; ऑन-चेन (on-chain) निष्पादित होने के लिए उनमें से किन्हीं दो का ट्रांज़ैक्शन पर साइन करना आवश्यक है। वॉलेट स्वयं एक स्मार्ट कॉन्ट्रैक्ट है (इथेरियम / EVM की दुनिया में) या एक नेटिव मल्टीसिग आउटपुट प्रकार है (बिटकॉइन में P2SH/P2WSH के माध्यम से)। कॉन्ट्रैक्ट हस्ताक्षरों (signatures) की पुष्टि करता है और फिर ट्रांज़ैक्शन को आगे बढ़ाता है।
EVM इकोसिस्टम में सबसे व्यापक रूप से उपयोग किया जाने वाला कार्यान्वयन Safe (जिसे पहले Gnosis Safe कहा जाता था) है। सोलाना (Solana) पर, Squads यही भूमिका निभाता है। बिटकॉइन में नेटिव मल्टीसिग सपोर्ट का एक लंबा इतिहास है, जिसे अक्सर PSBT वर्कफ़्लो के माध्यम से हार्डवेयर वॉलेट्स के साथ जोड़ा जाता है।
थ्रेसहोल्ड-सिग्नेचर स्कीम (TSS, FROST, MPC) एक सिंगल ऑन-चेन की (key) के साथ समान परिणाम प्राप्त करती हैं—प्रत्येक साइनर प्राइवेट की (private key) का एक हिस्सा (share) रखता है और वे इसे कभी भी फिर से बनाए बिना संयुक्त रूप से साइन करते हैं। थ्रेट-मॉडल के दृष्टिकोण से, नीचे दिए गए अधिकांश बिंदु दोनों पर समान रूप से लागू होते हैं, जिसमें कुछ चेतावनियाँ आगे बताई गई हैं।
मल्टीसिग किससे बचाता है (अच्छी खबर)
सिंगल-की का कॉम्प्रोमाइज़ होना (Single-key compromise)
यह इसका मुख्य लाभ है। यदि किसी एक साइनर का हार्डवेयर वॉलेट चोरी हो जाता है, किसी एक साइनर के फोन में मैलवेयर (malware) आ जाता है, या किसी एक साइनर का सीड फ्रेज़ (seed phrase) लीक हो जाता है, तो उस अकेली की (key) को रखने वाला हमलावर फंड्स को नहीं ले जा सकता। उसे एक ही समय में कम से कम M-1 अन्य कीज़ (keys) को कॉम्प्रोमाइज़ (हैक) करना होगा।
एक 2-of-3 सेटअप के लिए, इसका मतलब है कि हमलावर को दो स्वतंत्र एंडपॉइंट्स (endpoints) को हैक करना होगा, जो आदर्श रूप से अलग-अलग लोगों के पास, अलग-अलग हार्डवेयर पर, अलग-अलग भौतिक स्थानों में हों। एक ही समय सीमा में दो स्वतंत्र डिवाइसों के कॉम्प्रोमाइज़ होने की संभावना आमतौर पर किसी एक के कॉम्प्रोमाइज़ होने की तुलना में बहुत कम होती है।
अंदरूनी जोखिम (Insider risk)
पूर्ण कस्टडी रखने वाला एक व्यक्ति गुस्से में काम छोड़ सकता है, दलबदल कर सकता है, उसे मजबूर किया जा सकता है, या वह बस कोई विनाशकारी गलती कर सकता है। मल्टीसिग मिलीभगत के बिना ऐसा करना असंभव बनाता है। DAO और कंपनियों के लिए, यह अक्सर प्राथमिक प्रेरणा होती है—बाहरी हमलावरों के खिलाफ सुरक्षा लाभ किसी भी एक आंतरिक व्यक्ति (internal actor) के खिलाफ मिलने वाले गवर्नेंस लाभ के मुकाबले गौण (secondary) है।
खोई हुई की (key) की रिकवरी
N > M वाले M-of-N सेटअप में, एक की (key) खोना विनाशकारी नहीं है। शेष साइनर्स फंड्स को एक नए मल्टीसिग में स्थानांतरित कर सकते हैं और खोई हुई की (key) को बदल सकते हैं। यह सिंगल-की कस्टडी की तुलना में एक सार्थक सुधार है, जहां एक सीड फ्रेज़ खोने का मतलब है सब कुछ स्थायी रूप से खो देना।
उपयोगकर्ता की फ़िशिंग (Phishing the user)
कई वॉलेट फ़िशिंग हमले (नकली एयरड्रॉप साइट्स, दुर्भावनापूर्ण टोकन अप्रूवल, ड्रेनर कॉन्ट्रैक्ट्स) उपयोगकर्ता द्वारा एक सिंगल ब्राउज़र सेशन में दुर्भावनापूर्ण ट्रांज़ैक्शन पर साइन करने पर निर्भर करते हैं। मल्टीसिग एक अलग सतह पर कन्फर्मेशन (पुष्टिकरण) का चरण जोड़ता है—जैसे कि Safe का कोऑर्डिनेटिंग UI, या कई डिवाइसों पर हार्डवेयर अप्रूवल—जो उपयोगकर्ता को यह नोटिस करने का एक और मौका देता है कि वे किसी ऐसी चीज़ पर साइन कर रहे हैं जो वे नहीं चाहते थे।
मल्टीसिग किससे नहीं बचाता है (असहज करने वाला हिस्सा)
यह वह खंड है जिसे आमतौर पर लोग नज़रअंदाज़ कर देते हैं।
स्वयं मल्टीसिग के स्मार्ट-कॉन्ट्रैक्ट में बग (Bugs)
मल्टीसिग एक स्मार्ट कॉन्ट्रैक्ट है। यदि कॉन्ट्रैक्ट में कोई बग (bug) है, तो दुनिया का कोई भी सावधानीपूर्ण की मैनेजमेंट (key management) मदद नहीं कर सकता। इतिहास की सबसे महंगी मल्टीसिग घटना—नवंबर 2017 में पैरिटी मल्टीसिग फ्रीज़ (Parity multisig freeze)—एक कॉन्ट्रैक्ट बग थी, न कि की (key) का कॉम्प्रोमाइज़। एक ही ट्रांज़ैक्शन के कारण लगभग $150M मूल्य का ETH स्थायी रूप से अगम्य (inaccessible) हो गया था।
आधुनिक Safe इथेरियम पर सबसे अधिक ऑडिट किए गए कॉन्ट्रैक्ट्स में से एक है और यह अच्छे से टिका हुआ है, लेकिन मुख्य बात यह है कि: आप "सुरक्षा के लिए एक प्राइवेट की" के बदले "भरोसा करने के लिए एक स्मार्ट कॉन्ट्रैक्ट" का सौदा कर रहे हैं। वह भरोसा ऑडिट और समय के साथ अर्जित और बार-बार अर्जित किया जाना चाहिए।
साइनिंग UI (यूज़र इंटरफ़ेस) का कॉम्प्रोमाइज़ होना
लगभग हर मल्टीसिग साइन-ऑफ़ किसी न किसी इंटरफ़ेस के माध्यम से होता है—Safe का वेब UI, एक वॉलेट प्लगइन, एक कस्टम डैशबोर्ड। यदि वह इंटरफ़ेस कॉम्प्रोमाइज़ (हैक) हो जाता है (जैसे कि DNS हाईजैक, डिपेंडेंसी पर सप्लाई-चेन अटैक, दुर्भावनापूर्ण ब्राउज़र एक्सटेंशन), तो हमलावर साइनर A को "alice.eth को 1 ETH भेजें" दिखा सकता है, जबकि वास्तव में साइन करने के लिए हार्डवेयर वॉलेट में "attacker.eth को 1000 ETH भेजें" ट्रांसमिट कर सकता है।
अधिकांश हार्डवेयर वॉलेट्स वास्तविक डेस्टिनेशन एड्रेस प्रदर्शित करते हैं, लेकिन साइनर्स आमतौर पर उस पर सरसरी नज़र ही डालते हैं। 2025 की शुरुआत में हुई बायबिट (Bybit) घटना Safe UI के कॉम्प्रोमाइज़ होने पर आधारित थी; सभी साइनर्स ने उसे स्वीकृत किया जिसे वे एक नियमित ट्रांज़ैक्शन मान रहे थे, जबकि प्रॉक्सी कॉन्ट्रैक्ट को संशोधित किया जा रहा था।
मल्टीसिग आपको एक ऐसे हमलावर से बचाता है जिसके पास केवल एक की (key) है। यह आपको उस हमलावर से नहीं बचाता जो आपके सभी साइनर्स के सामने गलत ट्रांज़ैक्शन रख सकता है।
कई साइनर्स की समन्वित फ़िशिंग (Coordinated phishing)
यदि साइनर्स ज्ञात हैं और उन तक पहुंचा जा सकता है—और एक प्रकाशित Safe एड्रेस वाली किसी भी ट्रेजरी के मामले में, वे आमतौर पर होते हैं—तो हमलावर उन सभी को निशाना बना सकता है। प्रत्येक साइनर पर एक ही फ़िशिंग अभियान चलाएं और प्रतीक्षा करें। यदि तीन में से दो साइनर एक ही दिन थके हुए, विचलित, या असावधान हैं, तो थ्रेसहोल्ड (न्यूनतम आवश्यक हस्ताक्षर) पूरा हो जाता है।
व्यवहार में सुचारू रूप से चलने वाले मल्टीसिग्स के खिलाफ यह सबसे यथार्थवादी हमला है, और इसके खिलाफ बचाव मुख्य रूप से प्रक्रियात्मक (procedural) हैं, तकनीकी नहीं: एक अलग चैनल (Signal, एक अलग चैट, एक फोन कॉल) में प्रत्येक ट्रांज़ैक्शन की आउट-ऑफ़-बैंड पुष्टि, और एक सख्त नीति कि $X से अधिक के किसी भी ट्रांज़ैक्शन पर साइन करने से पहले लाइव चर्चा की जानी चाहिए।
ऑफ-चेन की (key) स्टोरेज का कॉम्प्रोमाइज़ होना
यदि "साइनिंग कीज़" वास्तव में दो इंजीनियरों के मेटामास्क (MetaMask) सीड फ्रेज़ और ऑफिस के सेफ में रखे एक हार्डवेयर वॉलेट के बीच 2-of-3 हैं, तो आपके पास एक OPSEC (ऑपरेशनल सिक्योरिटी) समस्या है जिसे मल्टीसिग का रूप दिया गया है। तकनीकी रूप से थ्रेसहोल्ड पूरा हो जाता है, लेकिन विविधता (diversity) नकली है। दो इंजीनियरों की मशीनों पर लैपटॉप-मैलवेयर का संक्रमण, या ऑफिस में एक ही बार घुसपैठ, थ्रेसहोल्ड को कॉम्प्रोमाइज़ कर सकती है।
वास्तविक विविधता के लिए आवश्यकता है:
- विभिन्न हार्डवेयर मॉडल। (एक Ledger, एक Trezor, एक Keystone)।
- किसी भी सॉफ्टवेयर साइनिंग के लिए अलग-अलग ऑपरेटिंग सिस्टम।
- किसी भी स्थायी (persistent) स्टोरेज के लिए अलग-अलग भौतिक स्थान।
- जहां लागू हो, वहां अलग-अलग मानव, जिनके थ्रेट प्रोफाइल अलग हों।
थ्रेसहोल्ड से परे का नुकसान
रिकवरी का दूसरा पहलू: एक 2-of-3 सेटअप में, दो कीज़ (keys) खोना स्थायी नुकसान है। एक 3-of-5 में, तीन खोना स्थायी नुकसान है। M और N के बीच का अंतर जितना बड़ा होगा, एकल नुकसान (single losses) से सुरक्षा उतनी ही बेहतर होगी—लेकिन हमलावर के लिए फ़िशिंग हेतु M साइनर्स को ढूंढना उतना ही आसान हो जाएगा।
यह अपरिहार्य तनाव है। उच्च M बाहरी हमले के खिलाफ अधिक सुरक्षित है और इसकी रिकवरी कम संभव है। कम M अधिक रिकवर करने योग्य है और इस पर हमला करना आसान है। ऐसी कोई सेटिंग नहीं है जो दोनों को अनुकूलित (optimize) करती हो।
मल्टीसिग कहाँ चीज़ों को बदतर बना सकता है
कुछ ईमानदार मामले:
- बहुत छोटे बैलेंस के लिए, मल्टीसिग का ऑपरेशनल ओवरहेड (ट्रांज़ैक्शन कोऑर्डिनेशन, EVM पर गैस की लागत, सीखने की प्रक्रिया) ऐसी गलतियाँ पैदा कर सकता है जो सिंगल-की कस्टडी में नहीं होतीं। पॉकेट-मनी वाले $200 के क्रिप्टो के लिए सही टूल एक हार्डवेयर-समर्थित सिंगल की (key) है।
- उन सोलो यूज़र्स के लिए जो मल्टीसिग को एक रिकवरी योजना के रूप में देखते हैं लेकिन व्यवहार में सभी तीन कीज़ (keys) को उन डिवाइसों पर रखते हैं जिन्हें वे अकेले नियंत्रित करते हैं, मल्टीसिग थ्रेट मॉडल को बदले बिना जटिलता बढ़ा देता है—यदि कोई एक हमलावर आज उनमें से किसी एक डिवाइस को कॉम्प्रोमाइज़ कर लेता है, तो वे संभवतः उन सभी को कॉम्प्रोमाइज़ कर सकते हैं।
- उन संगठनों के लिए जिनके पास वास्तव में साइनर विविधता नहीं है—एक ही ऑफिस में मौजूद हर कोई, एक ही VPN पर, एक ही SSO का उपयोग करते हुए—थ्रेसहोल्ड महज़ एक औपचारिकता बन जाता है।
इन तीनों मामलों में, इसका उत्तर "सिंगल-की कस्टडी का उपयोग करें" नहीं है। यह "मल्टीसिग का सही तरीके से उपयोग करें या ऐसा कस्टोडियन चुनें जो ऐसा करता हो" है। लेकिन ऑपरेशनल अभ्यास की परवाह किए बिना यह दिखावा करना कि केवल कॉन्ट्रैक्ट का प्रकार ही सुरक्षा प्रदान करता है, इसी तरह से बड़े पैमाने पर नुकसान (high-profile losses) होते हैं।
एक अच्छा सेटअप कैसा दिखता है (What good looks like)
एक 2-of-3 या 3-of-5 मल्टीसिग ट्रेजरी नियंत्रण के रूप में तब अच्छा काम करता है जब निम्नलिखित सभी सत्य हों:
- साइनर्स अलग-अलग इंसान हों, जहां संभव हो अलग-अलग क्षेत्राधिकारों (jurisdictions) में हों।
- साइनिंग डिवाइस अलग-अलग OS (ऑपरेटिंग सिस्टम) पर, अलग-अलग हार्डवेयर ब्रांड के हों।
- ट्रांज़ैक्शन कन्फर्मेशन के लिए साइनिंग UI से स्वतंत्र, एक अलग संचार चैनल का उपयोग किया जाता हो।
- किसी भी साइनर के अप्रूवल से पहले एक अपेक्षित अंतर (diff)—कॉलडेटा (calldata), लक्ष्य (target), मूल्य (value)—के विरुद्ध ट्रांज़ैक्शन पेलोड को सत्यापित करने के लिए एक प्रलेखित (documented) प्रक्रिया मौजूद हो।
- मल्टीसिग कॉन्ट्रैक्ट स्वयं अच्छी तरह से ऑडिट किया गया हो (2026 में Safe सुरक्षित डिफ़ॉल्ट है) और संस्करण (version) पिन किया गया और ज्ञात हो।
- एक साइनर रिप्लेसमेंट प्रक्रिया मौजूद हो और उसका अभ्यास (rehearse) किया गया हो।
यह उससे कहीं अधिक अनुशासन की मांग करता है जितना कि अधिकांश टीमें शुरुआत में महसूस करती हैं। अच्छी खबर यह है कि अनुशासन एक बार का निवेश है; बुरी खबर यह है कि अनुशासन कॉन्ट्रैक्ट से अधिक मायने रखता है।
यह डोमेन से कैसे जुड़ता है
ऑफ-चेन (off-chain) की दुनिया में नामकरण (Naming) मल्टीसिग की सबसे मजबूत समानताओं में से एक है। एक सिंगल पासवर्ड के पीछे एक सिंगल रजिस्ट्रार खाते द्वारा नियंत्रित डोमेन, एक सिंगल-की वॉलेट है। जबकि रजिस्ट्रार लॉक + रजिस्ट्री लॉक + DNS प्रदाता पर 2FA + कई आधिकारिक प्रदाताओं द्वारा संरक्षित एक डोमेन, संरचनात्मक रूप से, एक मल्टीसिग है: नाम (domain name) के स्थानांतरित होने से पहले कई स्वतंत्र कारकों में से प्रत्येक का कॉम्प्रोमाइज़ होना आवश्यक है।
Namefi स्वामित्व को एक ऑन-चेन रिकॉर्ड के रूप में प्रस्तुत करके इसे और आगे ले जाता है जिसे सीधे मल्टीसिग वॉलेट में रखा जा सकता है। वही थ्रेसहोल्ड योजना जो ट्रेजरी की रक्षा करती है, अब DNS कंट्रोल प्लेन की रक्षा कर सकती है—ताकि एक अकेला फ़िशिंग का शिकार व्यक्ति कंपनी का डोमेन नहीं खो सकता, ठीक उसी तरह जैसे वह अकेले ट्रेजरी को खाली नहीं कर सकता। दोनों दुनियाओं में थ्रेट मॉडल का अपग्रेड समान है: "एक क्रेडेंशियल पर भरोसा करें" को "N में से M स्वतंत्र कारकों को कॉम्प्रोमाइज़ करें" से बदलें।
स्रोत और आगे पढ़ने के लिए सामग्री
- Safe — स्मार्ट अकाउंट कॉन्ट्रैक्ट्स और ऑडिट्स.
- IETF FROST — RFC 9591, फ्लेक्सिबल राउंड-ऑप्टिमाइज़्ड श्नॉर थ्रेसहोल्ड प्रोटोकॉल.
- Bitcoin — BIP-174 PSBT.
- Parity — मल्टीसिग फ्रीज़ पोस्ट-मार्टम.
- a16z crypto — Safe मल्टीसिग चलाने के लिए व्यावहारिक मार्गदर्शिका.
योगदानकर्ता
Fenwei Bian तीसवें दशक की सॉफ़्टवेयर डेवलपर हैं, जो अपने काम के घंटे पुल रिक्वेस्ट्स में और सप्ताहांत मिट्टी या लकड़ी के बुरादे में हाथ डालकर बिताती हैं। GitHub पर वर्षों तक ओपन सोर्स में काम करने से उन्होंने सीखा कि नाम इंटरफ़ेस होते हैं: अच्छा नाम स्पष्ट होता है, वह जो करता है उसे ईमानदारी से बताता है और अगले उपयोगकर्ता का खयाल रखता है।
वे बागवानी करती हैं क्योंकि वह धैर्य का फल देती है और खुशफ़हमी को सज़ा देती है। वे लकड़ी का काम करती हैं क्योंकि कोई जोड़ या तो ठीक बैठता है या नहीं। दोनों आदतें नामकरण पर उनके लेखन में दिखती हैं — दो बार नापो, स्रोत जाँचो और किसी खुरदुरी जगह को ऊपर-ऊपर घिसकर यह उम्मीद मत करो कि किसी की नज़र नहीं पड़ेगी।
Namefi के लिए वे लिखती हैं कि डोमेन बाज़ार वास्तव में कैसे चलते हैं, नामों को टोकनाइज़ और फ़्लिप करने में कौन-से व्यावहारिक ट्रेडऑफ़ होते हैं, और ऐसा डोमेन कैसे चुनें जिसे बीस साल बाद भी अपने पास रखकर खुशी हो।
Victor Zhou डिजिटल पहचान और भरोसे पर केंद्रित टेक्नोलॉजी उद्यमी और मानक संपादक हैं। उन्होंने Namefi की स्थापना की, Ethereum Improvement Proposals का संपादन करते हैं और इससे पहले Google Labs में स्मार्ट-कॉन्ट्रैक्ट आर्किटेक्चर के काम का नेतृत्व कर चुके हैं।
उनका काम नामकरण, स्वामित्व और उन प्रणालियों के संगम पर है जिनका उपयोग लोग ऑनलाइन अपनी पहचान स्थापित करने के लिए करते हैं। यही नज़रिया उन्हें इस बात में खास दिलचस्पी देता है कि नाम निजी अर्थ, सार्वजनिक मान्यता और डिजिटल इन्फ़्रास्ट्रक्चर के बीच कैसे आते-जाते हैं।
Namefi के लिए Victor टिकाऊ डिजिटल पहचान के रूप में डोमेन पर संपादन और लेखन करते हैं: नाम कैसे मालिकाना हक़ वाले ऑनचेन एसेट बनते हैं, टोकनाइज़ेशन कस्टडी और भरोसे को कैसे बदलता है, और नामकरण उन प्रणालियों से क्या सीख सकता है जिनका उपयोग लोग ऑनलाइन अपनी पहचान स्थापित करने के लिए करते हैं।
Nirmit Buddhiraja (निर्मित बुद्धिराजा) बीसवें दशक के उत्तरार्ध के अनुवादक हैं, जो जयपुर में पले-बढ़े और अब बेंगलुरु से काम करते हैं। मैकेनिकल इंजीनियरिंग में स्नातक होने के बाद वे IT सपोर्ट में गए और फिर अंग्रेज़ी व हिंदी के बीच तकनीकी और संपादकीय सामग्री को लोकलाइज़ करने लगे।
वे उसी हिंग्लिश रजिस्टर में काम करते हैं जिसमें ज़्यादातर भारतीय पाठक सचमुच सोचते हैं। शुद्ध हिंदी या शुद्ध अंग्रेज़ी थोपने के बजाय, जहाँ स्वाभाविक लगे वहाँ वे लिपि बदलते हैं। रविवार का गली क्रिकेट, चाय-समोसे के ब्रेक और सप्ताहांत की ट्रेकिंग उनके लिए ज़रूरी हैं।
Namefi के लिए वे डोमेन और नामकरण से जुड़े लेखों को हिंदी में लोकलाइज़ करते हैं — देवनागरी IDN, .in और .bharat नेमस्पेस, और लिप्यंतरण के उन फैसलों का ध्यान रखते हुए जो तय करते हैं कि कोई ब्रांड नाम एक साथ दो लिपियों में सही दिखेगा या नहीं।
संबंधित गाइड
- क्या AI एजेंट किसी डोमेन का मालिक हो सकता है? WHOIS, कस्टडी और टोकनरजिस्ट्रेंट का कानूनी व्यक्ति होना ज़रूरी है, लेकिन कस्टडी सौंपी जा सकती है। WHOIS, API कुंजियाँ और टोकनाइज़्ड डोमेन — कस्टडी के पूरे दायरे की व्याख्या।
- Namefi MCP सर्वर: AI एजेंटों के लिए डोमेन टूलNamefi MCP सर्वर द्वारा AI एजेंटों को दिए जाने वाले सभी टूल: खोज, रजिस्ट्रेशन, DNS, रिन्यूअल और टोकनाइज़ेशन, साथ में प्रमाणीकरण मॉडल और उदाहरण वर्कफ़्लो।
- ENS और टोकनयुक्त डोमेन का मूल्यांकन: ऑनचेन कॉम्प्स पढ़नाऑनचेन कॉम्प्स, फ्लोर-बनाम-प्रीमियम तर्क और ENS क्लब फैक्टर्स का उपयोग करके ENS और टोकनयुक्त डोमेन का मूल्यांकन कैसे करें — और यह DNS से अलग क्यों है।
- ENS बनाम DNS डोमेन फ़्लिपिंग: क्या अलग हैENS .eth नामों की फ़्लिपिंग पारंपरिक DNS डोमेन की फ़्लिपिंग से कैसे अलग है: स्वामित्व, तरलता, नवीनीकरण, गैस, और हर एक किस काम के लिए अच्छा है।