EIP-3074 Invoker with Permissions

I had been working for a few weeks on an EIP-3074 invoker with permissions. It enables an EOA to use Kernel features such as issuing a session key or using a passkey as its key.

View the EIP-3074 invokers repository.

Warning: The code is still a work in progress and has not been audited. The testing environments and Solidity compiler have not been audited either. Use it only for testing.

Why validator modules were not enough

My first attempt was to build an ERC-7579 validator-compatible invoker, but it exposed some limitations. The validator type expected msg.sender to be the owner and stored data mapped to msg.sender.

Because an EIP-3074 invoker uses a multi-tenant model, validator modules are not compatible with this scenario without a way to separate storage for each authority. This can be solved by storing data on the invoker while using a stateless validator, or by using permissions.

I already had a working example of permissions. Because not every feature can be stateless, I chose the permission model built on the ERC-7579 extension types Policy and Signer.

Policy and Signer have a special id parameter that provides a context identifier, which the wallet vendor can choose. Using the authority address as the id separates storage for each authority and lets the model work with a multi-tenant EIP-3074 invoker.

What permissions enable

An EOA can use session keys and passkeys by composing policies and signers, including stateful validation modules, much like Kernel v3 does.

There are limitations. You cannot expect AUTH to work even after validation passes. This is not fully compatible with ERC-7579 because an EOA cannot have code. Still, the experiment showed that the features EIP-3074 can enable for EOAs are not limited to batch calls.

At ZeroDev, we are working on a permission invoker demo to show what EIP-3074, ERC-4337, and permissions can enable.

Special thanks to @julrach, @jxom, @annascarroll, and @eniwhere for their EIP-3074 work.