صفحہ پلٹ رہا ہے۔
اگلا باب سامنے لا رہے ہیں…
سنیے… مطالعہ اپنے مطابق بنائیں۔
خط اور تھیم ظاہری انداز میں ہیں۔ اپنی آنکھوں کی سہولت بھی دیکھیں۔
اگلا باب سامنے لا رہے ہیں…
Deceiving a user into authorizing account delegation to code that can exercise unintended control over the account.
براؤزر میں بلند آواز سے پڑھنے کی سہولت چیک ہو رہی ہے…
یہ مطالعہ فی الحال انگریزی میں دستیاب ہے۔ انٹرفیس آپ کی منتخب زبان استعمال کرتا ہے۔
اصل انگریزی پڑھیں ←EIP-7702 allows a key-controlled Ethereum account to authorize a delegation indicator pointing to code. That code can then execute in the account's context. A malicious prompt may disguise this authority as a harmless login, upgrade, or account-repair step. The risk is broader than approving one transfer: the account is authorizing executable behavior whose permissions and persistence depend on the delegation and implementation.
Before authorizing a delegation, identify the intended network, delegate address, implementation, and reason for the request. A familiar application name or a zero-value outer transaction does not establish that the permission is harmless. A sponsored transaction may let someone else submit the authorization, so the absence of an ordinary gas payment by the user does not imply the absence of an on-chain effect. Wallet presentation should make these distinctions visible.
Delegation persists until changed or cleared under the protocol rules; it is not automatically erased after one transaction. Clearing it can limit future delegated behavior but cannot undo transfers already completed. Separate token allowances or other previously granted permissions may also remain. The EIP discusses implementation risks including initialization and storage handling, so choosing a legitimate-looking delegate is not a substitute for secure code. A suspected incident requires examining the actual authorization and resulting account state, not merely disconnecting a website.