Top 7702 Delegator Revealed as Phishing Scam
Author: GoPlus Security
Pectra is a major Ethereum upgrade, integrating the highest number of EIPs in history—11 in total—greatly enhancing validator flexibility, network scalability, and execution efficiency. With the Ethereum mainnet Pectra hard fork expected to activate on May 7, 2025, the "ultimate form" of Account Abstraction—EIP-7702—has officially become usable!
Quoting OKX Research Institute: "If there’s any EVM-based Web3 wallet that doesn’t support EIP-7702, it’s essentially giving up on the entire Ethereum ecosystem and its users." This fully demonstrates the importance of EIP-7702.
Since the Pectra activation on May 7, what new security risks have emerged, and what EIP-7702-related features have mainstream Web3 wallets implemented? How do these features work? Let’s dive into it with GoPlus.
A Top-Ranked 7702 Delegator Turns Out to Be a Phishing Contract
According to on-chain monitoring at https://www.bundlebear.com/eip7702-authorized-contracts/all, tens of thousands of addresses have already enabled smart account features. Here are the Top 10 7702 Delegators:
However, we were shocked to discover that on ETH, the Delegator address with a high authorization ranking—0x930fcc37d6042c79211ee18a02857cb1fd7f0d0b—is malicious.
Through decompiling the contract code, we found that once a user authorizes this address, any ETH transferred to it will automatically be redirected to the fraudulent address: 0x000085bad5b016e5448a530cb3d4840d2cfd15bc
Important Security Reminder: Exploiting the EIP-7702 hype, the risk of creating malicious Delegate contracts and luring users into authorizing them through phishing is likely to surge first.
GoPlus reminds you: 7702 authorization typically happens within a wallet app or plugin. If you’re prompted to authorize 7702 via email or a URL, it’s usually risky—proceed with caution. Additionally, before authorizing, you can check if the contract is open-source via a blockchain explorer. Be extra vigilant if the contract is not open-source.
MetaMask 7702 Product Features and Source Code Analysis
Product Features
MetaMask now supports EIP-7702. There are two ways to send 7702 transactions via MetaMask:
Through the frontend interface: Details at https://support.metamask.io/configure/accounts/switch-to-or-revert-from-a-smart-account/
When your wallet interacts with a DApp on a 7702-supported network, MetaMask will proactively prompt you to switch to a 7702 smart wallet. You can also manually cancel and revert to a non-smart wallet state.
Using third-party libraries: Details at https://docs.metamask.io/wallet/how-to/send-transactions/send-batch-transactions/#use-third-party-libraries
Important Security Reminder: MetaMask also provides a critical warning: MetaMask will only prompt users to switch to a smart account within the wallet itself. If someone asks you to sign any agreement outside of MetaMask via email or a URL to "upgrade" or "enable" smart account features, it’s definitely a phishing scam—do not trust it!
Source Code Analysis
Contract Address (EIP7702StatelessDeleGator): https://etherscan.io/address/0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B#code
The entire contract is written using stateless design, with all global variables declared as constant or immutable to resolve potential storage conflicts when the same address uses different Delegators.
Batch Transactions
The contract implements batch transaction functionality with the following functions:
execute(ModeCode, bytes calldata): This function allows single or batch transactions and uses the onlyEntryPointOrSelf modifier to ensure the caller is valid.
executeFromExecutor(ModeCode, bytes calldata): This function mirrors execute but is restricted to calls from the DelegationManager.
Both functions ultimately call _execute or _tryExecute in the ExecutionHelper.sol contract to finalize transaction execution.
Gas Sponsorship (Paymaster Logic)
In the MetaMask Delegator Contract, the gas sponsorship logic is backward compatible with ERC-4337 and primarily consists of the validateUserOp and _payPrefund functions:
Check Deposit: The user checks EntryPoint.balanceOf(account address) to confirm if the account’s deposit in EntryPoint is sufficient to cover the estimated gas.
Top-Up Deposit (Optional): If the balance is insufficient, the user can call EntryPoint.depositTo or EIP7702DeleGatorCore.addDeposit to deposit ETH into the deposit pool. If a Paymaster is sponsoring, this step can be skipped, as the Paymaster will handle the top-up later.
Construct and Sign UserOperation: The frontend fills in fields (sender, callData, nonce, paymasterAndData, etc.), and the account’s offline signing logic (_isValidSignature) generates userOp.signature.
Broadcast UserOperation: The complete UserOperation is submitted to any Bundler via eth_sendUserOperation(userOp, entryPoint).
Bundler Bundles and Pays Gas: The Bundler collects multiple UserOps and calls EntryPoint.handleOps(ops, beneficiary), paying the on-chain gas fee upfront.
EntryPoint Pre-Check & Pre-Payment:
Calculate requiredPreFund → Determine _missingAccountFunds.
Call the account’s validateUserOp():
Verify the signature (_validateUserOpSignature).
_payPrefund(_missingAccountFunds): If the deposit is insufficient, the account transfers the shortfall to EntryPoint immediately.
If paymasterAndData is not empty, call the Paymaster’s validatePaymasterUserOp() for sponsorship.
Execute Business Logic: After validation, EntryPoint.executeUserOp() executes the account’s logic (e.g., execute(), redeemDelegations(), etc.) based on callData.
Gas Settlement: EntryPoint calculates the actual gas consumed × effectiveGasPrice and deducts it from the account’s or Paymaster’s deposit. The settled ETH is paid to the beneficiary (Bundler-specified address).
The above is MetaMask’s implementation of gas sponsorship compatible with ERC-4337. If backward compatibility with ERC-4337 is not a concern, the gas sponsorship logic based on EIP-7702 is clearer and simpler, as follows:
The general process involves the "transaction execution account" signing the transaction off-chain and delegating the signature to the "transaction sender account." The "transaction sender account" submits the transaction content and signature to the Delegator Contract, which verifies the signature on-chain. If the signature passes, the transaction is executed; otherwise, it reverts.
Construct the transaction content.
The "transaction execution account" generates the signature.
The "transaction sender account" calls the Delegator Contract with the transaction content and signature.
The Delegator Contract verifies the signature and executes the transaction.
Source Code Reference: https://book.getfoundry.sh/cheatcodes/sign-delegation
OKX Wallet Product Features and Source Code Analysis
Product Features
OKX now supports EIP-7702. To send 7702 transactions via OKX Wallet, you can use the latest version of the wallet plugin or app to upgrade to 7702. Clicking "upgrade" will call the official OKX Wallet Core contract by default, with the function selector corresponding to the initialize() function.Source Code Analysis Contract Address (WalletCore): https://etherscan.io/address/0x80296ff8d1ed46f8e3c7992664d13b833504c2bb#code
OKX Wallet Core creates an external Storage contract for each user to store state variables, resolving potential storage conflicts when the same address uses different Delegators.Batch Transactions
The contract implements batch transaction functionality with the following functions:executeFromSelf: Can only be called by the address itself, no external signature verification required.
executeWithValidator: Can only be called by the Validator contract, authorizing batch execution of multiple transactions via signature verification.
executeFromExecutor: Authorizes execution based on a session mechanism, allowing pre-authorized Session executors to execute, with support for triggering Hook plugins before and after operations.
All the above functions ultimately call the _batchCall function to execute the transactions.
How EIP-7702 Can Better Protect User Asset Security
The EIP-7702 upgrade grants addresses greater flexibility and business capabilities. From our analysis of mainstream wallets’ source code, we see that batch transactions and gas sponsorship are now widely supported. The integration of 7702 with business applications is just beginning, and more applications will emerge in the future, which will be crucial for improving user experience.
From a user security perspective, the EIP-7702 upgrade is equally important, offering new possibilities for security. For example, we can implement precise risk control rules when the Delegator processes transaction data in batches (Excution[] calldata), allowing users to configure custom authorization management, custom blacklists/whitelists, and set limits on the token type and amount for transfers during transactions, enabling robust transaction risk control.
We look forward to the adoption and popularization of EIP-7702, enabling users’ assets to flow more safely and efficiently!
