पेक्ट्रा 7702

सारांश

EIP-7702 EOA मध्ये कोड जोडण्यासाठी एक यंत्रणा परिभाषित करते. हा प्रस्ताव EOAs ला, जे पारंपारिक इथेरियम खाती आहेत, अल्प-मुदतीच्या कार्यक्षमतेत सुधारणा प्राप्त करण्याची अनुमती देतो, ज्यामुळे ॲप्लिकेशन्सची उपयोगिता वाढते. हे नवीन व्यवहार प्रकार: 4 वापरून आधीच प्रस्थापित केलेल्या कोडकडे पॉइंटर सेट करून केले जाते.

हा नवीन व्यवहार प्रकार एक अधिकृतता सूची (authorization list) सादर करतो. सूचीमधील प्रत्येक अधिकृतता ट्यूपल (tuple) खालीलप्रमाणे परिभाषित केले आहे

[ 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])) म्हणून परिभाषित केली जाते ज्याला अधिकृतता लागू होते (ज्याला ऑथॉरिटी देखील म्हटले जाते)

शून्य (null) पत्त्यावर अधिकारप्रदान करून अधिकारप्रदान रीसेट केले जाऊ शकते.

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

सर्वोत्तम पद्धती

खाते अमूर्तीकरण: सुसंगतता वाढवण्यासाठी अधिकारप्रदान कॉन्ट्रॅक्ट इथेरियमच्या व्यापक खाते अमूर्तीकरण (AA) मानकांशी संरेखित असले पाहिजे. विशेषतः, ते आदर्शतः ERC-4337 सुसंगत किंवा अनुरूप असावे.

परवानगीमुक्त आणि सेन्सॉरशिप-प्रतिरोधक डिझाइन: इथेरियम परवानगीमुक्त सहभागाला महत्त्व देते. अधिकारप्रदान कॉन्ट्रॅक्टने कोणत्याही एका “विश्वसनीय” रिलेअर किंवा सेवेवर हार्ड-कोड किंवा अवलंबून राहू नये. जर रिलेअर ऑफलाइन गेला तर यामुळे खाते निकामी होईल. बॅचिंग (उदा., मंजूर करणे+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 बंडलर किंवा पेमास्टरसह स्पष्टपणे कार्य करते.

वॉलेट इंटरफेसद्वारे विकेंद्रित ॲप्लिकेशन्स (dapps) एकत्रीकरण:

वॉलेट्स EIP-7702 साठी विशिष्ट अधिकारप्रदान कॉन्ट्रॅक्ट्सना व्हाइटलिस्ट करतील हे लक्षात घेता, dapps ने थेट 7702 अधिकृततेची विनंती करण्याची अपेक्षा करू नये. त्याऐवजी, एकत्रीकरण प्रमाणित वॉलेट इंटरफेसद्वारे झाले पाहिजे:

• ERC-5792 (wallet_sendCalls): dapps ला वॉलेट्सना बॅच केलेले कॉल्स कार्यान्वित करण्याची विनंती करण्यास सक्षम करते, ज्यामुळे व्यवहार बॅचिंग आणि गॅस ॲब्स्ट्रॅक्शन सारख्या कार्यक्षमतेची सोय होते.

• ERC-6900: dapps ला वॉलेट-व्यवस्थापित मॉड्यूल्सद्वारे मॉड्यूलर स्मार्ट खाते क्षमतांचा लाभ घेण्याची अनुमती देते, जसे की सेशन की आणि खाते पुनर्प्राप्ती.

या इंटरफेसचा वापर करून, dapps थेट अधिकारप्रदानांचे व्यवस्थापन न करता EIP-7702 द्वारे प्रदान केलेल्या स्मार्ट खाते कार्यक्षमतेत प्रवेश करू शकतात, ज्यामुळे विविध वॉलेट अंमलबजावणींमध्ये सुसंगतता आणि सुरक्षितता सुनिश्चित होते.

टीप: dapps साठी थेट 7702 अधिकृतता स्वाक्षऱ्यांची विनंती करण्यासाठी कोणतीही प्रमाणित पद्धत नाही. EIP-7702 वैशिष्ट्यांचा लाभ घेण्यासाठी dapps ने ERC-6900 सारख्या विशिष्ट वॉलेट इंटरफेसवर अवलंबून राहिले पाहिजे.

अधिक माहितीसाठी:

• ERC-5792 तपशील (opens in a new tab)
• ERC-6900 तपशील (opens in a new tab)

व्हेंडर लॉक-इन टाळणे: वरील गोष्टींच्या अनुषंगाने, एक चांगली अंमलबजावणी व्हेंडर-तटस्थ आणि आंतरकार्यक्षम असते. याचा अर्थ अनेकदा स्मार्ट खात्यांसाठी उदयोन्मुख मानकांचे पालन करणे असा होतो. उदाहरणार्थ, Alchemy चे मॉड्यूलर खाते (opens in a new tab) मॉड्यूलर स्मार्ट खात्यांसाठी ERC-6900 मानक वापरते आणि “परवानगीमुक्त आंतरकार्यक्षम वापर” लक्षात ठेवून डिझाइन केलेले आहे.

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

विस्तारक्षमता आणि मॉड्यूलर सुरक्षा: खात्याची अंमलबजावणी विस्तारण्यायोग्य असावी जेणेकरून ते नवीन वैशिष्ट्ये आणि सुरक्षा सुधारणांसह विकसित होऊ शकतील. EIP-7702 सह अपग्रेड करण्याची क्षमता अंतर्निहितपणे शक्य आहे (कारण EOA त्याचे लॉजिक अपग्रेड करण्यासाठी भविष्यात नेहमी नवीन कॉन्ट्रॅक्टला अधिकारप्रदान करू शकते). अपग्रेड करण्याच्या क्षमतेपलीकडे, एक चांगले डिझाइन मॉड्यूलरिटीला अनुमती देते – उदा., भिन्न स्वाक्षरी योजना किंवा खर्च धोरणांसाठी प्लग-इन मॉड्यूल्स – पूर्णपणे पुन्हा प्रस्थापित करण्याची आवश्यकता न ठेवता. Alchemy चे अकाउंट किट हे एक प्रमुख उदाहरण आहे, जे डेव्हलपर्सना प्रमाणीकरण मॉड्यूल्स (ECDSA, BLS, इ. सारख्या भिन्न स्वाक्षरी प्रकारांसाठी) आणि सानुकूल लॉजिकसाठी एक्झिक्यूशन मॉड्यूल्स स्थापित करण्याची अनुमती देते. EIP-7702-सक्षम खात्यांमध्ये अधिक लवचिकता आणि सुरक्षितता साध्य करण्यासाठी, डेव्हलपर्सना थेट विशिष्ट अंमलबजावणीऐवजी प्रॉक्सी कॉन्ट्रॅक्टला अधिकारप्रदान करण्यास प्रोत्साहित केले जाते. हा दृष्टिकोन प्रत्येक बदलासाठी अतिरिक्त EIP-7702 अधिकृततेची आवश्यकता न ठेवता अखंड अपग्रेड आणि मॉड्यूलरिटीला अनुमती देतो.

प्रॉक्सी पॅटर्नचे फायदे:

• अपग्रेड करण्याची क्षमता: प्रॉक्सीला नवीन अंमलबजावणी कॉन्ट्रॅक्टकडे निर्देशित करून कॉन्ट्रॅक्ट लॉजिक अपडेट करा.

• सानुकूल इनिशिएलायझेशन लॉजिक: आवश्यक स्थिती (state) व्हेरिएबल्स सुरक्षितपणे सेट करण्यासाठी प्रॉक्सीमध्ये इनिशिएलायझेशन फंक्शन्स समाविष्ट करा.

उदाहरणार्थ, 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 चा पुनर्प्रवेश रक्षक (opens in a new tab). ते ट्रान्झिएंट स्टोरेज व्हेरिएबल (opens in a new tab) देखील वापरू शकतात.

इनिशिएलायझेशन सुरक्षा विचार

EIP-7702 अधिकारप्रदान कॉन्ट्रॅक्ट्स लागू केल्याने विशिष्ट सुरक्षा आव्हाने निर्माण होतात, विशेषतः इनिशिएलायझेशन प्रक्रियेबाबत. जेव्हा इनिशिएलायझेशन फंक्शन (init) अधिकारप्रदान प्रक्रियेशी अणूस्वरूपात (atomically) जोडलेले असते तेव्हा एक गंभीर असुरक्षा निर्माण होते. अशा प्रकरणांमध्ये, एक फ्रंटरनर अधिकारप्रदान स्वाक्षरी रोखू शकतो आणि बदललेल्या पॅरामीटर्ससह init फंक्शन कार्यान्वित करू शकतो, ज्यामुळे खात्यावर नियंत्रण मिळवण्याची शक्यता असते.

जेव्हा त्यांच्या इनिशिएलायझेशन यंत्रणेत बदल न करता EIP-7702 सह विद्यमान स्मार्ट कॉन्ट्रॅक्ट खाते (SCA) अंमलबजावणी वापरण्याचा प्रयत्न केला जातो तेव्हा हा धोका विशेषतः संबंधित असतो.

इनिशिएलायझेशन असुरक्षा कमी करण्यासाठी उपाय

• initWithSig लागू करा
  प्रमाणित init फंक्शनला initWithSig फंक्शनने बदला ज्यासाठी वापरकर्त्याने इनिशिएलायझेशन पॅरामीटर्सवर स्वाक्षरी करणे आवश्यक आहे. हा दृष्टिकोन हे सुनिश्चित करतो की इनिशिएलायझेशन केवळ वापरकर्त्याच्या स्पष्ट संमतीनेच पुढे जाऊ शकते, ज्यामुळे अनधिकृत इनिशिएलायझेशनचे धोके कमी होतात.

• ERC-4337 च्या EntryPoint चा वापर करा
  इनिशिएलायझेशन फंक्शन केवळ ERC-4337 EntryPoint कॉन्ट्रॅक्टमधूनच कॉल करणे आवश्यक करा. ही पद्धत ERC-4337 द्वारे प्रदान केलेल्या प्रमाणित प्रमाणीकरण आणि अंमलबजावणी फ्रेमवर्कचा लाभ घेते, इनिशिएलायझेशन प्रक्रियेत सुरक्षिततेचा अतिरिक्त स्तर जोडते.
  (पहा: Safe दस्तऐवज (opens in a new tab))

या उपायांचा अवलंब करून, डेव्हलपर्स EIP-7702 अधिकारप्रदान कॉन्ट्रॅक्ट्सची सुरक्षा वाढवू शकतात, इनिशिएलायझेशन टप्प्यात संभाव्य फ्रंटरनिंग हल्ल्यांपासून संरक्षण करू शकतात.

स्टोरेज कोलिजन्स कोडचे अधिकारप्रदान केल्याने विद्यमान स्टोरेज साफ होत नाही. एका अधिकारप्रदान कॉन्ट्रॅक्टमधून दुसऱ्यामध्ये स्थलांतरित होताना, मागील कॉन्ट्रॅक्टमधील उर्वरित डेटा तसाच राहतो. जर नवीन कॉन्ट्रॅक्ट समान स्टोरेज स्लॉट्स वापरत असेल परंतु त्यांचा वेगळ्या प्रकारे अर्थ लावत असेल, तर यामुळे अनपेक्षित वर्तन होऊ शकते. उदाहरणार्थ, जर सुरुवातीचे अधिकारप्रदान अशा कॉन्ट्रॅक्टला केले असेल जिथे स्टोरेज स्लॉट bool दर्शवतो, आणि त्यानंतरचे अधिकारप्रदान अशा कॉन्ट्रॅक्टला केले असेल जिथे तोच स्लॉट uint दर्शवतो, तर या विसंगतीमुळे अप्रत्याशित परिणाम होऊ शकतात.

फिशिंगचे धोके EIP-7702 अधिकारप्रदानाच्या अंमलबजावणीसह, वापरकर्त्याच्या खात्यातील मालमत्ता पूर्णपणे स्मार्ट कॉन्ट्रॅक्ट्सद्वारे नियंत्रित केली जाऊ शकते. जर वापरकर्त्याने नकळतपणे त्यांचे खाते एखाद्या दुर्भावनापूर्ण कॉन्ट्रॅक्टला अधिकारप्रदान केले, तर हल्लेखोर सहजपणे नियंत्रण मिळवू शकतो आणि निधी चोरू शकतो. chain_id=0 वापरताना अधिकारप्रदान सर्व चेन आयडींवर लागू केले जाते. केवळ अपरिवर्तनीय कॉन्ट्रॅक्टला अधिकारप्रदान करा (कधीही प्रॉक्सीला अधिकारप्रदान करू नका), आणि केवळ CREATE2 वापरून प्रस्थापित केलेल्या कॉन्ट्रॅक्ट्सना (प्रमाणित initcode सह - कोणतेही मेटामॉर्फिक कॉन्ट्रॅक्ट्स नाहीत) जेणेकरून प्रस्थापित करणारा इतरत्र त्याच पत्त्यावर काहीतरी वेगळे प्रस्थापित करू शकणार नाही. अन्यथा तुमचे अधिकारप्रदान तुमचे खाते इतर सर्व EVM चेन्सवर धोक्यात आणते.

जेव्हा वापरकर्ते अधिकारप्रदान केलेल्या स्वाक्षऱ्या करतात, तेव्हा फिशिंगचे धोके कमी करण्यात मदत करण्यासाठी अधिकारप्रदान प्राप्त करणारे लक्ष्य कॉन्ट्रॅक्ट स्पष्टपणे आणि ठळकपणे प्रदर्शित केले जावे.

किमान विश्वसनीय पृष्ठभाग आणि सुरक्षा: लवचिकता प्रदान करताना, अधिकारप्रदान कॉन्ट्रॅक्टने त्याचे मुख्य लॉजिक किमान आणि ऑडिट करण्यायोग्य ठेवले पाहिजे. कॉन्ट्रॅक्ट प्रभावीपणे वापरकर्त्याच्या EOA चा विस्तार आहे, त्यामुळे कोणतीही त्रुटी विनाशकारी असू शकते. अंमलबजावणीने स्मार्ट कॉन्ट्रॅक्ट सुरक्षा समुदायाच्या सर्वोत्तम पद्धतींचे पालन केले पाहिजे. उदाहरणार्थ, कन्स्ट्रक्टर किंवा इनिशिएलायझर फंक्शन्स काळजीपूर्वक सुरक्षित करणे आवश्यक आहे – जसे Alchemy ने हायलाइट केले आहे, जर 7702 अंतर्गत प्रॉक्सी पॅटर्न वापरत असाल, तर असुरक्षित इनिशिएलायझर हल्लेखोराला खात्यावर ताबा मिळवू देऊ शकतो. टीम्सनी ऑनचेन कोड सोपा ठेवण्याचे उद्दिष्ट ठेवले पाहिजे: Ambire चे 7702 कॉन्ट्रॅक्ट केवळ ~200 ओळींचे Solidity आहे, जे बग्स कमी करण्यासाठी जाणीवपूर्वक गुंतागुंत कमी करते. वैशिष्ट्यपूर्ण लॉजिक आणि ऑडिटिंग सुलभ करणारी साधेपणा यांच्यात समतोल साधला पाहिजे.

ज्ञात अंमलबजावणी

EIP-7702 च्या स्वरूपामुळे, वापरकर्त्यांना तृतीय पक्ष कॉन्ट्रॅक्टला अधिकारप्रदान करण्यात मदत करताना वॉलेट्सनी सावधगिरी बाळगण्याची शिफारस केली जाते. खाली ऑडिट केलेल्या ज्ञात अंमलबजावणींचा संग्रह सूचीबद्ध आहे:

हार्डवेअर वॉलेट मार्गदर्शक तत्त्वे

हार्डवेअर वॉलेट्सनी अनियंत्रित अधिकारप्रदान उघड करू नये. हार्डवेअर वॉलेट क्षेत्रात विश्वसनीय डेलिगेटर कॉन्ट्रॅक्ट्सची सूची वापरण्यावर एकमत आहे. आम्ही वर सूचीबद्ध केलेल्या ज्ञात अंमलबजावणींना अनुमती देण्याची आणि इतरांचा केस-बाय-केस आधारावर विचार करण्याची शिफारस करतो. तुमचे EOA एखाद्या कॉन्ट्रॅक्टला अधिकारप्रदान केल्याने सर्व मालमत्तेवर नियंत्रण मिळते, त्यामुळे हार्डवेअर वॉलेट्सनी 7702 ची अंमलबजावणी करण्याच्या पद्धतीबाबत सावधगिरी बाळगली पाहिजे.

सहचर ॲप्ससाठी (companion apps) एकत्रीकरण परिस्थिती

लेझी (Lazy)

EOA अद्याप नेहमीप्रमाणे कार्य करत असल्याने, करण्यासारखे काहीही नाही.

टीप: काही मालमत्ता अधिकारप्रदान कोडद्वारे स्वयंचलितपणे नाकारल्या जाऊ शकतात, जसे की ERC-1155 NFTs, आणि सपोर्टला याची जाणीव असावी.

जागरूक (Aware)

EOA चा कोड तपासून त्याच्यासाठी अधिकारप्रदान लागू असल्याचे वापरकर्त्याला सूचित करा आणि वैकल्पिकरित्या अधिकारप्रदान काढून टाकण्याची ऑफर द्या.

सामान्य अधिकारप्रदान

हार्डवेअर प्रदाता ज्ञात अधिकारप्रदान कॉन्ट्रॅक्ट्सना व्हाइटलिस्ट करतो आणि सॉफ्टवेअर सहचरामध्ये (software companion) त्यांचे समर्थन लागू करतो. पूर्ण ERC-4337 समर्थन असलेले कॉन्ट्रॅक्ट निवडण्याची शिफारस केली जाते.

वेगळ्या कॉन्ट्रॅक्टला अधिकारप्रदान केलेले EOAs प्रमाणित EOAs म्हणून हाताळले जातील.

सानुकूल अधिकारप्रदान

हार्डवेअर प्रदाता स्वतःचे अधिकारप्रदान कॉन्ट्रॅक्ट लागू करतो आणि ते सूचीमध्ये जोडतो, तसेच सॉफ्टवेअर सहचरामध्ये त्याचे समर्थन लागू करतो. पूर्ण ERC-4337 समर्थन असलेले कॉन्ट्रॅक्ट तयार करण्याची शिफारस केली जाते.

वेगळ्या कॉन्ट्रॅक्टला अधिकारप्रदान केलेले EOAs प्रमाणित EOAs म्हणून हाताळले जातील.