We've just come accross an issue that Kernel accounts revert with the AA21 didn't pay prefund error during the estimation phase - when calling simulateHandleOps method of EntryPoint - although the sender had enough funds.
I believe this is because Kernel.validateUserOp requires a signature to be valid before sending missingAccountFunds.
|
} else { |
|
return SIG_VALIDATION_FAILED; |
|
} |
|
if (missingAccountFunds != 0) { |
|
assembly { |
|
pop(call(gas(), caller(), missingAccountFunds, 0, 0, 0, 0)) |
|
} |
|
//ignore failure (its EntryPoint's job to verify, not account.) |
|
} |
|
userOp.signature = userOpSignature; |
I'd suggest that Kernel.validateUserOp pays missingAccountFunds regardless of a signature otherwise it hurts UX (because we would be asking users for 2 signatures to send 1 userop)
Reference:
https://github.com/eth-infinitism/account-abstraction/blob/0a9d55ca73cd309f4ec1cda28284d2d039e552b9/contracts/core/BaseAccount.sol#L42-L48
We've just come accross an issue that Kernel accounts revert with the
AA21 didn't pay prefunderror during the estimation phase - when callingsimulateHandleOpsmethod of EntryPoint - although the sender had enough funds.I believe this is because
Kernel.validateUserOprequires a signature to be valid before sendingmissingAccountFunds.kernel/src/Kernel.sol
Lines 145 to 154 in 50bd922
I'd suggest that
Kernel.validateUserOppaysmissingAccountFundsregardless of a signature otherwise it hurts UX (because we would be asking users for 2 signatures to send 1 userop)Reference:
https://github.com/eth-infinitism/account-abstraction/blob/0a9d55ca73cd309f4ec1cda28284d2d039e552b9/contracts/core/BaseAccount.sol#L42-L48