EIP-7702 Paymaster Specific Vectors

EIP-7702 is one of the execution upgrades in the Pectra update scheduled for the first half of 2025, and it is compatible with the existing AA system. If EIP-7702 is applied, EOAs can take on the role of CAs, and since the handling of UserOperations will change, several issues may arise if the existing system is applied as-is.

Since there is no implementation yet and it is still in the concept stage, this is a compilation of potential vulnerabilities that could arise based on the conceptual overview.

For a comprehensive understanding of EIP-7702, please refer to the official document here.

Alternatively, please refer to the Resources section in our paymaster documentation.

Nonce value management issue

If an authorized account directly manages the nonce, it could increase the nonce right before a paymaster processes a UserOperation. This could potentially result in an attack on the reputation of the paymaster.

Incrementing the nonce in EIP-7702 is equivalent to invalidating authorization.

Example Code

op.nonce++; // increasing nonce

try validateUserOp(op, opInfo.userOpHash, missingAccountFunds)
returns (uint256 _validationData) {
    validationData = _validationData;
} catch {// validation fails by increasing nonce
    revert FailedOpWithRevert(opIndex, "AA23 reverted", Exec.getReturnData(REVERT_REASON_MAX_LEN));
}

• Mitgation: To address this, relayers should consider implementing a deposit or a reputation system.

---

Account that does not increment the nonce

If the nonce is managed by the account instead of the EntryPoint (EP) as a backup measure, a malicious account could reuse operations by not incrementing its nonce, potentially executing a replay attack.

In this case, the same UserOperation (UP) could be repeatedly executed, launching a gas-griefing attack on the sponsor.

Example Code

// op.nonce++; 

A situation where the section responsible for incrementing the nonce is commented out, resulting in the nonce not being updated

• Mitgation: The nonce should be managed by a defined, separate entity or trusted third party to prevent abuse.

---

Wallet can be tx.origin

If EIP-7702 is implemented, an EOA can temporarily act as a SCW (Smart Contract Wallet) during a transaction. This could bypass reentrancy guard logic in paymasters, which currently protects against such attacks.

Imagine a paymaster contract that uses a require(msg.sender == tx.origin); check to prevent reentrancy attacks, trusting that only EOAs (not contracts) can initiate transactions. With EIP-7702, an EOA can temporarily gain smart contract-like functionality and bypass this restriction. During a transaction, this EOA acting as a SCW could call back into the paymaster, circumventing the tx.origin check and potentially exploiting reentrancy vulnerabilities, leading to unintended behavior or funds drain.

require(msg.sender == tx.origin);

Bypassing atomic sandwich protection relying on tx.origin.

• Mitgation: Security logic relying on tx.origin should be avoided.

---

More Difficult to validate UserOperation

If EIP-7702 is applied, an EOA will function like a smart contract, capable of executing code that can invalidate specific transactions or interact with other accounts. In other words, an EOA can dynamically adjust transaction flow through code delegation. This means that one EOA, due to code execution, can potentially cancel or modify another transaction, making it difficult for paymaster to pre-validate transaction legitimacy on the network.

• Mitgation: For EOAs with a non-zero delegation designator, allow no more than two transactions in progress simultaneously, minimizing transaction invalidation.