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?