---
title: పెక్ట్రా 7702
metaTitle: Pectra EIP-7702 guidelines
description: పెక్ట్రా విడుదలలో 7702 గురించి మరింత తెలుసుకోండి
lang: te
---

## సారాంశం
EIP-7702 ఒక EOAకి కోడ్‌ను జోడించడానికి ఒక యంత్రాంగాన్ని నిర్వచిస్తుంది. ఈ ప్రతిపాదన పాత ఎథీరియం ఖాతాలైన EOAలను స్వల్పకాలిక కార్యాచరణ మెరుగుదలలను స్వీకరించడానికి అనుమతిస్తుంది, తద్వారా అప్లికేషన్‌ల వినియోగాన్ని పెంచుతుంది. కొత్త లావాదేవీ రకం: 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 స్వయంగా ఉపయోగించవచ్చు. EIP-7702 (గ్యాస్ నైరూప్యత, గోప్యతను కాపాడే ఉపసంహరణలు) ద్వారా ప్రారంభించబడిన అధునాతన ఫీచర్‌లను ఉపయోగించాలనుకునే అప్లికేషన్ డెవలపర్‌ల కోసం మీకు రిలేయర్ అవసరం. విభిన్న రిలేయర్ ఆర్కిటెక్చర్‌లు ఉన్నప్పటికీ, కనీసం [ఎంట్రీ పాయింట్ 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0)ని సూచించే [ERC-4337 బండ్లర్‌లను](https://www.erc4337.io/bundlers) ఉపయోగించమని మా సిఫార్సు ఎందుకంటే:

- అవి రిలేయింగ్ కోసం ప్రామాణిక ఇంటర్‌ఫేస్‌లను అందిస్తాయి
- అంతర్నిర్మిత చెల్లింపుదారు సిస్టమ్‌లను కలిగి ఉంటాయి
- భవిష్యత్తు అనుకూలతను నిర్ధారిస్తాయి
- [పబ్లిక్ మెంపూల్](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool) ద్వారా సెన్సార్‌షిప్ నిరోధకతకు మద్దతు ఇవ్వగలవు
- init ఫంక్షన్ కేవలం [EntryPoint](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) నుండి మాత్రమే కాల్ చేయబడాలని అవసరం చేయగలవు

మరో మాటలో చెప్పాలంటే, ఖాతా నుండి అవసరమైన చెల్లుబాటు అయ్యే సంతకం లేదా వాడుకరి కార్యకలాపం (UserOperation) అందించినంత కాలం ఎవరైనా లావాదేవీ స్పాన్సర్/రిలేయర్‌గా వ్యవహరించగలగాలి. ఇది సెన్సార్‌షిప్ నిరోధకతను నిర్ధారిస్తుంది: అనుకూల మౌలిక సదుపాయాలు అవసరం లేకపోతే, గేట్‌కీపింగ్ రిలే ద్వారా వినియోగదారు లావాదేవీలను ఏకపక్షంగా నిరోధించలేరు. ఉదాహరణకు, [మెటామాస్క్ యొక్క డెలిగేషన్ టూల్‌కిట్](https://github.com/MetaMask/delegation-framework/releases/tag/v1.3.0) మెటామాస్క్-నిర్దిష్ట సర్వర్ అవసరం లేకుండా, ఏదైనా చైన్‌లోని ఏదైనా ERC-4337 బండ్లర్ లేదా చెల్లింపుదారుతో స్పష్టంగా పనిచేస్తుంది.

**వాలెట్ ఇంటర్‌ఫేస్‌ల ద్వారా వికేంద్రీకృత అప్లికేషన్ (dapp)ల ఏకీకరణ**:

వాలెట్‌లు EIP-7702 కోసం నిర్దిష్ట ప్రాతినిధ్యం అప్పగింత కాంట్రాక్ట్‌లను వైట్‌లిస్ట్ చేస్తాయి కాబట్టి, dAppలు నేరుగా EIP-7702 అధికారాలను అభ్యర్థిస్తాయని ఆశించకూడదు. బదులుగా, ప్రామాణిక వాలెట్ ఇంటర్‌ఫేస్‌ల ద్వారా ఏకీకరణ జరగాలి:

- **ERC-5792 (`wallet_sendCalls`)**: బ్యాచ్ చేయబడిన కాల్‌లను అమలు చేయమని వాలెట్‌లను అభ్యర్థించడానికి dAppలను అనుమతిస్తుంది, లావాదేవీ బ్యాచింగ్ మరియు గ్యాస్ నైరూప్యత వంటి కార్యాచరణలను సులభతరం చేస్తుంది.

- **ERC-6900**: వాలెట్-నిర్వహించే మాడ్యూల్స్ ద్వారా సెషన్ కీలు మరియు ఖాతా పునరుద్ధరణ వంటి మాడ్యులర్ స్మార్ట్ ఖాతా సామర్థ్యాలను ఉపయోగించుకోవడానికి dAppలను అనుమతిస్తుంది.

ఈ ఇంటర్‌ఫేస్‌లను ఉపయోగించడం ద్వారా, dAppలు ప్రాతినిధ్యం అప్పగింతలను నేరుగా నిర్వహించకుండా EIP-7702 అందించిన స్మార్ట్ ఖాతా కార్యాచరణలను యాక్సెస్ చేయగలవు, విభిన్న వాలెట్ అమలులలో అనుకూలత మరియు భద్రతను నిర్ధారిస్తాయి.

> గమనిక: dAppలు నేరుగా EIP-7702 అధికార సంతకాలను అభ్యర్థించడానికి ప్రామాణిక పద్ధతి లేదు. EIP-7702 ఫీచర్‌ల ప్రయోజనాన్ని పొందడానికి dAppలు తప్పనిసరిగా ERC-6900 వంటి నిర్దిష్ట వాలెట్ ఇంటర్‌ఫేస్‌లపై ఆధారపడాలి.

మరింత సమాచారం కోసం:

- [ERC-5792 స్పెసిఫికేషన్](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md)
- [ERC-6900 స్పెసిఫికేషన్](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6900.md)

**వెండర్ లాక్-ఇన్‌ను నివారించడం**: పైన పేర్కొన్న దానికి అనుగుణంగా, మంచి అమలు వెండర్-న్యూట్రల్ మరియు పరస్పరం పనిచేయగలది. దీని అర్థం తరచుగా స్మార్ట్ ఖాతాల కోసం అభివృద్ధి చెందుతున్న ప్రమాణాలకు కట్టుబడి ఉండటం. ఉదాహరణకు, [Alchemy యొక్క మాడ్యులర్ ఖాతా](https://github.com/alchemyplatform/modular-account) మాడ్యులర్ స్మార్ట్ ఖాతాల కోసం ERC-6900 ప్రమాణాన్ని ఉపయోగిస్తుంది మరియు "అనుమతి రహిత పరస్పరం పనిచేయగల వినియోగం" దృష్టిలో ఉంచుకుని రూపొందించబడింది.

**గోప్యత సంరక్షణ**: ఆన్‌చైన్ గోప్యత పరిమితం అయినప్పటికీ, ప్రాతినిధ్యం అప్పగింత కాంట్రాక్ట్ డేటా బహిర్గతం మరియు లింకబిలిటీని తగ్గించడానికి ప్రయత్నించాలి. ERC-20 టోకెన్‌లలో గ్యాస్ చెల్లింపులు (కాబట్టి వినియోగదారులు పబ్లిక్ ETH బ్యాలెన్స్‌ను నిర్వహించాల్సిన అవసరం లేదు, ఇది గోప్యత మరియు UXని మెరుగుపరుస్తుంది) మరియు వన్-టైమ్ సెషన్ కీలు (ఇవి ఒకే దీర్ఘకాలిక కీపై ఆధారపడటాన్ని తగ్గిస్తాయి) వంటి ఫీచర్‌లకు మద్దతు ఇవ్వడం ద్వారా దీనిని సాధించవచ్చు. ఉదాహరణకు, EIP-7702 స్పాన్సర్ చేయబడిన లావాదేవీల ద్వారా టోకెన్‌లలో గ్యాస్ చెల్లించడాన్ని అనుమతిస్తుంది మరియు మంచి అమలు అవసరమైన దానికంటే ఎక్కువ సమాచారాన్ని లీక్ చేయకుండా అటువంటి చెల్లింపుదారులను ఏకీకృతం చేయడాన్ని సులభతరం చేస్తుంది. అదనంగా, నిర్దిష్ట ఆమోదాల ఆఫ్‌చైన్ ప్రాతినిధ్యం అప్పగింత (ఆన్‌చైన్‌లో ధృవీకరించబడిన సంతకాలను ఉపయోగించడం) అంటే వినియోగదారు యొక్క ప్రాథమిక కీతో తక్కువ ఆన్‌చైన్ లావాదేవీలు, గోప్యతకు సహాయపడతాయి. రిలేయర్‌ను ఉపయోగించాల్సిన ఖాతాలు వినియోగదారులు తమ IP చిరునామాలను బహిర్గతం చేసేలా చేస్తాయి. పబ్లిక్ మెంపూల్స్ దీనిని మెరుగుపరుస్తాయి, లావాదేవీ/UserOp మెంపూల్ ద్వారా ప్రచారం అయినప్పుడు అది పంపిన IP నుండి ఉద్భవించిందా లేదా p2p ప్రోటోకాల్ ద్వారా రిలే చేయబడిందా అని మీరు చెప్పలేరు.

**విస్తరణ మరియు మాడ్యులర్ భద్రత**: ఖాతా అమలులు విస్తరించదగినవిగా ఉండాలి, తద్వారా అవి కొత్త ఫీచర్‌లు మరియు భద్రతా మెరుగుదలలతో అభివృద్ధి చెందుతాయి. EIP-7702తో అప్‌గ్రేడబిలిటీ అంతర్లీనంగా సాధ్యమవుతుంది (ఎందుకంటే EOA దాని లాజిక్‌ను అప్‌గ్రేడ్ చేయడానికి భవిష్యత్తులో ఎల్లప్పుడూ కొత్త కాంట్రాక్ట్‌కు ప్రాతినిధ్యం వహించగలదు). అప్‌గ్రేడబిలిటీకి మించి, మంచి డిజైన్ మాడ్యులారిటీని అనుమతిస్తుంది – ఉదా., విభిన్న సంతకం స్కీమ్‌లు లేదా ఖర్చు విధానాల కోసం ప్లగ్-ఇన్ మాడ్యూల్స్ – పూర్తిగా మళ్లీ డిప్లాయ్ చేయు అవసరం లేకుండా. Alchemy యొక్క అకౌంట్ కిట్ ఒక ప్రధాన ఉదాహరణ, డెవలపర్‌లు ధ్రువీకరణ మాడ్యూల్స్ (ECDSA, BLS మొదలైన విభిన్న సంతకం రకాల కోసం) మరియు అనుకూల లాజిక్ కోసం ఎగ్జిక్యూషన్ మాడ్యూల్స్‌ను ఇన్‌స్టాల్ చేయడానికి అనుమతిస్తుంది. EIP-7702-ప్రారంభించబడిన ఖాతాలలో ఎక్కువ సౌలభ్యం మరియు భద్రతను సాధించడానికి, డెవలపర్‌లు నేరుగా నిర్దిష్ట అమలుకు కాకుండా ప్రతినిధి కాంట్రాక్ట్‌కు ప్రాతినిధ్యం వహించమని ప్రోత్సహించబడతారు. ఈ విధానం ప్రతి మార్పుకు అదనపు EIP-7702 అధికారాలు అవసరం లేకుండా అతుకులు లేని అప్‌గ్రేడ్‌లు మరియు మాడ్యులారిటీని అనుమతిస్తుంది.

ప్రాక్సీ ప్యాటర్న్ యొక్క ప్రయోజనాలు:

- **అప్‌గ్రేడబిలిటీ**: ప్రాక్సీని కొత్త అమలు కాంట్రాక్ట్‌కు సూచించడం ద్వారా కాంట్రాక్ట్ లాజిక్‌ను అప్‌డేట్ చేయండి.

- **అనుకూల ఇనిషియలైజేషన్ లాజిక్**: అవసరమైన స్థితి వేరియబుల్స్‌ను సురక్షితంగా సెటప్ చేయడానికి ప్రాక్సీలో ఇనిషియలైజేషన్ ఫంక్షన్‌లను చేర్చండి.

ఉదాహరణకు, [SafeEIP7702Proxy](https://docs.safe.global/advanced/eip-7702/7702-safe) EIP-7702-అనుకూల ఖాతాలలో ప్రాతినిధ్యం అప్పగింతలను సురక్షితంగా ప్రారంభించడానికి మరియు నిర్వహించడానికి ప్రాక్సీని ఎలా ఉపయోగించవచ్చో ప్రదర్శిస్తుంది.

ప్రాక్సీ ప్యాటర్న్ యొక్క ప్రతికూలతలు:

- **బాహ్య నటులపై ఆధారపడటం**: సురక్షితం కాని కాంట్రాక్ట్‌కు అప్‌గ్రేడ్ చేయకుండా ఉండటానికి మీరు బాహ్య బృందంపై ఆధారపడాలి.
## భద్రతా పరిగణనలు {#security-considerations}

**రీఎంట్రెన్సీ గార్డ్**: EIP-7702 ప్రాతినిధ్యం అప్పగింత పరిచయంతో, వినియోగదారు ఖాతా బాహ్యంగా స్వంతమైన ఖాతా (EOA) మరియు స్మార్ట్ కాంట్రాక్ట్ (SC) మధ్య డైనమిక్‌గా మారవచ్చు. ఈ సౌలభ్యం ఖాతాను లావాదేవీలను ప్రారంభించడానికి మరియు కాల్‌ల లక్ష్యంగా ఉండటానికి అనుమతిస్తుంది. ఫలితంగా, ఒక ఖాతా తనను తాను కాల్ చేసుకునే మరియు బాహ్య కాల్స్ చేసే సందర్భాలలో `msg.sender` అనేది `tx.origin` కి సమానంగా ఉంటుంది, ఇది గతంలో `tx.origin` ఎల్లప్పుడూ EOAగా ఉంటుందనే దానిపై ఆధారపడిన కొన్ని భద్రతా అంచనాలను బలహీనపరుస్తుంది.

స్మార్ట్ కాంట్రాక్ట్ డెవలపర్‌ల కోసం, `tx.origin` అనేది EOAని సూచిస్తుందని ఊహించడం ఇకపై సురక్షితం కాదు. అదేవిధంగా, రీఎంట్రెన్సీ దాడులకు వ్యతిరేకంగా రక్షణగా `msg.sender == tx.origin` ని ఉపయోగించడం ఇకపై నమ్మదగిన వ్యూహం కాదు.

ఇకముందు, సిస్టమ్‌లోని ఏ భాగస్వామి అయినా స్మార్ట్ కాంట్రాక్ట్ కావచ్చనే ఊహతో డెవలపర్‌లు డిజైన్ చేయాలి. ప్రత్యామ్నాయంగా వారు `nonReentrant` మాడిఫైయర్ ప్యాటర్న్‌లతో రీఎంట్రెన్సీ గార్డ్‌లను ఉపయోగించి స్పష్టమైన రీఎంట్రెన్సీ రక్షణను అమలు చేయవచ్చు. ఆడిట్ చేయబడిన మాడిఫైయర్‌ను అనుసరించాలని మేము సిఫార్సు చేస్తున్నాము ఉదా. [ఓపెన్ జెప్పెలిన్ యొక్క రీఎంట్రెన్సీ గార్డ్](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol). వారు [ట్రాన్సియెంట్ స్టోరేజ్ వేరియబుల్](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html)ని కూడా ఉపయోగించవచ్చు.

**ఇనిషియలైజేషన్ భద్రతా పరిగణనలు**

EIP-7702 ప్రాతినిధ్యం అప్పగింత కాంట్రాక్ట్‌లను అమలు చేయడం నిర్దిష్ట భద్రతా సవాళ్లను పరిచయం చేస్తుంది, ముఖ్యంగా ఇనిషియలైజేషన్ ప్రక్రియకు సంబంధించి. ఇనిషియలైజేషన్ ఫంక్షన్ (`init`) ప్రాతినిధ్యం అప్పగింత ప్రక్రియతో అణుబద్ధంగా జతచేయబడినప్పుడు ఒక క్లిష్టమైన దుర్బలత్వం తలెత్తుతుంది. అటువంటి సందర్భాలలో, ఒక ఫ్రంట్‌రన్నర్ ప్రాతినిధ్యం అప్పగింత సంతకాన్ని అడ్డగించవచ్చు మరియు మార్చబడిన పారామితులతో `init` ఫంక్షన్‌ను అమలు చేయవచ్చు, తద్వారా ఖాతా నియంత్రణను తీసుకోవచ్చు.

ఇప్పటికే ఉన్న స్మార్ట్ కాంట్రాక్ట్ ఖాతా (SCA) అమలులను వాటి ఇనిషియలైజేషన్ యంత్రాంగాలను సవరించకుండా EIP-7702తో ఉపయోగించడానికి ప్రయత్నిస్తున్నప్పుడు ఈ ప్రమాదం ముఖ్యంగా సంబంధితంగా ఉంటుంది.

**ఇనిషియలైజేషన్ దుర్బలత్వాలను తగ్గించడానికి పరిష్కారాలు**

- `initWithSig` ని అమలు చేయండి  
  ప్రామాణిక `init` ఫంక్షన్‌ను ఇనిషియలైజేషన్ పారామితులపై వినియోగదారు సంతకం చేయాల్సిన `initWithSig` ఫంక్షన్‌తో భర్తీ చేయండి. ఈ విధానం ఇనిషియలైజేషన్ స్పష్టమైన వినియోగదారు సమ్మతితో మాత్రమే కొనసాగుతుందని నిర్ధారిస్తుంది, తద్వారా అనధికార ఇనిషియలైజేషన్ ప్రమాదాలను తగ్గిస్తుంది.

- ERC-4337 యొక్క EntryPointని ఉపయోగించండి  
  ఇనిషియలైజేషన్ ఫంక్షన్ ప్రత్యేకంగా ERC-4337 EntryPoint కాంట్రాక్ట్ నుండి మాత్రమే కాల్ చేయబడాలని డిమాండ్ చేయండి. ఈ పద్ధతి ERC-4337 అందించిన ప్రామాణిక ధ్రువీకరణ మరియు అమలు ఫ్రేమ్‌వర్క్‌ను ప్రభావితం చేస్తుంది, ఇనిషియలైజేషన్ ప్రక్రియకు అదనపు భద్రతా పొరను జోడిస్తుంది.  
  _(చూడండి: [సేఫ్ డాక్స్](https://docs.safe.global/advanced/eip-7702/7702-safe))_

ఈ పరిష్కారాలను అవలంబించడం ద్వారా, డెవలపర్‌లు EIP-7702 ప్రాతినిధ్యం అప్పగింత కాంట్రాక్ట్‌ల భద్రతను మెరుగుపరచగలరు, ఇనిషియలైజేషన్ దశలో సంభావ్య ఫ్రంట్‌రన్నింగ్ దాడుల నుండి రక్షించగలరు.

**స్టోరేజ్ ఘర్షణలు** కోడ్‌కు ప్రాతినిధ్యం వహించడం ఇప్పటికే ఉన్న స్టోరేజ్‌ను క్లియర్ చేయదు. ఒక ప్రాతినిధ్యం అప్పగింత కాంట్రాక్ట్ నుండి మరొక దానికి మారుతున్నప్పుడు, మునుపటి కాంట్రాక్ట్ నుండి మిగిలిన డేటా అలాగే ఉంటుంది. కొత్త కాంట్రాక్ట్ అదే స్టోరేజ్ స్లాట్‌లను ఉపయోగించుకుని, వాటిని భిన్నంగా అర్థం చేసుకుంటే, అది అనాలోచిత ప్రవర్తనకు కారణమవుతుంది. ఉదాహరణకు, ప్రారంభ ప్రాతినిధ్యం అప్పగింత ఒక స్టోరేజ్ స్లాట్ `bool` ని సూచించే కాంట్రాక్ట్‌కు ఉంటే, మరియు తదుపరి ప్రాతినిధ్యం అప్పగింత అదే స్లాట్ `uint` ని సూచించే కాంట్రాక్ట్‌కు ఉంటే, ఆ అసమతుల్యత అనూహ్య ఫలితాలకు దారితీస్తుంది.

**ఫిషింగ్ ప్రమాదాలు** EIP-7702 ప్రాతినిధ్యం అప్పగింత అమలుతో, వినియోగదారు ఖాతాలోని ఆస్తులు పూర్తిగా స్మార్ట్ కాంట్రాక్ట్‌ల ద్వారా నియంత్రించబడవచ్చు. వినియోగదారు తెలియకుండానే తమ ఖాతాను హానికరమైన కాంట్రాక్ట్‌కు ప్రాతినిధ్యం వహిస్తే, దాడి చేసే వ్యక్తి సులభంగా నియంత్రణను పొంది నిధులను దొంగిలించవచ్చు. `chain_id=0` ని ఉపయోగిస్తున్నప్పుడు ప్రాతినిధ్యం అప్పగింత అన్ని చైన్ idలకు వర్తించబడుతుంది. మార్చలేని కాంట్రాక్ట్‌కు మాత్రమే ప్రాతినిధ్యం వహించండి (ఎప్పుడూ ప్రాక్సీకి ప్రాతినిధ్యం వహించవద్దు), మరియు CREATE2 (ప్రామాణిక ఇనిట్‌కోడ్‌తో - మెటామార్ఫిక్ కాంట్రాక్ట్‌లు లేవు) ఉపయోగించి డిప్లాయ్ చేయబడిన కాంట్రాక్ట్‌లకు మాత్రమే ప్రాతినిధ్యం వహించండి, తద్వారా డిప్లాయర్ వేరే చోట అదే చిరునామాకు భిన్నమైన దాన్ని డిప్లాయ్ చేయలేరు. లేకపోతే మీ ప్రాతినిధ్యం అప్పగింత అన్ని ఇతర EVM చైన్‌లలో మీ ఖాతాను ప్రమాదంలో పడేస్తుంది.

వినియోగదారులు ప్రాతినిధ్యం వహించిన సంతకాలను చేసినప్పుడు, ఫిషింగ్ ప్రమాదాలను తగ్గించడంలో సహాయపడటానికి ప్రాతినిధ్యం అప్పగింతను స్వీకరించే లక్ష్య కాంట్రాక్ట్ స్పష్టంగా మరియు ప్రముఖంగా ప్రదర్శించబడాలి.

**కనీస విశ్వసనీయ ఉపరితలం & భద్రత**: సౌలభ్యాన్ని అందిస్తున్నప్పటికీ, ప్రాతినిధ్యం అప్పగింత కాంట్రాక్ట్ దాని ప్రధాన లాజిక్‌ను కనిష్టంగా మరియు ఆడిట్ చేయదగినదిగా ఉంచాలి. కాంట్రాక్ట్ సమర్థవంతంగా వినియోగదారు యొక్క EOA యొక్క పొడిగింపు, కాబట్టి ఏదైనా లోపం విపత్తు కావచ్చు. అమలులు స్మార్ట్ కాంట్రాక్ట్ భద్రతా సంఘం నుండి ఉత్తమ పద్ధతులను అనుసరించాలి. ఉదాహరణకు, కన్స్ట్రక్టర్ లేదా ఇనిషియలైజర్ ఫంక్షన్‌లు జాగ్రత్తగా సురక్షితం చేయబడాలి – Alchemy హైలైట్ చేసినట్లుగా, 7702 కింద ప్రాక్సీ ప్యాటర్న్‌ను ఉపయోగిస్తుంటే, రక్షించబడని ఇనిషియలైజర్ దాడి చేసే వ్యక్తి ఖాతాను స్వాధీనం చేసుకునేలా చేస్తుంది. బృందాలు ఆన్‌చైన్ కోడ్‌ను సరళంగా ఉంచాలని లక్ష్యంగా పెట్టుకోవాలి: Ambire యొక్క 7702 కాంట్రాక్ట్ కేవలం ~200 లైన్ల Solidity మాత్రమే, బగ్‌లను తగ్గించడానికి ఉద్దేశపూర్వకంగా సంక్లిష్టతను తగ్గిస్తుంది. ఫీచర్-రిచ్ లాజిక్ మరియు ఆడిటింగ్‌ను సులభతరం చేసే సరళత మధ్య సమతుల్యతను సాధించాలి.

### తెలిసిన అమలులు
EIP-7702 స్వభావం కారణంగా, వినియోగదారులు 3వ పక్ష కాంట్రాక్ట్‌కు ప్రాతినిధ్యం వహించడంలో సహాయపడేటప్పుడు వాలెట్‌లు జాగ్రత్త వహించాలని సిఫార్సు చేయబడింది. ఆడిట్ చేయబడిన తెలిసిన అమలుల సేకరణ క్రింద జాబితా చేయబడింది:

| కాంట్రాక్ట్ చిరునామా                           | మూలం                                                                                                                                     | ఆడిట్‌లు                                                                                                                                                        |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00 | [Uniswap/calibur](https://github.com/Uniswap/calibur)                                                                                      | [ఆడిట్‌లు](https://github.com/Uniswap/calibur/tree/main/audits)                                                                                                 |
| 0x69007702764179f14F51cdce752f4f775d74E139 | [alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account)                                                      | [ఆడిట్‌లు](https://github.com/alchemyplatform/modular-account/tree/develop/audits)                                                                              |
| 0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d | [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)                                                                            |
| 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b | [MetaMask/delegation-framework](https://github.com/MetaMask/delegation-framework)                                                          | [ఆడిట్‌లు](https://github.com/MetaMask/delegation-framework/tree/main/audits)                                                                                   |
| 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 | [Ethereum Foundation AA team](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) |
| 0x17c11FDdADac2b341F2455aFe988fec4c3ba26e3 | [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}

హార్డ్‌వేర్ వాలెట్‌లు ఏకపక్ష ప్రాతినిధ్యం అప్పగింతను బహిర్గతం చేయకూడదు. హార్డ్‌వేర్ వాలెట్ స్పేస్‌లో ఏకాభిప్రాయం ఏమిటంటే విశ్వసనీయ డెలిగేటర్ కాంట్రాక్ట్‌ల జాబితాను ఉపయోగించడం. పైన జాబితా చేయబడిన తెలిసిన అమలులను అనుమతించాలని మరియు ఇతరులను సందర్భానుసారంగా పరిగణించాలని మేము సూచిస్తున్నాము. మీ EOAని కాంట్రాక్ట్‌కు ప్రాతినిధ్యం వహించడం అన్ని ఆస్తులపై నియంత్రణను ఇస్తుంది కాబట్టి, హార్డ్‌వేర్ వాలెట్‌లు 7702ని అమలు చేసే విధానంలో జాగ్రత్తగా ఉండాలి.

### సహచర యాప్‌ల కోసం ఏకీకరణ దృశ్యాలు {#integration-scenarios-for-companion-apps}

#### లేజీ {#lazy}

EOA ఇప్పటికీ యధావిధిగా పనిచేస్తున్నందున, చేయడానికి ఏమీ లేదు.

గమనిక : ERC-1155 NFTల వంటి కొన్ని ఆస్తులు ప్రాతినిధ్యం అప్పగింత కోడ్ ద్వారా స్వయంచాలకంగా తిరస్కరించబడవచ్చు మరియు మద్దతు బృందం దీని గురించి తెలుసుకోవాలి.

#### అవగాహన {#aware}

దాని కోడ్‌ని తనిఖీ చేయడం ద్వారా EOA కోసం ప్రాతినిధ్యం అప్పగింత అమలులో ఉందని వినియోగదారుకు తెలియజేయండి మరియు ఐచ్ఛికంగా ప్రాతినిధ్యం అప్పగింతను తీసివేయడానికి ఆఫర్ చేయండి.

#### సాధారణ ప్రాతినిధ్యం అప్పగింత
హార్డ్‌వేర్ ప్రొవైడర్ తెలిసిన ప్రాతినిధ్యం అప్పగింత కాంట్రాక్ట్‌లను వైట్‌లిస్ట్ చేస్తుంది మరియు సాఫ్ట్‌వేర్ సహచరుడిలో వాటి మద్దతును అమలు చేస్తుంది. పూర్తి ERC-4337 మద్దతు ఉన్న కాంట్రాక్ట్‌ను ఎంచుకోవాలని సిఫార్సు చేయబడింది.

వేరొక దానికి ప్రాతినిధ్యం వహించిన EOAలు ప్రామాణిక EOAలుగా నిర్వహించబడతాయి.
#### అనుకూల ప్రాతినిధ్యం అప్పగింత
హార్డ్‌వేర్ ప్రొవైడర్ దాని స్వంత ప్రాతినిధ్యం అప్పగింత కాంట్రాక్ట్‌ను అమలు చేస్తుంది మరియు దానిని జాబితాలకు జోడిస్తుంది, సాఫ్ట్‌వేర్ సహచరుడిలో దాని మద్దతును అమలు చేస్తుంది. పూర్తి ERC-4337 మద్దతుతో కాంట్రాక్ట్‌ను నిర్మించాలని సిఫార్సు చేయబడింది.

వేరొక దానికి ప్రాతినిధ్యం వహించిన EOAలు ప్రామాణిక EOAలుగా నిర్వహించబడతాయి.