Thanks for the reply, @abcoathup!
The why is simply that, for our use case, we want the admin to be able to use the proxy contact like other users can. I won’t bore you with details because this is obviously something we could redesign as you suggest if there were a pressing need to do so (e.g. for security reasons), and we may do so later anyway, but in the short run this approach is more convenient if the “only” reasons to redesign are separation of concerns & avoiding function signature clashes.
Re: using OpenZeppelin SDK, it’s our intention to go that route eventually, if for no other reason than to get the storage layout back-compatibility checks. But it seems non-straightforward because we have the following non-standard requirements:
- the aforementioned requirement for the admin to have full use of the proxy
- this is an existing multi-contract system, with numerous truffle migrations that we would rather not re-write
- we want to change one of the existing contracts to be upgradable, by separating logic from storage, but this contract is deployed by a factory contract (rather on the command line)
I know you have example code that illustrates a system with some of these properties, but moving our system with all of these properties into your SDK seems to involve some effort and risk. (If you disagree, I’d welcome pointers!) Hence this intermediate step.