In an upgradable smart contract implementation, should I limit the logic contract to accept only delegate calls?

I have implemented an upgradable smart contract, as per the specifications of EIP1822. Should I limit the logic contract to accept only delegate calls? I have noticed that in some sample implementations of EIP 1822. Is there any specific reason for it?

Hello @cypheronline

Its often not needed to have that kind of protection for all function. You should however make sure your implementation cannot be self-destructed by anyone. This is often done by locking the implementation (calling the initializer with empty parameters) and making sure the contract doesn't call delegatecall to any arbitrary address.

This security advisory discusses this kind of attacks

1 Like

Thanks @Amxx
From your explanation I can clearly understand the need for strictly restricting the outgoing delegate calls of a proxy contract to an authorized logic contract only. But what I would like to understand is the reason behind the delegateOnly modifier being used on the functions of logic contract. How does it secure the contract?

If there is a function that can trigger selfdestruct, it's a good idea to protect the implementation contract using the delegateOnly modifier (I think we call it onlyProxy). Note that it's possible to indirectly trigger selfdestruct through a delegatecall, so if there is a delegatecall to an arbitrary or otherwise dangerous contract, the modifier makes sense there as well.

1 Like