-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: EIP-4337 Support through hooks #178
base: master
Are you sure you want to change the base?
Conversation
86371b3
to
ce7c2de
Compare
We should be moving in the direction of an EOA guard anyway, that's what WaaS uses and it would also be good for the universal wallet (more secure). |
contracts/hooks/EIP4337Hook.sol
Outdated
*/ | ||
function eip4337SelfExecute(IModuleCalls.Transaction[] calldata txs) external payable onlyEntrypoint { | ||
// Self execute | ||
(bool success, ) = payable(address(this)).call{value: msg.value}( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI native .call
copies return data into memory even if you don't define it. Either use LibOptim.call
or use the returned data directly.
Here's an implementation of EIP-4337 that can be added as a hook.
Support is only valid (due to opcode restrictions) when the tx signature doesn't validate against nested Sequence wallets (due to accessing imageHash on the nested wallet and potentially GAS op code usage).
This means signatures including the guard will fail. A temporary solution could be adding an EOA based guard or increasing the threshold of the session key.