About proxyAdmin for TransparentUpgradeableProxy.sol

[idyllsss]

🧐 Motivation
My concern is whether it is reasonable to forcibly generate a new ProxyAdmin in the constructor of TransparentUpgradeableProxy.sol:

📝 Details
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/proxy/transparent/TransparentUpgradeableProxy.sol

constructor(address _logic, address initialOwner, bytes memory _data) payable ERC1967Proxy(_logic, _data) {
    _admin = address(new ProxyAdmin(initialOwner));
    // Set the storage value and emit an event for ERC-1967 compatibility
    ERC1967Utils.changeAdmin(_proxyAdmin());
}

If I want to use a TimelockController as the ProxyAdmin, it becomes very difficult. The contract's extensibility seems to be reduced.

[ernestognw]

Hi @idyllsss,

We had a long discussion around this and concluded that both contracts are tightly coupled since the ProxyAdmin can't do other than upgrade its corresponding proxy and the proxy doesn't allow the admin to interact in any other way.

The case where a TimelockController is the upgrader, then the ProxyAdmin can be owned by a TimelockController instead. Making the TimelockController the ProxyAdmin itself will prevent it from performing any other action (e.g. if your proxy is a token and the TimelockController has balance, it won't be able to transfer if it's the admin).

Let me know if that works!