---
title: پیکٹرا 7702
metaTitle: Pectra EIP-7702 guidelines
description: پیکٹرا ریلیز میں 7702 کے بارے میں مزید جانیں
lang: ur
---

## خلاصہ
<span dir="ltr">EIP-7702</span> ایک <span dir="ltr">EOA</span> میں کوڈ شامل کرنے کے طریقہ کار کی وضاحت کرتا ہے۔ یہ تجویز <span dir="ltr">EOAs</span>، جو کہ پرانے ایتھیریم اکاؤنٹس ہیں، کو قلیل مدتی فعالیت میں بہتری حاصل کرنے کی اجازت دیتی ہے، جس سے ایپلی کیشنز کے استعمال میں اضافہ ہوتا ہے۔ یہ ایک نئی ٹرانزیکشن قسم: <span dir="ltr">4</span> کا استعمال کرتے ہوئے پہلے سے تعینات کردہ کوڈ کی طرف ایک پوائنٹر سیٹ کر کے کیا جاتا ہے۔

یہ نئی ٹرانزیکشن قسم ایک اجازت نامے کی فہرست متعارف کراتی ہے۔ فہرست میں ہر اجازت نامے کے ٹوپل (tuple) کی وضاحت اس طرح کی گئی ہے:

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

**address** تفویض ہے (پہلے سے تعینات کردہ بائٹ کوڈ جو <span dir="ltr">EOA</span> کے ذریعے استعمال کیا جائے گا)
**chain_id** اجازت نامے کو ایک مخصوص چین (یا تمام چینز کے لیے <span dir="ltr">0</span>) تک محدود کرتا ہے
**nonce** اجازت نامے کو ایک مخصوص اکاؤنٹ نانس تک محدود کرتا ہے
(**y_parity, r, s**) اجازت نامے کے ٹوپل کا دستخط ہے، جس کی وضاحت <span dir="ltr">EOA</span> کی نجی کلید کے ذریعے `keccak(0x05 || rlp ([chain_id ,address, nonce]))` کے طور پر کی گئی ہے جس پر اجازت نامہ لاگو ہوتا ہے (جسے اتھارٹی بھی کہا جاتا ہے)

کسی تفویض کو null پتے پر تفویض کر کے ری سیٹ کیا جا سکتا ہے۔

تفویض کے بعد <span dir="ltr">EOA</span> کی نجی کلید کا اکاؤنٹ پر مکمل کنٹرول برقرار رہتا ہے۔ مثال کے طور پر Safe کو تفویض کرنے سے اکاؤنٹ ملٹی سگ نہیں بن جاتا کیونکہ اب بھی ایک ہی کلید موجود ہے جو کسی بھی دستخط کرنے کی پالیسی کو نظرانداز کر سکتی ہے۔ آگے بڑھتے ہوئے، ڈیولپرز کو اس مفروضے کے ساتھ ڈیزائن کرنا چاہیے کہ سسٹم میں کوئی بھی شریک سمارٹ کنٹریکٹ ہو سکتا ہے۔ سمارٹ کنٹریکٹ ڈیولپرز کے لیے، اب یہ فرض کرنا محفوظ نہیں ہے کہ `tx.origin` کسی <span dir="ltr">EOA</span> کی طرف اشارہ کرتا ہے۔
## بہترین طرز عمل
**اکاؤنٹ کی تجرید**: مطابقت کو زیادہ سے زیادہ کرنے کے لیے ایک تفویض کنٹریکٹ کو ایتھیریم کے وسیع تر اکاؤنٹ کی تجرید (<span dir="ltr">AA</span>) کے معیارات کے ساتھ ہم آہنگ ہونا چاہیے۔ خاص طور پر، اسے مثالی طور پر <span dir="ltr">ERC-4337</span> کے مطابق یا ہم آہنگ ہونا چاہیے۔

**بلا اجازت اور سنسرشپ کے خلاف مزاحم ڈیزائن**: ایتھیریم بلا اجازت شرکت کی قدر کرتا ہے۔ ایک تفویض کنٹریکٹ کو کسی ایک "قابل اعتماد" ریلے یا سروس کو ہارڈ کوڈ یا اس پر انحصار نہیں کرنا چاہیے۔ اگر ریلے آف لائن ہو جاتا ہے تو یہ اکاؤنٹ کو ناکارہ بنا دے گا۔ بیچنگ (جیسے `approve+transferFrom`) جیسی خصوصیات کو <span dir="ltr">EOA</span> خود ریلے کے بغیر استعمال کر سکتا ہے۔ ان ایپلی کیشن ڈیولپرز کے لیے جو <span dir="ltr">EIP-7702</span> (گیس کی تجرید، رازداری کو برقرار رکھنے والے انخلا) کے ذریعے فعال کردہ جدید خصوصیات استعمال کرنا چاہتے ہیں، آپ کو ایک ریلے کی ضرورت ہوگی۔ اگرچہ مختلف ریلے آرکیٹیکچرز موجود ہیں، ہماری سفارش ہے کہ [<span dir="ltr">ERC-4337</span> بنڈلرز](https://www.erc4337.io/bundlers) کا استعمال کریں جو کم از کم [entry point 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) کی طرف اشارہ کرتے ہوں کیونکہ:

- وہ ریلے کرنے کے لیے معیاری انٹرفیس فراہم کرتے ہیں
- ان میں بلٹ ان پے ماسٹر سسٹمز شامل ہیں
- مستقبل کی مطابقت کو یقینی بناتے ہیں
- ایک [عوامی میم پول](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool) کے ذریعے سنسرشپ کے خلاف مزاحمت کی حمایت کر سکتے ہیں
- یہ تقاضا کر سکتے ہیں کہ `init` فنکشن کو صرف [EntryPoint](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) سے کال کیا جائے

دوسرے الفاظ میں، کوئی بھی شخص ٹرانزیکشن اسپانسر/ریلے کے طور پر کام کرنے کے قابل ہونا چاہیے جب تک کہ وہ اکاؤنٹ سے مطلوبہ درست دستخط یا صارف کا عمل فراہم کرے۔ یہ سنسرشپ کے خلاف مزاحمت کو یقینی بناتا ہے: اگر کسی کسٹم انفراسٹرکچر کی ضرورت نہیں ہے، تو صارف کی ٹرانزیکشنز کو کسی گیٹ کیپنگ ریلے کے ذریعے من مانی طور پر روکا نہیں جا سکتا۔ مثال کے طور پر، [میٹاماسک کی ڈیلیگیشن ٹول کٹ](https://github.com/MetaMask/delegation-framework/releases/tag/v1.3.0) واضح طور پر کسی بھی چین پر کسی بھی <span dir="ltr">ERC-4337</span> بنڈلر یا پے ماسٹر کے ساتھ کام کرتی ہے، بجائے اس کے کہ میٹاماسک کے لیے مخصوص سرور کی ضرورت ہو۔

**والیٹ انٹرفیسز کے ذریعے غیر مرکزی ایپلی کیشنز (dapps) کا انضمام**:

یہ دیکھتے ہوئے کہ والیٹس <span dir="ltr">EIP-7702</span> کے لیے مخصوص تفویض کنٹریکٹس کو وائٹ لسٹ کریں گے، dapps کو براہ راست <span dir="ltr">EIP-7702</span> اجازت ناموں کی درخواست کرنے کی توقع نہیں کرنی چاہیے۔ اس کے بجائے، انضمام معیاری والیٹ انٹرفیسز کے ذریعے ہونا چاہیے:

- **<span dir="ltr">ERC-5792</span> (`wallet_sendCalls`)**: dapps کو والیٹس سے بیچڈ کالز کو انجام دینے کی درخواست کرنے کے قابل بناتا ہے، جس سے ٹرانزیکشن بیچنگ اور گیس کی تجرید جیسی خصوصیات میں سہولت ملتی ہے۔

- **<span dir="ltr">ERC-6900</span>**: dapps کو والیٹ کے زیر انتظام ماڈیولز کے ذریعے ماڈیولر اسمارٹ اکاؤنٹ کی صلاحیتوں، جیسے سیشن کیز اور اکاؤنٹ کی بحالی، سے فائدہ اٹھانے کی اجازت دیتا ہے۔

ان انٹرفیسز کا استعمال کرتے ہوئے، dapps براہ راست تفویض کا انتظام کیے بغیر <span dir="ltr">EIP-7702</span> کے ذریعے فراہم کردہ اسمارٹ اکاؤنٹ کی خصوصیات تک رسائی حاصل کر سکتے ہیں، جس سے مختلف والیٹ کے نفاذ میں مطابقت اور سیکیورٹی کو یقینی بنایا جا سکتا ہے۔

> نوٹ: dapps کے لیے براہ راست <span dir="ltr">EIP-7702</span> اجازت نامے کے دستخطوں کی درخواست کرنے کا کوئی معیاری طریقہ نہیں ہے۔ Dapps کو <span dir="ltr">EIP-7702</span> کی خصوصیات سے فائدہ اٹھانے کے لیے <span dir="ltr">ERC-6900</span> جیسے مخصوص والیٹ انٹرفیسز پر انحصار کرنا چاہیے۔

مزید معلومات کے لیے:

- [<span dir="ltr">ERC-5792</span> کی تفصیلات](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md)
- [<span dir="ltr">ERC-6900</span> کی تفصیلات](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6900.md)

**وینڈر لاک ان سے بچنا**: مندرجہ بالا کے مطابق، ایک اچھا نفاذ وینڈر نیوٹرل اور قابلِ باہمی عمل ہوتا ہے۔ اس کا مطلب اکثر اسمارٹ اکاؤنٹس کے ابھرتے ہوئے معیارات پر عمل کرنا ہوتا ہے۔ مثال کے طور پر، [Alchemy کا ماڈیولر اکاؤنٹ](https://github.com/alchemyplatform/modular-account) ماڈیولر اسمارٹ اکاؤنٹس کے لیے <span dir="ltr">ERC-6900</span> معیار کا استعمال کرتا ہے اور اسے "بلا اجازت قابلِ باہمی عمل استعمال" کو ذہن میں رکھ کر ڈیزائن کیا گیا ہے۔

**رازداری کا تحفظ**: اگرچہ آن چین رازداری محدود ہے، ایک تفویض کنٹریکٹ کو ڈیٹا کے افشاء اور لنک ایبلٹی کو کم سے کم کرنے کی کوشش کرنی چاہیے۔ یہ <span dir="ltr">ERC-20</span> ٹوکنز میں گیس کی ادائیگی (تاکہ صارفین کو عوامی <span dir="ltr">ETH</span> بیلنس برقرار رکھنے کی ضرورت نہ ہو، جو رازداری اور UX کو بہتر بناتا ہے) اور ون ٹائم سیشن کیز (جو ایک طویل مدتی کلید پر انحصار کو کم کرتی ہیں) جیسی خصوصیات کی حمایت کر کے حاصل کیا جا سکتا ہے۔ مثال کے طور پر، <span dir="ltr">EIP-7702</span> اسپانسر شدہ ٹرانزیکشنز کے ذریعے ٹوکنز میں گیس کی ادائیگی کو قابل بناتا ہے، اور ایک اچھا نفاذ ضرورت سے زیادہ معلومات لیک کیے بغیر ایسے پے ماسٹرز کو مربوط کرنا آسان بنا دے گا۔ مزید برآں، کچھ منظوریوں کی آف چین تفویض (ایسے دستخطوں کا استعمال کرتے ہوئے جن کی آن چین تصدیق کی جاتی ہے) کا مطلب ہے صارف کی بنیادی کلید کے ساتھ کم آن چین ٹرانزیکشنز، جو رازداری میں مدد کرتی ہیں۔ وہ اکاؤنٹس جنہیں ریلے استعمال کرنے کی ضرورت ہوتی ہے وہ صارفین کو اپنے IP پتے ظاہر کرنے پر مجبور کرتے ہیں۔ پبلک میم پولز اس میں بہتری لاتے ہیں، جب کوئی ٹرانزیکشن/صارف کا عمل میم پول کے ذریعے پھیلتا ہے تو آپ یہ نہیں بتا سکتے کہ آیا یہ اس IP سے شروع ہوا جس نے اسے بھیجا تھا، یا صرف p2p پروٹوکول کے ذریعے اس کے ذریعے ریلے کیا گیا تھا۔

**توسیع پذیری اور ماڈیولر سیکیورٹی**: اکاؤنٹ کے نفاذ کو قابل توسیع ہونا چاہیے تاکہ وہ نئی خصوصیات اور سیکیورٹی میں بہتری کے ساتھ تیار ہو سکیں۔ اپ گریڈ ایبلٹی <span dir="ltr">EIP-7702</span> کے ساتھ فطری طور پر ممکن ہے (کیونکہ ایک <span dir="ltr">EOA</span> ہمیشہ مستقبل میں اپنی منطق کو اپ گریڈ کرنے کے لیے ایک نئے کنٹریکٹ کو تفویض کر سکتا ہے)۔ اپ گریڈ ایبلٹی کے علاوہ، ایک اچھا ڈیزائن ماڈیولرٹی کی اجازت دیتا ہے – مثلاً، مختلف دستخطی اسکیموں یا خرچ کرنے کی پالیسیوں کے لیے پلگ ان ماڈیولز – مکمل طور پر دوبارہ تعینات کرنے کی ضرورت کے بغیر۔ Alchemy کی اکاؤنٹ کٹ ایک بہترین مثال ہے، جو ڈیولپرز کو توثیقی ماڈیولز (مختلف دستخطی اقسام جیسے <span dir="ltr">ECDSA</span>، <span dir="ltr">BLS</span> وغیرہ کے لیے) اور کسٹم منطق کے لیے ایگزیکیوشن ماڈیولز انسٹال کرنے کی اجازت دیتی ہے۔ <span dir="ltr">EIP-7702</span> سے چلنے والے اکاؤنٹس میں زیادہ لچک اور سیکیورٹی حاصل کرنے کے لیے، ڈیولپرز کی حوصلہ افزائی کی جاتی ہے کہ وہ براہ راست کسی مخصوص نفاذ کے بجائے پراکسی کنٹریکٹ کو تفویض کریں۔ یہ نقطہ نظر ہر تبدیلی کے لیے اضافی <span dir="ltr">EIP-7702</span> اجازت ناموں کی ضرورت کے بغیر ہموار اپ گریڈ اور ماڈیولرٹی کی اجازت دیتا ہے۔

پراکسی پیٹرن کے فوائد:

- **اپ گریڈ ایبلٹی**: پراکسی کو ایک نئے نفاذ کے کنٹریکٹ کی طرف اشارہ کر کے کنٹریکٹ کی منطق کو اپ ڈیٹ کریں۔

- **کسٹم انیشلائزیشن منطق**: ضروری حالت کے متغیرات کو محفوظ طریقے سے ترتیب دینے کے لیے پراکسی کے اندر انیشلائزیشن فنکشنز کو شامل کریں۔

مثال کے طور پر، [SafeEIP7702Proxy](https://docs.safe.global/advanced/eip-7702/7702-safe) یہ ظاہر کرتا ہے کہ <span dir="ltr">EIP-7702</span> کے ساتھ ہم آہنگ اکاؤنٹس میں تفویض کو محفوظ طریقے سے شروع کرنے اور ان کا انتظام کرنے کے لیے پراکسی کو کس طرح استعمال کیا جا سکتا ہے۔

پراکسی پیٹرن کے نقصانات:

- **بیرونی اداکاروں پر انحصار**: آپ کو کسی غیر محفوظ کنٹریکٹ میں اپ گریڈ نہ کرنے کے لیے کسی بیرونی ٹیم پر انحصار کرنا پڑتا ہے۔
## سیکیورٹی کے تحفظات {#security-considerations}

**ری اینٹرنسی گارڈ**: <span dir="ltr">EIP-7702</span> تفویض کے متعارف ہونے کے ساتھ، صارف کا اکاؤنٹ متحرک طور پر ایک بیرونی ملکیت والے اکاؤنٹ (<span dir="ltr">EOA</span>) اور ایک سمارٹ کنٹریکٹ (<span dir="ltr">SC</span>) کے درمیان سوئچ کر سکتا ہے۔ یہ لچک اکاؤنٹ کو ٹرانزیکشنز شروع کرنے اور کالز کا ہدف بننے دونوں کے قابل بناتی ہے۔ نتیجے کے طور پر، ایسے منظرنامے جہاں ایک اکاؤنٹ خود کو کال کرتا ہے اور بیرونی کالز کرتا ہے، ان میں `msg.sender` `tx.origin` کے برابر ہوگا، جو کچھ سیکیورٹی مفروضوں کو کمزور کرتا ہے جو پہلے اس بات پر انحصار کرتے تھے کہ `tx.origin` ہمیشہ ایک <span dir="ltr">EOA</span> ہوتا ہے۔

سمارٹ کنٹریکٹ ڈیولپرز کے لیے، اب یہ فرض کرنا محفوظ نہیں ہے کہ `tx.origin` کسی <span dir="ltr">EOA</span> کی طرف اشارہ کرتا ہے۔ اسی طرح، مکرر داخلہ (reentrancy) کے حملوں سے بچاؤ کے طور پر `msg.sender == tx.origin` کا استعمال اب کوئی قابل اعتماد حکمت عملی نہیں ہے۔

مستقبل میں، ڈیولپرز کو اس مفروضے کے ساتھ ڈیزائن کرنا چاہیے کہ سسٹم میں کوئی بھی شریک سمارٹ کنٹریکٹ ہو سکتا ہے۔ متبادل کے طور پر وہ `nonReentrant` موڈیفائر پیٹرنز کے ساتھ ری اینٹرنسی گارڈز کا استعمال کرتے ہوئے واضح مکرر داخلہ کے تحفظ کو نافذ کر سکتے ہیں۔ ہم ایک آڈٹ شدہ موڈیفائر کی پیروی کرنے کی تجویز کرتے ہیں مثلاً [Open Zeppelin کا ری اینٹرنسی گارڈ](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol)۔ وہ ایک [عارضی اسٹوریج متغیر (transient storage variable)](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html) بھی استعمال کر سکتے ہیں۔

**انیشلائزیشن سیکیورٹی کے تحفظات**

<span dir="ltr">EIP-7702</span> تفویض کنٹریکٹس کو نافذ کرنا مخصوص سیکیورٹی چیلنجز متعارف کراتا ہے، خاص طور پر انیشلائزیشن کے عمل کے حوالے سے۔ ایک اہم کمزوری اس وقت پیدا ہوتی ہے جب انیشلائزیشن فنکشن (`init`) کو تفویض کے عمل کے ساتھ ایٹمی طور پر (atomically) جوڑا جاتا ہے۔ ایسے معاملات میں، ایک فرنٹ رنر تفویض کے دستخط کو روک سکتا ہے اور تبدیل شدہ پیرامیٹرز کے ساتھ `init` فنکشن کو چلا سکتا ہے، جس سے ممکنہ طور پر اکاؤنٹ کا کنٹرول حاصل کیا جا سکتا ہے۔

یہ خطرہ خاص طور پر اس وقت متعلقہ ہوتا ہے جب موجودہ اسمارٹ کنٹریکٹ اکاؤنٹ (<span dir="ltr">SCA</span>) کے نفاذ کو ان کے انیشلائزیشن میکانزم میں ترمیم کیے بغیر <span dir="ltr">EIP-7702</span> کے ساتھ استعمال کرنے کی کوشش کی جائے۔

**انیشلائزیشن کی کمزوریوں کو کم کرنے کے حل**

- `initWithSig` کو نافذ کریں  
  معیاری `init` فنکشن کو ایک `initWithSig` فنکشن سے تبدیل کریں جو صارف سے انیشلائزیشن پیرامیٹرز پر دستخط کرنے کا تقاضا کرتا ہے۔ یہ نقطہ نظر اس بات کو یقینی بناتا ہے کہ انیشلائزیشن صرف صارف کی واضح رضامندی کے ساتھ ہی آگے بڑھ سکتی ہے، اس طرح غیر مجاز انیشلائزیشن کے خطرات کو کم کیا جا سکتا ہے۔

- <span dir="ltr">ERC-4337</span> کے EntryPoint کا استعمال کریں  
  یہ تقاضا کریں کہ انیشلائزیشن فنکشن کو خصوصی طور پر <span dir="ltr">ERC-4337</span> EntryPoint کنٹریکٹ سے کال کیا جائے۔ یہ طریقہ <span dir="ltr">ERC-4337</span> کے ذریعے فراہم کردہ معیاری توثیق اور ایگزیکیوشن فریم ورک کا فائدہ اٹھاتا ہے، جس سے انیشلائزیشن کے عمل میں سیکیورٹی کی ایک اضافی تہہ شامل ہوتی ہے۔  
  _(دیکھیں: [Safe کی دستاویزات](https://docs.safe.global/advanced/eip-7702/7702-safe))_

ان حلوں کو اپنا کر، ڈیولپرز <span dir="ltr">EIP-7702</span> تفویض کنٹریکٹس کی سیکیورٹی کو بڑھا سکتے ہیں، اور انیشلائزیشن کے مرحلے کے دوران ممکنہ فرنٹ رننگ حملوں سے بچاؤ کر سکتے ہیں۔

**اسٹوریج کا ٹکراؤ** کوڈ تفویض کرنے سے موجودہ اسٹوریج صاف نہیں ہوتا ہے۔ ایک تفویض کنٹریکٹ سے دوسرے میں منتقل ہوتے وقت، پچھلے کنٹریکٹ کا بقیہ ڈیٹا باقی رہتا ہے۔ اگر نیا کنٹریکٹ انہی اسٹوریج سلاٹس کا استعمال کرتا ہے لیکن ان کی تشریح مختلف طریقے سے کرتا ہے، تو یہ غیر ارادی رویے کا سبب بن سکتا ہے۔ مثال کے طور پر، اگر ابتدائی تفویض ایک ایسے کنٹریکٹ کو کی گئی تھی جہاں ایک اسٹوریج سلاٹ `bool` کی نمائندگی کرتا ہے، اور بعد کی تفویض ایک ایسے کنٹریکٹ کو کی جاتی ہے جہاں وہی سلاٹ `uint` کی نمائندگی کرتا ہے، تو یہ عدم مطابقت غیر متوقع نتائج کا باعث بن سکتی ہے۔

**فشنگ کے خطرات** <span dir="ltr">EIP-7702</span> تفویض کے نفاذ کے ساتھ، صارف کے اکاؤنٹ میں موجود اثاثے مکمل طور پر سمارٹ کنٹریکٹس کے کنٹرول میں ہو سکتے ہیں۔ اگر کوئی صارف نادانستہ طور پر اپنا اکاؤنٹ کسی بدنیتی پر مبنی کنٹریکٹ کو تفویض کر دیتا ہے، تو حملہ آور آسانی سے کنٹرول حاصل کر سکتا ہے اور فنڈز چرا سکتا ہے۔ جب `chain_id=0` استعمال کیا جاتا ہے تو تفویض تمام چین آئی ڈیز پر لاگو ہوتی ہے۔ صرف ایک ناقابلِ تبدیلی کنٹریکٹ کو تفویض کریں (کبھی بھی پراکسی کو تفویض نہ کریں)، اور صرف ان کنٹریکٹس کو جو <span dir="ltr">CREATE2</span> کا استعمال کرتے ہوئے تعینات کیے گئے تھے (معیاری initcode کے ساتھ - کوئی میٹامورفک کنٹریکٹس نہیں) تاکہ تعینات کرنے والا کہیں اور اسی پتے پر کچھ مختلف تعینات نہ کر سکے۔ بصورت دیگر آپ کی تفویض آپ کے اکاؤنٹ کو دیگر تمام <span dir="ltr">EVM</span> چینز پر خطرے میں ڈال دیتی ہے۔

جب صارفین تفویض کردہ دستخط کرتے ہیں، تو تفویض وصول کرنے والے ہدف کنٹریکٹ کو واضح اور نمایاں طور پر دکھایا جانا چاہیے تاکہ فشنگ کے خطرات کو کم کرنے میں مدد ملے۔

**کم از کم قابل اعتماد سطح اور سیکیورٹی**: لچک پیش کرنے کے باوجود، ایک تفویض کنٹریکٹ کو اپنی بنیادی منطق کو کم سے کم اور قابل آڈٹ رکھنا چاہیے۔ یہ کنٹریکٹ مؤثر طریقے سے صارف کے <span dir="ltr">EOA</span> کی توسیع ہے، لہذا کوئی بھی خامی تباہ کن ہو سکتی ہے۔ نفاذ کو سمارٹ کنٹریکٹ سیکیورٹی کمیونٹی کے بہترین طرز عمل کی پیروی کرنی چاہیے۔ مثال کے طور پر، کنسٹرکٹر یا انیشلائزر فنکشنز کو احتیاط سے محفوظ کیا جانا چاہیے – جیسا کہ Alchemy نے روشنی ڈالی ہے، اگر 7702 کے تحت پراکسی پیٹرن استعمال کیا جا رہا ہے، تو ایک غیر محفوظ انیشلائزر حملہ آور کو اکاؤنٹ پر قبضہ کرنے دے سکتا ہے۔ ٹیموں کا مقصد آن چین کوڈ کو سادہ رکھنا ہونا چاہیے: Ambire کا 7702 کنٹریکٹ صرف ~200 لائنوں کا Solidity کوڈ ہے، جو بگز کو کم کرنے کے لیے جان بوجھ کر پیچیدگی کو کم کرتا ہے۔ خصوصیات سے بھرپور منطق اور سادگی کے درمیان توازن قائم کیا جانا چاہیے جو آڈیٹنگ کو آسان بناتا ہے۔

### معلوم نفاذ
<span dir="ltr">EIP-7702</span> کی نوعیت کی وجہ سے، یہ تجویز کیا جاتا ہے کہ والیٹس صارفین کو کسی فریق ثالث کے کنٹریکٹ کو تفویض کرنے میں مدد کرتے وقت احتیاط برتیں۔ ذیل میں معلوم نفاذ کا ایک مجموعہ درج ہے جن کا آڈٹ کیا گیا ہے:

| کنٹریکٹ کا پتہ | ماخذ | آڈٹس |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <span dir="ltr">0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00</span> | [Uniswap/calibur](https://github.com/Uniswap/calibur)                                                                                      | [آڈٹس](https://github.com/Uniswap/calibur/tree/main/audits)                                                                                                 |
| <span dir="ltr">0x69007702764179f14F51cdce752f4f775d74E139</span> | [alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account)                                                      | [آڈٹس](https://github.com/alchemyplatform/modular-account/tree/develop/audits)                                                                              |
| <span dir="ltr">0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d</span> | [AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol)              | [آڈٹس](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits)                                                                            |
| <span dir="ltr">0x63c0c19a282a1b52b07dd5a65b58948a07dae32b</span> | [MetaMask/delegation-framework](https://github.com/MetaMask/delegation-framework)                                                          | [آڈٹس](https://github.com/MetaMask/delegation-framework/tree/main/audits)                                                                                   |
| <span dir="ltr">0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9</span> | [ایتھیریم فاؤنڈیشن AA ٹیم](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) | [آڈٹس](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) |
| <span dir="ltr">0x17c11FDdADac2b341F2455aFe988fec4c3ba26e3</span> | [Luganodes/Pectra-Batch-Contract](https://github.com/Luganodes/Pectra-Batch-Contract)                                                      | [آڈٹس](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html)                             |
## ہارڈویئر والیٹ کی ہدایات {#hardware-wallet-guidelines}

ہارڈویئر والیٹس کو من مانی تفویض کو ظاہر نہیں کرنا چاہیے۔ ہارڈویئر والیٹ کی جگہ میں اتفاق رائے قابل اعتماد ڈیلیگیٹر کنٹریکٹس کی فہرست استعمال کرنے پر ہے۔ ہم تجویز کرتے ہیں کہ اوپر درج معلوم نفاذ کی اجازت دی جائے اور دوسروں پر انفرادی بنیادوں پر غور کیا جائے۔ چونکہ آپ کے <span dir="ltr">EOA</span> کو کسی کنٹریکٹ میں تفویض کرنے سے تمام اثاثوں پر کنٹرول مل جاتا ہے، اس لیے ہارڈویئر والیٹس کو 7702 کو نافذ کرنے کے طریقے میں محتاط رہنا چاہیے۔

### ساتھی ایپس کے لیے انضمام کے منظرنامے {#integration-scenarios-for-companion-apps}

#### سست (Lazy) {#lazy}

چونکہ <span dir="ltr">EOA</span> اب بھی معمول کے مطابق کام کرتا ہے، اس لیے کرنے کو کچھ نہیں ہے۔

نوٹ: کچھ اثاثے تفویض کوڈ کے ذریعے خود بخود مسترد کیے جا سکتے ہیں، جیسے کہ <span dir="ltr">ERC-1155</span> NFTs، اور سپورٹ کو اس سے آگاہ ہونا چاہیے۔

#### باخبر (Aware) {#aware}

اس کا کوڈ چیک کر کے صارف کو مطلع کریں کہ <span dir="ltr">EOA</span> کے لیے ایک تفویض موجود ہے، اور اختیاری طور پر تفویض کو ہٹانے کی پیشکش کریں۔

#### عام تفویض
ہارڈویئر فراہم کنندہ معلوم تفویض کنٹریکٹس کو وائٹ لسٹ کرتا ہے اور سافٹ ویئر ساتھی میں ان کی حمایت کو نافذ کرتا ہے۔ یہ تجویز کیا جاتا ہے کہ مکمل <span dir="ltr">ERC-4337</span> سپورٹ کے ساتھ ایک کنٹریکٹ کا انتخاب کریں۔

کسی مختلف کو تفویض کردہ <span dir="ltr">EOAs</span> کو معیاری <span dir="ltr">EOAs</span> کے طور پر ہینڈل کیا جائے گا۔
#### کسٹم تفویض
ہارڈویئر فراہم کنندہ اپنا تفویض کنٹریکٹ نافذ کرتا ہے اور اسے فہرستوں میں شامل کرتا ہے اور سافٹ ویئر ساتھی میں اس کی حمایت کو نافذ کرتا ہے۔ یہ تجویز کیا جاتا ہے کہ مکمل <span dir="ltr">ERC-4337</span> سپورٹ کے ساتھ ایک کنٹریکٹ بنائیں۔

کسی مختلف کو تفویض کردہ <span dir="ltr">EOAs</span> کو معیاری <span dir="ltr">EOAs</span> کے طور پر ہینڈل کیا جائے گا۔