Issues with Delegatable-based Session-Key

[xcshuan]

Currently, we are considering the possibility of using Delegatable as a Session Key solution for our Contract Wallet (UniPass), but we have some questions that we would like to discuss with you.

1. Gas cost

I noticed that Delegatable is advancing the integration with 4337, delegatable-4337.

At present, 4337 already brings a lot of extra gas overhead, and Delegatable will too. The combination of the two may cause extra gas overhead that users cannot afford.

The question is, what benefits does 4337 compatibility bring to Delegatable? In my opinion, the greatest usefulness of EIP4337 is that there is a mechanism to help users submit transactions after the smart wallet operator stops, but I think full compatibility with 4337 will restrict the ability of Delegatable.

2. CallData & State

Currently, in order to save gas, Delegatable signs the delegation off-chain, and then places it in calldata every time it is used. This gas saving is useful for ETH, but for Layer2, it is likely to cause more gas costs, because Layer2’s calldata need to submit to Layer1.

Perhaps Delegatable can consider adding some mechanisms to adapt to Layer 2. For example, after a Delegation is used for the first time, it will be recorded in the on-chain state, and subsequent uses do not need to continue to occupy calldata. This can be used as an option for contracts that want to integrate Delegatable.

3. Single delegation for multiple txs

The current Delegatable has a corresponding delegation for each transaction, which makes it necessary for the delegate to reuse the same Delegation sequence when he wants to use the delegation to execute multiple transactions, which greatly increases the size of the calldata.

Perhaps the Invocation can be changed to the following:

struct Invocation {
  Transaction[] transactions;
  SignedDelegation[] authority;
}

4. Other issues

• In the current design of Delegatable, the format of the delegate can only be an address, but in fact, we can give the delegation to a Passkey or Email (verified by DKIM), and the address format restricts the use of new authentication methods.
• The current CaveatEnforcer can add some verification:

  • firstly, post-verification, that is, some verification of the execution result can be performed.

  • second, the delegate that specifically made this invocation can be used as an input argument, and some verification can also be performed, for example, check that the delegate should own a certain NFT or be a member of a certain Dao.