Wallet
Last updated
Last updated
RIP-7560 requires implementing a new interface in wallets for transaction validation.
Each parameter in the function has meanings as follows:
| Name | Type | Description |
|---|---|---|
The return of validateTransaction means only success or failure. Account contact must be implemented to validation data be delivered via a callback function call defined below to AA_ENTRY_POINT.
Calls to the AA_ENTRY_POINT approval callbacks have the following meaning:
acceptAccount - This callback is called by the account after it verified the transaction and agreed to pay for its execution.
sigFailAccount - This callback is called by the account if the transaction is syntactically valid, but the authorizationData is incorrect.
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 |
|---|---|
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.
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 TransactionTypeRIP7560 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,
nonceKey,
nonceSequence,
sender,
deployer,
deployerData,
paymaster,
paymasterData,
executionData,
builderFee,
maxPriorityFeePerGas,
maxFeePerGas,
validationGasLimit,
paymasterValidationGasLimit,
paymasterPostOpGasLimit,
callGasLimit,
accessList,
authorizationList,
authorizationData
]
transaction
bytes
ABI encoding of the following struct.
struct TransactionTypeRIP7560 {
address sender;
address deployer;
address paymaster;
uint256 nonceKey;
uint256 nonceSequence;
uint256 builderFee;
uint256 maxFeePerGas;
uint256 maxPriorityFeePerGas;
uint256 validationGasLimit;
uint256 paymasterValidationGasLimit;
uint256 paymasterPostOpGasLimit;
uint256 callGasLimit;
bytes deployerData;
bytes paymasterData;
bytes executionData;
bytes authorizationData;
address[] authorizationList;
bool[] authorizationListStatus;
}
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.