On the “sign code” vs “sign address” debate:
First of all, just wanted to be clear about my current stance that signing an address is fine. IMO It is slightly less expressive and removes some interesting use cases that were possible with EIP-3074, but my personal opinion is not that it is fundamentally problematic. Just wanted to share some my point of view so it is considered for the EIP from a “feature” point of view.
AFAIU, the current rationale around signing an implementation address instead of some template code is that it is shorter (less than half the amount of data - 20 bytes vs 45 bytes for the min-proxy code) and that it does not add any additional value. However, I believe it does add additional value, as it enables keys to sign additional context that is accessible on-chain that can be used in a number of (IMO) interesting cases over the current suggested proxy approach. In particular, it can serve a similar purpose to the commit argument from EIP-3074: some additional piece of data that is included in what ultimately gets signed by the account.
In order to not be super generic, I am going to focus on a particular use cases that I believe directly benefit from signing template code instead of a delegation address: account initialization. Currently, the suggested approach to using 7702 to upgrade an EOA to a SCA is to replace code with the suggested proxy implementation linked above. The proxy then takes care of initialization in the cases where the proxy is being used for the first time. This require the initialization to be authenticated using a signature from the EOA, meaning that all 7702 upgrades require at least 2 signatures (one for the 7702 signature, and one for the initialization). It is possible to reduce this to 1 signature in the case where tx.origin is permitted to set code with some minor modifications to the suggested proxy (it can skip the ecrecover if address = tx.origin), but only without gas sponsorship (since the EOA is the tx.origin in this case).
If we were to sign template code instead of an address then this minor downside can be worked around. Specifically, minProxy(implementation) || commit can be used as the code, i.e. you append some commit parameter to the min-proxy code as some additional metadata that doesn’t actually execute, but can be used on-chain as a source of some additional signed data. This allows flows where SCA implementations can accept initialization without additional signatures and instead compute some hash(initializationParameters) and compare it to the last 32 bytes of the account code with extcodecopy, therefore, enabling EOAs to be upgraded to SCAs with a single signature (even with gas sponsoring). This also unlocks some fringe use cases where, for example, you use Nick’s method to generate random 7702 signatures for single use accounts with a pre-determined initial configuration for which you are guaranteed to not have a private key (although, the actual usefulness of this is questionable at best, however a use case that was possible with 3074).
Again, this isn’t a particularly strong argument to justify “WE MUST SIGN CODE!”, but I wanted to share my slight preference for signing code instead of a delegation address.