" This is a feedback only submission. Due to missing functionality in the 7715 snap I was not able to implement the feature I had envisioned.

The project

I wanted to create a simple cli tool + webapp that allows you to delegate the ability to update your ENS contenthash from the command line securely.

Design

Design was simple:

1. create an account in the cli

2. Copy the account address from (1) to the webapp and create a delegation with the following delegations to it:

   1. 'allowed-targets': the resolver of the ENS domain

   2. 'allowed-methods': 'setContenthash'

   3. 'allowed-calldata': the ens name (first param of (2))

3. Display delegation and allow user to copy it into the cli tool

4. Cli tool can now at any time update the contenthash for the given ENS name, but can not change anything else about the ENS name

Uncovered issues

The main problem I discovered was that the 7715 implementation doesn't support the caveat enforces mentioned above. By analysing the '@metamask/permissions-kernel-snap' bundle code with Gemini it looks like only the following permissions are allowed:

• native-token-stream

• native-token-transfer

• erc20-token-transfer

• erc721-token-transfer

• erc1155-token-transfer

Only using these permissions it seems impossible to achive my goal. Hence I abandoned this project.

General feedback

Diving into the tooling I have some general feedback to provide on the delegator framework and the overall approach to account abstraction by MetaMask.

User experience

• Installing snaps kind of sucks and is confusing from a user experience perspective imo. To use 7715 I even had to install two separate snaps. If we want a 7715 like grant permission flow to become the standard, it needs to be the default

• What is a "Gator Account"? This question caused me (as a user) a lot of confusion and searching around in the MM UI. I understand this will be less of an issue once 7702 is supported

Developer experience

• Found and reported this issue: https://github.com/MetaMask/templated-gator-7715/issues/3

• I was really missing some API docs. The provided documentation mostly contained examples, but examples tend not to be comprehensive. I mostly find it more helpful to just read the API docs instead

• docs for client.grantPermissions was completely(?) missing. I only knew to use it through the example app.

• The client.grantPermissions only allows for a single 'permission' object, while in eip7715 the same method defines a 'permissions' field which takes an array of permissions objects.

  • This is important because even if the 7715 snap supported all the caveat types I needed for my project if I only could request one per delegation I would not be able to restrict the permissions properly

• It would also have been helpful to have an architecture diagram of how the smart contracts come together. After reading eip7710 I got the general idea, but would still be useful to better understand how caveat enforcers etc. work in the system

Architecture

Overall I found the smart contract architecture a bit confusing. I really like the idea of how permissions are requested through 7715 and the existing caveat enforcers are really nice and comprehensive (as defined by the docs, I also wish they were implemented and usable ;) ).

Session accounts

It took a while before I fully grasped that session accounts are 4337 smart accounts. Because of how 7710 is design I understand this is the only way to make the session keys able to submit gasless transactions? However, that now meas that the transactions submitted no longer originates from the account in my MM wallet.

It does look like it's possible to delegate to a "key type" instead, but then I would need to add gas to that account to support 7710 transactions?

eip7710 design

I might be missing some important detail, but overal I feel like 7710 add unnecessary complexity to a problem that could be solved within 4337. I would like to be able to have the same caveats as defined with 7715 but for session keys to be able to through these capabilities act on behalf of my account more natively (4337 style)

Redesign proposal

I'll caveat this with saying I'm just newly diving into the 4337 design space. As I wasn't really satisifed with the 7710 approach I tried to figure out how to harmonize 7715 with the overall 4337 landscape.

eip7579 modules

The functionality that 7710 provides (I belive) can be implemented as modules as defined by eip7579. The caveatEnforcer framework roughly matches the 'hooks', and the ability to verify delegations could be implemented as a 'validator'.
Finally the UserOp.signature field is where we could encode one or multiple delegations. The custom validator would then parse this signature blob and validate the delegation chain.

This (these?) modules could then easily be integrated into any smart wallet that chooses to adopt them.

eip7715 signers

Currently eip7715 list a bunch of different signer types. From my perspective this seems like a lot of complexity for something that ethereum already has an abstraction around, i.e. the ethereum address. As long as the eip7579 module above can verify EOA signatures as well as arbitrary 4337 verifications, it seems to me that the ethereum address abstraction should be enough.