Wallet

New Interface for Transaction Validation

RIP-7560 requires implementing a new interface in wallets for transaction validation.

function validateTransaction(uint256 version, bytes32 txHash, bytes transaction) external returns (bytes32 validationData);

Each parameter in the function has meanings as follows:

Name	Type	Description
version	uint256	For backward compatibility and future extensibility, this is used for versioning of the current Native AA scheme (RIP-7560). Currently, the only valid value is 1.
txHash	bytes32	Means transaction hash. Unlike ERC-4337, calculation of tx hash does not require an Entrypoint address. It is calculated as follows: keccak256(AA_TX_TYPE || 0x00 || rlp(transaction_payload) Note that chainId and access_list is included in the transaction_payload, but not in the following TransactionType4 struct. Also, unlike the calculation of userOp hash, the transaction payload must be rlp-encoded before being hashed. The payload format will be as follows: [ chainId, nonce, sender, deployerAndData, paymasterAndData, callData, builderFee, maxPriorityFeePerGas, maxFeePerGas, validationGasLimit, paymasterValidationGasLimit, paymasterPostOpGasLimit callGasLimit, accessList, signature ]
transaction	bytes	ABI encoding of the following struct. struct TransactionType4 { address sender; uint256 nonce; uint256 validationGasLimit; uint256 paymasterValidationGasLimit; uint256 paymasterPostOpGasLimit; uint256 callGasLimit; uint256 maxFeePerGas; uint256 maxPriorityFeePerGas; uint256 builderFee; bytes paymasterAndData; bytes deployerAndData; bytes callData; bytes signature; }

The return data should be in the following format. Here, validUntil and validAfter are in uint48 format, as in ERC-4337. MAGIC_VALUE_SENDER is encoded in 20 bytes, with only the first 4 bytes occupied. This is to ensure forward compatibility with signature aggregation functionality.

[Return data]
MAGIC_VALUE_SENDER <20 bytes>, validUntil <6 bytes>, validAfter <6 bytes>

Wallet providers need to modify or add to their wallet interfaces accordingly.

Changes need to be made on Wallet SDKs

Since the Entrypoint is removed, the Wallet SDK also needs modification. For example, Wallet Providers using permissionless.js need to adjust the following methods:

Method	Changes
getUserOperationHash	Should modify the calculation logic to match the hash format of AA_TX_TYPE transactions.
getUserOperationReceipt	Entrypoint address will not be displayed on the output. The old values will be mapped into the newly introduced fields, such as userOpHash to transactionHash.
sendUserOperation	Should change the input data. For example, preVerificationGas is now interpreted as builderFee, nonce as bigNonce, and initCode as deployerData.
getAccountNonce	Should query the NonceManager predeployed contract instead of Entrypoint. The calldata should be 44 bytes long (excluding the selector), composed of sender (20 bytes) + key (24 bytes).
getSenderAddress	Since the SenderCreator provided in the Entrypoint is no longer available, initCode (deployerData) is executed directly against the factory address. Thus, the sender address must be extracted directly from initCode.

Other functions and interfaces relying on the Entrypoint will also need adjustments.

The RPCs provided by existing ERC-4337 Bundlers will remain, except for eth_supportedEntryPoints. The response formats for eth_getUserOpbyHash and eth_getUserOperationReceipt remain the same as before, but the fields will be mapped to the equivalent fields introduced in RIP-7560. For example, initCode at the result of eth_getUserOpbyHash will contain deployerData of RIP-7560.