timelocked proxy contract

[Byron-McKeeby]

implements a timelocked proxy with EIP 1967 storage. The admin or governance may register a new implementation address

Design notes:

• changeover is checked on all user calls
• only 1 change can be queued at a time
• the admin and governance addresses can ONLY access the proxy management functions. they CANNOT access the target implementation.
• storage changes must be ADDITIVE ONLY
• selector clashes are avoided via the ifAdmin functionality. However, the public view functions may clash with the target implementation

Limitations/questions:

• Should there be limits on changing governance/admin addresses?
• Timer is set on construction and cannot be changed afterwards
• No upgradeAndCall due to necessity of storing the calldata in eip1967 storage (which would be so annoying)

[Byron-McKeeby]

the new architecture uses inheritence to encapsulate access to shared state. storage addresses for shared state are hardcoded to eip1967 standard there are 2 of these encapsulation contracts. One stores a Storage references and mediates access to it. It is used by the GovernableProxy and exposed to all its descendents

The other (ProxyVaultStore) stores Vault state that affects initialization. This includes ERC20Detailed info, numerator, denominator, etc.

because storage access must be done via assembly, the ProxyVaultStore has somewhat hacky handling of name and symbol strings, and I would appreciate review to ensure that they are handled correctly

[breadforthepeople]

Thank you. The proxied vaults were implemented and this code was taken into account as an inspiration.