EIP-7702 grants addresses capabilities and flexibility similar to smart contracts, and more and more 7702 applications are continuously being created, which is crucial for bringing more people into Web3 and enhancing user experience.
However, the flexibility of 7702 and the fact that most users are still unfamiliar with 7702 are being exploited by fraudulent groups. Recently, we have observed that some users have fallen victim to phishing groups like #InfernoDrainer due to MetaMask's 7702 batch execution capability, leading to what originally required dozens of authorizations being merged into a single transaction, resulting in asset theft.
Note: MetaMask itself has no security issues. MetaMask prioritizes user safety when providing 7702-related capabilities and has implemented many security measures. Users need to understand more about the capabilities and related risks of 7702 to prevent such security incidents from happening again.
One, Principles and Security Design of MetaMask 7702 Delegator Signature Authorization
1. Technical Analysis
Authorized by the user to deploy the Delegator Contract, directing the code field of the user's account to that contract. The current official MetaMask Delegator Contract address: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
Authorization structure: (chainId, delegatorAddress, nonce, signature) written into authorization_list
Signing method: MetaMask's underlying logic for authorization transactions related to EIP-7702 uses a unified signing logic, specifically the signEIP7702Authorization method. The authorization data digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)) is signed using ECDSA, generating a (v, r, s) signature structure, which is attached to the subsequent Type-4 transaction to achieve account authorization and upgrade. For detailed implementation, see: https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts
Verification method: The consensus layer verifies by ecrecover(digest7702, sig) == tx.from.
Security design: The web version cannot induce users to authorize any Delegator because the signEIP7702Authorization method is implemented only within the MetaMask wallet and is not open for web calls through window.ethereum. Signature methods accessible from the web, such as eth_signTypedData_v4, are not suitable for EIP-7702 authorization signatures, and their signature digest format is as follows:
The signature format required by the EIP-7702 specification is:
Because eth_signTypedData_v4 always includes the 0x1901 prefix and the digest calculation process is completely different from 7702, it is almost impossible for digest712 == digest7702, even if cleverly constructed domainSeparator, primaryType, and message.
Therefore, the web version cannot forge a legitimate 7702 authorization signature through this method. In addition, MetaMask implements a whitelist mechanism for Delegator addresses, which by default allows authorization only for the official Delegator (0x63c0...32B) and prohibits DApps from injecting addresses themselves, further preventing users from being misled into signing malicious Delegator authorization data. EIP-7702 grants addresses capabilities and flexibility similar to smart contracts, and more and more 7702 applications are continuously being created, which is crucial for bringing more people into Web3 and enhancing user experience.
However, the flexibility of 7702 and the fact that most users are still unfamiliar with 7702 are being exploited by fraudulent groups. Recently, we have observed that some users have fallen victim to phishing groups like #InfernoDrainer due to MetaMask's 7702 batch execution capability, leading to what originally required dozens of authorizations being merged into a single transaction, resulting in asset theft.
Note: MetaMask itself has no security issues. MetaMask prioritizes user safety when providing 7702-related capabilities and has implemented many security measures. Users need to understand more about the capabilities and related risks of 7702 to prevent such security incidents from happening again.
One, Principles and Security Design of MetaMask 7702 Delegator Signature Authorization
1. Technical Analysis
Authorized by the user to deploy the Delegator Contract, directing the code field of the user's account to that contract. The current official MetaMask Delegator Contract address: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B
Authorization structure: (chainId, delegatorAddress, nonce, signature) written into authorization_list
Signing method: MetaMask's underlying logic for authorization transactions related to EIP-7702 uses a unified signing logic, specifically the signEIP7702Authorization method. The authorization data digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)) is signed using ECDSA, generating a (v, r, s) signature structure, which is attached to the subsequent Type-4 transaction to achieve account authorization and upgrade. For detailed implementation, see: https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts
Verification method: The consensus layer verifies by ecrecover(digest7702, sig) == tx.from.
Security design: The web version cannot induce users to authorize any Delegator because the signEIP7702Authorization method is implemented only within the MetaMask wallet and is not open for web calls through window.ethereum. Signature methods accessible from the web, such as eth_signTypedData_v4, are not suitable for EIP-7702 authorization signatures, and their signature digest format is as follows:
The signature format required by the EIP-7702 specification is:
Because eth_signTypedData_v4 always includes the 0x1901 prefix and the digest calculation process is completely different from 7702, it is almost impossible for digest712 == digest7702, even if cleverly constructed domainSeparator, primaryType, and message.
Therefore, the web version cannot forge a legitimate 7702 authorization signature through this method. In addition, MetaMask implements a whitelist mechanism for Delegator addresses, which by default allows authorization only for the official Delegator (0x63c0...32B) and prohibits DApps from injecting addresses themselves, further preventing users from being misled into signing malicious Delegator authorization data.
2. Usage Method
Currently in MetaMask, the way to upgrade an existing EOA to a 7702 smart account (Smart Account) is primarily divided into two categories: active upgrade and passive upgrade.
Active upgrade means that the user actively clicks the 'Switch' button in the wallet interface to authorize a specific Delegator Contract.
Passive upgrades occur when users interact with certain DApps that support 7702. When MetaMask detects related operations, it will automatically pop up a prompt suggesting the user complete the upgrade.
2.1 Active Upgrade:
Transaction content: only includes the action of upgrading the account, that is, authorizing a specific Delegator Contract.
Upgrade process: Enter the account details interface of the wallet, click the switch button as shown in the image below, and the user can upgrade from Ethereum Mainnet to a smart account. After clicking switch, a window will appear for the user to sign the current upgrade transaction:
Authorization record: After confirmation, wait for the transaction to be on-chain. Successful on-chain means the user has successfully upgraded to a smart account. Specific authorization transaction information can be viewed on the current wallet address page under **Authorizations (EIP-7702)** on etherscan.
2. Usage Method
Currently in MetaMask, the way to upgrade an existing EOA to a 7702 smart account (Smart Account) is primarily divided into two categories: active upgrade and passive upgrade.
Active upgrade means that the user actively clicks the 'Switch' button in the wallet interface to authorize a specific Delegator Contract.
Passive upgrades occur when users interact with certain DApps that support 7702. When MetaMask detects related operations, it will automatically pop up a prompt suggesting the user complete the upgrade.
2.1 Active Upgrade:
Transaction content: only includes the action of upgrading the account, that is, authorizing a specific Delegator Contract.
Upgrade process: Enter the account details interface of the wallet, click the switch button as shown in the image below, and the user can upgrade from Ethereum Mainnet to a smart account. After clicking switch, a window will appear for the user to sign the current upgrade transaction:
Authorization record: After confirmation, wait for the transaction to be on-chain. Successful on-chain means the user has successfully upgraded to a smart account. Specific authorization transaction information can be viewed on the current wallet address page under **Authorizations (EIP-7702)** on etherscan.
2.2 Passive Upgrade
Transaction content: includes the action of upgrading the account and batch actions interacting with on-chain contracts.
Upgrade process: When the user interacts with certain DApps on-chain, MetaMask will proactively prompt the user that the current transaction can be completed by upgrading to a smart account using batch sending. For example, when swapping certain tokens on Uniswap, clicking the 'Use smart account' button will upgrade to a smart account, and then token authorization and swap will be completed in a single transaction.
2.3 Switch back to regular EOA
Whether using active or passive upgrades to convert the current account to a smart account, the bound Delegator Contract address will be permanently stored on-chain, serving as the current execution logic of the account.
If the user wishes to revert the account to a regular EOA, they need to manually initiate a 'Switch back to EOA' operation. The essence of this operation is to submit address(0) as the new Delegator contract address through an EIP-7702 authorization. Once this transaction successfully goes on-chain, the account's code field will be cleared, and the execution logic will revert to the default empty code, returning the account to a regular EOA state.
Enter the account details interface of the wallet, click the switch button, and the user can switch from Ethereum Mainnet back to a regular EOA account.
After clicking confirm, wait for the transaction to be on-chain. Successful on-chain means the user has switched from a smart account back to a regular EOA account. The specific transaction information can also be found on the current wallet address page on etherscan.
Two, 7702 Phishing Attack Example
On May 24, the #InfernoDrainer phishing gang used the MetaMask 7702-Delegator contract's batch execution function to defraud user (0xc6D2…06DC) of token authorization and carried out phishing attacks, resulting in losses exceeding $146,000 in $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual.
Fraudulent Address
0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181
Phishing transaction example
https://etherscan.io/tx/0x09c264618e93983510aaeb7aa2c91c8254a8b2ec66167438f3f6c28b866b6eba
Reasons for phishing
User (0xc6D2…06DC) executed a malicious batch authorization transaction:
Ethereum Transaction Hash: 0x1ddc8cecbc... | Etherscan
Call 0xe9ae5c53 Method By 0xc6D289d5...0d2E606DC on 0xc6D289d5...0d2E606DC | Success | May-23-2025 02:31:35 PM (UTC)
etherscan.io
#InfernoDrainer and #PinkDrainer are experimenting with more covert and impactful phishing black industry chains utilizing 7702.
According to our research, the current phishing black industry gangs #InfernoDrainer and #PinkDrainer are studying and experimenting with more covert and impactful phishing black industry chains using 7702. The relevant addresses are as follows, and we will release a more detailed report later:
Inferno Drainer:
0x0000db5c8B030ae20308ac975898E09741e70000
Pink Drainer:
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Three, Security Recommendations
Wallet Provider:
Refer to MetaMask's implementation and security management of 7702 Delegator, prohibiting users from authorizing any Delegator and only allowing in-app operations. Remind users that any behavior that prompts users to sign authorization through the web is a phishing attack.
Check if the chain matches the current network and remind users of replay risks when signing with chainID 0.
Display the target contract when users sign authorization, and show specific function call content when users execute batch operations through Delegator, reducing the risk of phishing attacks.
User:
Private key protection is always the most important. Not your keys, not your coins.
Do not authorize Delegators based on any independent webpage; safe authorization typically occurs within the app, like MetaMask.
When signing with any wallet, carefully review the content of the signature to avoid blind signing or erroneous signing. After clicking confirm, wait for the transaction to be on-chain. Successful on-chain means the user has switched from a smart account back to a regular EOA account. The specific transaction information can also be found on the current wallet address page on etherscan.
Two, 7702 Phishing Attack Example
On May 24, the #InfernoDrainer phishing gang used the MetaMask 7702-Delegator contract's batch execution function to defraud user (0xc6D2…06DC) of token authorization and carried out phishing attacks, resulting in losses exceeding $146,000 in $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual.
Fraudulent Address
0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181
Phishing transaction example
Reasons for phishing
User (0xc6D2…06DC) executed a malicious batch authorization transaction:
#InfernoDrainer and #PinkDrainer are experimenting with more covert and impactful phishing black industry chains utilizing 7702.
According to our research, the current phishing black industry gangs #InfernoDrainer and #PinkDrainer are studying and experimenting with more covert and impactful phishing black industry chains using 7702. The relevant addresses are as follows, and we will release a more detailed report later:
Inferno Drainer:
0x0000db5c8B030ae20308ac975898E09741e70000
Pink Drainer:
0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624
Three, Security Recommendations
Wallet Provider:
Refer to MetaMask's implementation and security management of 7702 Delegator, prohibiting users from authorizing any Delegator and only allowing in-app operations. Remind users that any behavior that prompts users to sign authorization through the web is a phishing attack.
Check if the chain matches the current network and remind users of replay risks when signing with chainID 0.
Display the target contract when users sign authorization, and show specific function call content when users execute batch operations through Delegator, reducing the risk of phishing attacks.
User:
Private key protection is always the most important. Not your keys, not your coins.
Do not authorize Delegators based on any independent webpage; safe authorization typically occurs within the app, like MetaMask.
When signing with any wallet, carefully review the content of the signature to avoid blind signing or erroneous signing.