I would like to open a discussion about the possibility of deploying the new Treasury contracts as deterministic non-upgradable proxy contracts.
[NOTICE]: I undestand the new Treasury contracts have been audited and it might be too late to make changes to the contracts, as the risk is to face (now deprecated) Parity-multisig-like issues.
In light of recent multi-chain developments, and the recent Aave governance issue, plus the problems arising from users using a bridge to send tokens on a different blockchain where the same contract does not exist. In the latter case, the user was still able to retrieve funds but had to go through a burdensome process.
This is relevant for the 0x Treasury as, while ZRX voting power only exists on Ethereum, the treasury might receive funds from partner projects on their own blockchain, like occurred with ARB recently. Having the same address on multiple blockchains would eliminate the risk of sending the token to a non-existing contract. Also it would allow to disburse grants on L2s-altchains with tokens on L2s-altchains by voting on Ethereum.
The specification should be as follows:
-
current Treasury contract becomes the implementation of the proxy on Ethereum (would require adaptations to the proxy pattern. The proxy implementation would not be upgadable in the proxy storage and should be a storage parameter, not an immutable.
-
reson for storing non-upgradable implementation in the proxy storage would be to allow deploying the treasury contract with the same address on different chains, but with different implementations and voting strategies.
The proxy should be deployed through a proxy factory which uses the msg.sender and governance name as create2 salt parameters.
In the context of Layer2 chains, operationally, the treasury would receive bridged messages from L1, therefore having a completely different logic and, most importantly, not needing a voting strategy. Technically, the L2 treasury should be a general proxy contract that can only accept messages signed by the L1 treasury.
An implementation of such proxy deployment factory exists on the Rigoblock governance and this factory should not be deployed directly, but through the Safe Singleton Factory.
As a side note, I believe making the proxies upgradable would help the treasury be future-proof, but I believe this could open up some risk of rogue treasury takeover and it will still be possible to use the same technique in a subsequent treasury migration.
I am curious to see if there is interest for one such implementation and if we are still on time. I understand it is a late proposal, but I initially thought the timeline for moving to the new treasury was very short and did not want to cause delays.