पेक्ट्रा 7702

सार

EIP 7702 एक EOA में कोड जोड़ने के लिए एक तंत्र को परिभाषित करता है। यह प्रस्ताव EOAs, जो कि पुराने एथेरियम खाते हैं, को अल्पकालिक कार्यात्मकता में सुधार प्राप्त करने की अनुमति देता है, जिससे अनुप्रयोगों की उपयोगिता बढ़ जाती है। यह एक नए लेनदेन प्रकार: 4 का उपयोग करके पहले से तैनात कोड के लिए एक पॉइंटर सेट करके किया जाता है।

यह नया लेनदेन प्रकार एक प्राधिकरण सूची प्रस्तुत करता है। सूची में प्रत्येक प्राधिकरण टपल को इस प्रकार परिभाषित किया गया है

[ chain_id, address, nonce, y_parity, r, s ]

address प्रत्यायोजन है (पहले से तैनात बाइटकोड जो EOA द्वारा उपयोग किया जाएगा) chain_id प्राधिकरण को एक विशिष्ट श्रृंखला तक लॉक करता है (या सभी श्रृंखलाओं के लिए 0) nonce प्राधिकरण को एक विशिष्ट खाता नॉन्स तक लॉक करता है (y_parity, r, s) प्राधिकरण टपल का हस्ताक्षर है, जिसे EOA की निजी कुंजी द्वारा keccak(0x05 || rlp ([chain_id ,address, nonce])) के रूप में परिभाषित किया गया है जिस पर प्राधिकरण लागू होता है (जिसे प्राधिकारी भी कहा जाता है)

शून्य पते पर प्रत्यायोजित करके एक प्रत्यायोजन को रीसेट किया जा सकता है।

प्रत्यायोजन के बाद EOA की निजी कुंजी खाते पर पूर्ण नियंत्रण बनाए रखती है। उदाहरण के लिए, Safe में प्रत्यायोजित करने से खाता मल्टीसिग नहीं बन जाता है क्योंकि अभी भी एक ही कुंजी है जो किसी भी हस्ताक्षर नीति को बायपास कर सकती है। आगे बढ़ते हुए, डेवलपर्स को इस धारणा के साथ डिज़ाइन करना चाहिए कि सिस्टम में कोई भी भागीदार एक स्मार्ट अनुबंध हो सकता है। स्मार्ट अनुबंध डेवलपर्स के लिए, यह मानना अब सुरक्षित नहीं है कि tx.origin एक EOA को संदर्भित करता है।

सर्वोत्तम प्रथाएं

खाता एब्स्ट्रैक्शन: संगतता को अधिकतम करने के लिए एक प्रत्यायोजन अनुबंध को एथेरियम के व्यापक खाता एब्स्ट्रैक्शन (AA) मानकों के अनुरूप होना चाहिए। विशेष रूप से, इसे आदर्श रूप से ERC-4337 के अनुरूप या संगत होना चाहिए।

अनुमति रहित और सेंसरशिप-प्रतिरोधी डिज़ाइन: एथेरियम अनुमति रहित भागीदारी को महत्व देता है। एक प्रत्यायोजन अनुबंध को किसी एक "विश्वसनीय" रिलेयर या सेवा को हार्ड-कोड नहीं करना चाहिए या उस पर निर्भर नहीं रहना चाहिए। यदि रिलेयर ऑफ़लाइन हो जाता है तो यह खाते को निष्क्रिय कर देगा। बैचिंग जैसी सुविधाएँ (उदाहरण के लिए, approve+transferFrom) EOA द्वारा स्वयं एक रिलेयर के बिना उपयोग की जा सकती हैं। उन एप्लिकेशन डेवलपर्स के लिए जो 7702 द्वारा सक्षम उन्नत सुविधाओं (गैस एब्स्ट्रैक्शन, गोपनीयता-संरक्षण निकासी) का उपयोग करना चाहते हैं, आपको एक रिलेयर की आवश्यकता होगी। हालांकि अलग-अलग रिलेयर आर्किटेक्चर हैं, हमारी सिफारिश 4337 बंडलर (opens in a new tab) का उपयोग करने की है जो कम से कम एंट्री पॉइंट 0.8 (opens in a new tab) को इंगित करते हैं, क्योंकि:

वे रिले करने के लिए मानकीकृत इंटरफेस प्रदान करते हैं
अंतर्निहित पेमास्टर सिस्टम शामिल हैं
आगे की संगतता सुनिश्चित करें
सार्वजनिक मेमपूल (opens in a new tab) के माध्यम से सेंसरशिप प्रतिरोध का समर्थन कर सकते हैं
यह आवश्यक कर सकते हैं कि init फ़ंक्शन को केवल EntryPoint (opens in a new tab) से ही कॉल किया जाए

दूसरे शब्दों में, कोई भी व्यक्ति लेनदेन प्रायोजक/रिलेयर के रूप में तब तक कार्य कर सकता है, जब तक वह खाते से आवश्यक वैध हस्ताक्षर या UserOperation प्रदान करता है। यह सेंसरशिप प्रतिरोध सुनिश्चित करता है: यदि किसी कस्टम अवसंरचना की आवश्यकता नहीं है, तो एक गेटकीपिंग रिले द्वारा किसी यूज़र के लेनदेन को मनमाने ढंग से ब्लॉक नहीं किया जा सकता है। उदाहरण के लिए, मेटामास्क का डेलिगेशन टूलकिट (opens in a new tab) किसी भी श्रृंखला पर किसी भी ERC-4337 बंडलर या पेमास्टर के साथ स्पष्ट रूप से काम करता है, बजाय इसके कि उसे मेटामास्क-विशिष्ट सर्वर की आवश्यकता हो।

वॉलेट इंटरफेस के माध्यम से डैप्स एकीकरण:

यह देखते हुए कि वॉलेट EIP-7702 के लिए विशिष्ट प्रत्यायोजन अनुबंधों को श्वेतसूची में डालेंगे, डैप्स को सीधे 7702 प्राधिकरणों का अनुरोध करने की उम्मीद नहीं करनी चाहिए। इसके बजाय, एकीकरण मानकीकृत वॉलेट इंटरफेस के माध्यम से होना चाहिए:

ERC-5792 (wallet_sendCalls): डैप्स को बैच किए गए कॉल निष्पादित करने के लिए वॉलेट से अनुरोध करने में सक्षम बनाता है, जिससे लेनदेन बैचिंग और गैस एब्स्ट्रैक्शन जैसी कार्यात्मकताओं को सुविधा मिलती है।
ERC-6900: डैप्स को वॉलेट-प्रबंधित मॉड्यूल के माध्यम से मॉड्यूलर स्मार्ट खाता क्षमताओं, जैसे सत्र कुंजी और खाता पुनर्प्राप्ति का लाभ उठाने की अनुमति देता है।

इन इंटरफेस का उपयोग करके, डैप्स सीधे प्रत्यायोजन का प्रबंधन किए बिना EIP-7702 द्वारा प्रदान की गई स्मार्ट खाता कार्यात्मकताओं तक पहुंच सकते हैं, जिससे विभिन्न वॉलेट कार्यान्वयनों में संगतता और सुरक्षा सुनिश्चित होती है।

ध्यान दें: डैप्स के लिए सीधे 7702 प्राधिकरण हस्ताक्षरों का अनुरोध करने के लिए कोई मानकीकृत विधि नहीं है। डैप्स को EIP-7702 सुविधाओं का लाभ उठाने के लिए ERC-6900 जैसे विशिष्ट वॉलेट इंटरफेस पर निर्भर रहना चाहिए।

अधिक जानकारी के लिए:

वेंडर लॉक-इन से बचना: उपरोक्त के अनुरूप, एक अच्छा कार्यान्वयन वेंडर-तटस्थ और इंटरऑपरेबल होता है। इसका अक्सर मतलब स्मार्ट खातों के लिए उभरते मानकों का पालन करना है। उदाहरण के लिए, अल्केमी’s Modular Account (opens in a new tab) मॉड्यूलर स्मार्ट खातों के लिए ERC-6900 मानक का उपयोग करता है और इसे "अनुमति रहित इंटरऑपरेबल उपयोग" को ध्यान में रखकर डिज़ाइन किया गया है।

गोपनीयता संरक्षण: हालांकि ऑन-चेन गोपनीयता सीमित है, एक प्रत्यायोजन अनुबंध को डेटा जोखिम और लिंकेबिलिटी को कम करने का प्रयास करना चाहिए। यह ERC-20 टोकन में गैस भुगतान जैसी सुविधाओं का समर्थन करके प्राप्त किया जा सकता है (ताकि यूज़र्स को सार्वजनिक ETH बैलेंस बनाए रखने की आवश्यकता न हो, जो गोपनीयता और UX में सुधार करता है) और एक बार की सत्र कुंजियाँ (जो एक ही दीर्घकालिक कुंजी पर निर्भरता को कम करती हैं)। उदाहरण के लिए, EIP-7702 प्रायोजित लेनदेन के माध्यम से टोकन में गैस का भुगतान करने में सक्षम बनाता है, और एक अच्छा कार्यान्वयन ऐसे पेमास्टर्स को आवश्यकता से अधिक जानकारी लीक किए बिना एकीकृत करना आसान बना देगा। इसके अतिरिक्त, कुछ अनुमोदनों का ऑफ़-चेन प्रत्यायोजन (उन हस्ताक्षरों का उपयोग करके जिन्हें ऑन-चेन सत्यापित किया जाता है) का अर्थ है यूज़र की प्राथमिक कुंजी के साथ कम ऑन-चेन लेनदेन, जो गोपनीयता में सहायता करता है। जिन खातों को रिलेयर का उपयोग करने की आवश्यकता होती है, वे यूज़र्स को अपने आईपी पते प्रकट करने के लिए बाध्य करते हैं। PublicMempools इसमें सुधार करता है, जब एक लेनदेन/UserOp मेमपूल के माध्यम से फैलता है तो आप यह नहीं बता सकते कि यह उस IP से उत्पन्न हुआ जिसने इसे भेजा है, या बस p2p प्रोटोकॉल के माध्यम से इसके माध्यम से रिले किया गया है।

विस्तारणीयता और मॉड्यूलर सुरक्षा: खाता कार्यान्वयन विस्तारणीय होना चाहिए ताकि वे नई सुविधाओं और सुरक्षा सुधारों के साथ विकसित हो सकें। EIP-7702 के साथ अपग्रेडेबिलिटी स्वाभाविक रूप से संभव है (चूंकि एक EOA भविष्य में अपने तर्क को अपग्रेड करने के लिए हमेशा एक नए अनुबंध को प्रत्यायोजित कर सकता है)। अपग्रेडेबिलिटी से परे, एक अच्छा डिज़ाइन मॉड्यूलरिटी की अनुमति देता है - उदाहरण के लिए, विभिन्न हस्ताक्षर योजनाओं या खर्च नीतियों के लिए प्लग-इन मॉड्यूल - पूरी तरह से फिर से तैनात करने की आवश्यकता के बिना। अल्केमी का अकाउंट किट एक प्रमुख उदाहरण है, जो डेवलपर्स को सत्यापन मॉड्यूल (ECDSA, BLS, आदि जैसे विभिन्न हस्ताक्षर प्रकारों के लिए) स्थापित करने की अनुमति देता है। और कस्टम लॉजिक के लिए निष्पादन मॉड्यूल। EIP-7702-सक्षम खातों में अधिक लचीलापन और सुरक्षा प्राप्त करने के लिए, डेवलपर्स को सीधे एक विशिष्ट कार्यान्वयन के बजाय एक प्रॉक्सी अनुबंध को प्रत्यायोजित करने के लिए प्रोत्साहित किया जाता है। यह दृष्टिकोण प्रत्येक परिवर्तन के लिए अतिरिक्त EIP-7702 प्राधिकरणों की आवश्यकता के बिना निर्बाध अपग्रेड और मॉड्यूलरिटी की अनुमति देता है।

प्रॉक्सी पैटर्न के लाभ:

अपग्रेडेबिलिटी: प्रॉक्सी को एक नए कार्यान्वयन अनुबंध पर इंगित करके अनुबंध तर्क को अपडेट करें।
कस्टम इनिशियलाइज़ेशन लॉजिक: आवश्यक स्टेट वेरिएबल्स को सुरक्षित रूप से सेट करने के लिए प्रॉक्सी के भीतर इनिशियलाइज़ेशन फ़ंक्शन शामिल करें।

उदाहरण के लिए, SafeEIP7702Proxy (opens in a new tab) यह प्रदर्शित करता है कि EIP-7702-संगत खातों में प्रत्यायोजनों को सुरक्षित रूप से प्रारंभ करने और प्रबंधित करने के लिए प्रॉक्सी का उपयोग कैसे किया जा सकता है।

प्रॉक्सी पैटर्न के नुकसान:

बाहरी हितधारकों पर निर्भरता: आपको एक बाहरी टीम पर भरोसा करना होगा कि वह असुरक्षित अनुबंध में अपग्रेड न करे।

सुरक्षा संबंधी विचार

रीएंट्रेंसी गार्ड: EIP-7702 प्रत्यायोजन की शुरूआत के साथ, एक यूज़र का खाता गतिशील रूप से बाहरी स्वामित्व वाले खाते (EOA) और एक स्मार्ट अनुबंध (SC) के बीच स्विच कर सकता है। यह लचीलापन खाते को लेनदेन शुरू करने और कॉल का लक्ष्य दोनों होने में सक्षम बनाता है। परिणामस्वरूप, ऐसे परिदृश्यों में जहां कोई खाता स्वयं को कॉल करता है और बाहरी कॉल करता है, msg.sender tx.origin के बराबर होगा, जो कुछ सुरक्षा धारणाओं को कमजोर करता है जो पहले tx.origin के हमेशा EOA होने पर निर्भर करती थीं।

स्मार्ट अनुबंध डेवलपर्स के लिए, यह मानना अब सुरक्षित नहीं है कि tx.origin एक EOA को संदर्भित करता है। इसी तरह, रीएंट्रेंसी हमलों के खिलाफ एक सुरक्षा उपाय के रूप में msg.sender == tx.origin का उपयोग करना अब एक विश्वसनीय रणनीति नहीं है।

आगे बढ़ते हुए, डेवलपर्स को इस धारणा के साथ डिज़ाइन करना चाहिए कि सिस्टम में कोई भी भागीदार एक स्मार्ट अनुबंध हो सकता है। वैकल्पिक रूप से वे nonReentrant संशोधक पैटर्न के साथ रीएंट्रेंसी गार्ड का उपयोग करके स्पष्ट रीएंट्रेंसी सुरक्षा लागू कर सकते हैं। हम एक ऑडिट किए गए संशोधक का पालन करने की सलाह देते हैं, जैसे Open Zeppelin's Reentrancy Guard (opens in a new tab)। वे क्षणिक भंडारण चर (opens in a new tab) का भी उपयोग कर सकते हैं।

आरंभीकरण सुरक्षा संबंधी विचार

EIP-7702 प्रत्यायोजन अनुबंधों को लागू करने से विशिष्ट सुरक्षा चुनौतियाँ सामने आती हैं, विशेष रूप से आरंभीकरण प्रक्रिया से संबंधित। एक महत्वपूर्ण भेद्यता तब उत्पन्न होती है जब आरंभीकरण फ़ंक्शन (init) को प्रत्यायोजन प्रक्रिया के साथ परमाणु रूप से जोड़ा जाता है। ऐसे मामलों में, एक फ्रंटरनर प्रत्यायोजन हस्ताक्षर को रोक सकता है और परिवर्तित मापदंडों के साथ init फ़ंक्शन निष्पादित कर सकता है, संभावित रूप से खाते का नियंत्रण ले सकता है।

यह जोखिम विशेष रूप से तब प्रासंगिक होता है जब मौजूदा स्मार्ट अनुबंध खाता (SCA) कार्यान्वयन को EIP-7702 के साथ उनके आरंभीकरण तंत्र को संशोधित किए बिना उपयोग करने का प्रयास किया जाता है।

प्रारंभिकरण कमजोरियों को कम करने के समाधान

initWithSig लागू करें मानक init फ़ंक्शन को initWithSig फ़ंक्शन से बदलें जिसके लिए यूज़र को प्रारंभिकरण मापदंडों पर हस्ताक्षर करने की आवश्यकता होती है। यह दृष्टिकोण सुनिश्चित करता है कि आरंभीकरण केवल स्पष्ट यूज़र सहमति के साथ ही आगे बढ़ सकता है, जिससे अनधिकृत आरंभीकरण जोखिम कम हो जाते हैं।
ERC-4337 के एंट्रीपॉइंट का उपयोग करें यह आवश्यक है कि आरंभीकरण फ़ंक्शन को विशेष रूप से ERC-4337 एंट्रीपॉइंट अनुबंध से कॉल किया जाए। यह विधि ERC-4337 द्वारा प्रदान किए गए मानकीकृत सत्यापन और निष्पादन ढांचे का लाभ उठाती है, जिससे आरंभीकरण प्रक्रिया में सुरक्षा की एक अतिरिक्त परत जुड़ जाती है।
(देखें: Safe Docs (opens in a new tab))

इन समाधानों को अपनाकर, डेवलपर्स EIP-7702 प्रत्यायोजन अनुबंधों की सुरक्षा बढ़ा सकते हैं, जिससे प्रारंभिक चरण के दौरान संभावित फ्रंटरनिंग हमलों से बचाव होता है।

भंडारण टकराव कोड को प्रत्यायोजित करने से मौजूदा भंडारण साफ़ नहीं होता है। एक प्रत्यायोजन अनुबंध से दूसरे में माइग्रेट करते समय, पिछले अनुबंध से अवशिष्ट डेटा बना रहता है। यदि नया अनुबंध समान भंडारण स्लॉट का उपयोग करता है लेकिन उन्हें अलग-अलग तरीके से व्याख्या करता है, तो यह अनपेक्षित व्यवहार का कारण बन सकता है। उदाहरण के लिए, यदि प्रारंभिक प्रत्यायोजन एक ऐसे अनुबंध के लिए था जहां एक भंडारण स्लॉट bool का प्रतिनिधित्व करता है, और बाद का प्रत्यायोजन एक ऐसे अनुबंध के लिए है जहां वही स्लॉट uint का प्रतिनिधित्व करता है, तो बेमेल अप्रत्याशित परिणाम दे सकता है।

फ़िशिंग जोखिम EIP-7702 प्रत्यायोजन के कार्यान्वयन के साथ, एक यूज़र के खाते में संपत्ति पूरी तरह से स्मार्ट अनुबंधों द्वारा नियंत्रित की जा सकती है। यदि कोई यूज़र अनजाने में अपने खाते को एक दुर्भावनापूर्ण अनुबंध को प्रत्यायोजित कर देता है, तो एक हमलावर आसानी से नियंत्रण हासिल कर सकता है और धन चुरा सकता है। जब chain_id=0 का उपयोग किया जाता है तो प्रत्यायोजन सभी श्रृंखला आईडी पर लागू होता है। केवल एक अपरिवर्तनीय अनुबंध को प्रत्यायोजित करें (कभी भी प्रॉक्सी को प्रत्यायोजित न करें), और केवल उन अनुबंधों को जो CREATE2 (मानक इनिटकोड के साथ - कोई मेटामॉर्फिक अनुबंध नहीं) का उपयोग करके तैनात किए गए थे, ताकि डिप्लॉयर कहीं और उसी पते पर कुछ अलग तैनात न कर सके। अन्यथा आपका प्रत्यायोजन आपके खाते को अन्य सभी EVM श्रृंखलाओं पर जोखिम में डालता है।

जब यूज़र प्रत्यायोजित हस्ताक्षर करते हैं, तो प्रत्यायोजन प्राप्त करने वाले लक्ष्य अनुबंध को फ़िशिंग जोखिमों को कम करने में मदद करने के लिए स्पष्ट रूप से और प्रमुखता से प्रदर्शित किया जाना चाहिए।

न्यूनतम विश्वसनीय सतह और सुरक्षा: लचीलापन प्रदान करते हुए, एक प्रत्यायोजन अनुबंध को अपने मूल तर्क को न्यूनतम और ऑडिट करने योग्य रखना चाहिए। अनुबंध प्रभावी रूप से यूज़र के EOA का एक विस्तार है, इसलिए कोई भी दोष विनाशकारी हो सकता है। कार्यान्वयन को स्मार्ट अनुबंध सुरक्षा समुदाय से सर्वोत्तम प्रथाओं का पालन करना चाहिए। उदाहरण के लिए, कंस्ट्रक्टर या इनिशियलाइज़र फ़ंक्शंस को सावधानीपूर्वक सुरक्षित किया जाना चाहिए - जैसा कि अल्केमी द्वारा हाइलाइट किया गया है, यदि 7702 के तहत प्रॉक्सी पैटर्न का उपयोग कर रहे हैं, तो एक असुरक्षित इनिशियलाइज़र एक हमलावर को खाते पर नियंत्रण करने दे सकता है। टीमों को ऑन-चेन कोड को सरल रखने का लक्ष्य रखना चाहिए: Ambire का 7702 अनुबंध केवल ~200 पंक्तियों का सॉलिडिटी है, जो बग को कम करने के लिए जानबूझकर जटिलता को कम करता है। सुविधा संपन्न तर्क और ऑडिटिंग को आसान बनाने वाली सादगी के बीच संतुलन बनाना चाहिए।

ज्ञात कार्यान्वयन

EIP 7702 की प्रकृति के कारण, यह अनुशंसा की जाती है कि वॉलेट तीसरे पक्ष के अनुबंध को यूज़र को प्रत्यायोजित करने में मदद करते समय सावधानी बरतें। नीचे ज्ञात कार्यान्वयनों का एक संग्रह सूचीबद्ध है जिनका ऑडिट किया गया है:

अनुबंध का पता	स्रोत	ऑडिट
0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00	यूनिस्वैप/calibur (opens in a new tab)	ऑडिट (opens in a new tab)
0x69007702764179f14F51cdce752f4f775d74E139	alchemyplatform/modular-account (opens in a new tab)	ऑडिट (opens in a new tab)
0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d	AmbireTech/ambire-common (opens in a new tab)	ऑडिट (opens in a new tab)
0x63c0c19a282a1b52b07dd5a65b58948a07dae32b	मेटामास्क/delegation-framework (opens in a new tab)	ऑडिट (opens in a new tab)
0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9	एथेरियम फाउंडेशन AA टीम (opens in a new tab)	ऑडिट (opens in a new tab)
0x17c11FDdADac2b341F2455aFe988fec4c3ba26e3	Luganodes/पेक्ट्रा-Batch-Contract (opens in a new tab)	ऑडिट (opens in a new tab)

हार्डवेयर वॉलेट दिशानिर्देश

हार्डवेयर वॉलेट को मनमाना प्रत्यायोजन उजागर नहीं करना चाहिए। हार्डवेयर वॉलेट स्पेस में सहमति विश्वसनीय डेलीगेटर अनुबंधों की एक सूची का उपयोग करने की है। हम ऊपर सूचीबद्ध ज्ञात कार्यान्वयनों को अनुमति देने और केस-दर-केस आधार पर दूसरों पर विचार करने का सुझाव देते हैं। चूंकि आपके EOA को एक अनुबंध को प्रत्यायोजित करने से सभी संपत्तियों पर नियंत्रण मिलता है, हार्डवेयर वॉलेट को 7702 को लागू करने के तरीके से सतर्क रहना चाहिए।

सहयोगी ऐप्स के लिए एकीकरण परिदृश्य

आलसी

चूंकि EOA अभी भी सामान्य रूप से काम करता है, इसलिए कुछ भी करने की आवश्यकता नहीं है।

ध्यान दें : कुछ संपत्तियां प्रतिनिधिमंडल कोड द्वारा स्वचालित रूप से अस्वीकार की जा सकती हैं, जैसे कि ERC 1155 एनएफटीज़, और सहायता को इसके बारे में पता होना चाहिए।

जागरूक

यूज़र को सूचित करें कि EOA के लिए उसके कोड की जाँच करके एक प्रत्यायोजन लागू है, और वैकल्पिक रूप से प्रत्यायोजन को हटाने की पेशकश करें।

सामान्य प्रत्यायोजन

हार्डवेयर प्रदाता ज्ञात प्रत्यायोजन अनुबंधों को श्वेतसूची में डालता है और सॉफ्टवेयर साथी में उनके समर्थन को लागू करता है। पूर्ण ERC 4337 समर्थन वाले अनुबंध को चुनने की अनुशंसा की जाती है।

एक अलग वाले को प्रत्यायोजित EOA को मानक EOA के रूप में संभाला जाएगा।

कस्टम प्रत्यायोजन

हार्डवेयर प्रदाता अपना स्वयं का प्रत्यायोजन अनुबंध लागू करता है और इसे सूचियों में जोड़ता है और सॉफ़्टवेयर साथी में इसके समर्थन को लागू करता है। पूर्ण ERC 4337 समर्थन वाले अनुबंध बनाने की अनुशंसा की जाती है।