EIP-5806 Delegate transaction

3 Likes

One of the point I think should be discussed is the “amount” part of the transaction.

Since this transaction is going to delegate call, the amount should not be sent to anyone, and should remain on the sender/signer’s account. The delegate call mechanism cause the code that the is being executed to has access to the entire balance of the account.

Consequently, the amount doesn’t correspond to an actual transfer, and I believe it should not be part of the transaction parameters.

On the other hand, that means that the code being called through the delegate will always have msg.value equal to 0. Is that acceptable?

Amazing concept, would be awesome to have it together with EIP-3074

I think of contract storage as being tied to a specific contract. For instance, when “upgrading” contract code using create2 pattern the new code has to work with existing storage layout. So I am struggling to understand how arbitrary calls to different contracts via delegatecall will work? Sorry if this is a silly question.

I’m sorry I don’t understand.

Only contracts have storage, not EOAs. That storage is managed by the contract’s bytecode. You propose to create storage under the EOA - without any code to manage that storage. I am thinking about issues that arise when using delegatecall, such as storage collisions or the “constructor caveat” mentioned here Proxy Upgrade Pattern - OpenZeppelin Docs . How can you avoid such issues when your EOA’s storage is completely at the mercy of external contracts you delegatecall?