ERC-4337 v0.7 - HackMD

# ERC-4337 v0.7 ## UserOperation packing changes Version 0.7 introduces two major changes to the UserOperation structure (all in [PR#363](https://github.com/eth-infinitism/account-abstraction/pull/363)). Obviously, these affect wallet/sdk code, on-chain account contracts and paymasters. This document describes the reasons for these changes. First, we found out that a paymaster must have its own gas limits. Until version 0.6, we “re-purposed” the verificationGas of the account, in order to avoid adding more parameters. However, we found out that this opens a vulnerability for the paymaster. In addition, it requires the paymaster to have a much higher balance set aside, (twice the maximum verificationGas) which it never uses. Consequently, in addition to `verificationGasLimit` and `callGasLimit`, a UserOperation that uses a paymaster must also specify `paymasterGasLimit` and `paymasterPostOpGasLimit`. Adding these parameters to the already crammed UserOperation was tight. Several implementations were already struggling with the dreaded “stack too deep” of EVM and Solidity due to the number of UserOperation fields. The solution (For both the two new gas parameters and the old gas parameters) was to pack these two fields in one “bytes32”, as neither parameter ever gets anywhere close to 128 bits. While all of those parameters must exist in the UserOperation, they are rarely accessed by accounts, so this packing doesn’t change the validation code in those contracts. In addition, the paymaster-related parameters must either be all set, or none of them. Therefore it made sense to pack them all into the `paymasterAndData` field, which can remain empty when not using a paymaster. UserOperation has two account gas-limit fields. It may seem that there is no reason to pack them together, and they could have been left unpacked. However, the stack constraints that have been haunting some implementations indicated that packing them is beneficial. ## RPC API change Version 0.7 also separated the off-chain UserOperation structure, and the on-chain PackagedUserOperation. The reason for that is to abstract the UserOperation struct and make it more compatible with the future native AA RIP-7562. With that RIP, the new transaction is encoded in RLP, and is packed into ABIv2 structure just when calling the smart-contract accounts. In the future, this will allow wallets to use the same RPC calls for ERC-4337 accounts and for EIP-7562 accounts (or even the same account supports both interfaces, on different networks). ## Migration ### Account migration Account migration is always done by replacing the main contract, as the entrypoint contract address is hard-coded (immutable). This account upgrade must include a new validateUserOp which accepts the new UserOperation struct, along with the new entrypoint. ### Wallet migration The account upgrade requires a new wallet version, which supports both the new and the old encoding. Until the account is migrated, it should use the old entrypoint and ABI. Once the account is migrated, the wallet must switch to using the new entrypoint and ABI. ### Paymaster migration Paymasters can’t be used by multiple entrypoints with different interfaces. One of the changes of BasePaymaster is that during deployment it asserts its compatibility with the EntryPoint contract. The `paymasterAndData` field in the UserOp was modified and now includes the paymaster gas limits. To access the verification and postOp gas limits, use the [`unpackPaymasterStaticFields()`](https://github.com/eth-infinitism/account-abstraction/blob/manual-validatePaymasterUserOp/contracts/core/UserOperationLib.sol#L83) helper method or access them directly using the constant offset values defined in BasePaymaster. In addition, to access the paymaster-specific data, you should use the offset constant `PAYMASTER_DATA_OFFSET` (see [usage example](https://github.com/eth-infinitism/account-abstraction/blob/manual-validatePaymasterUserOp/contracts/test/TestExpirePaymaster.sol#L19https://github.com/eth-infinitism/account-abstraction/blob/manual-validatePaymasterUserOp/contracts/test/TestExpirePaymaster.sol#L19)) The paymaster MUST validate that the postOp gas limit value is large enough, otherwise, it might revert due to OOG (at the paymaster’s expense!)