Discuss and come up with an upgrade strategy for community vaults

[0x-r4bbit]

If we're implementing #31 we specifically add APIs for certain EIPs.

This raises the question of what will happen if at some point in the future other token types should be officially supported by community vaults. It might mean that a vault needs new dedicated APIs for those new token types.

This in turn means communities need to either a) create a new vault and eventually manage multiple vaults with funds being spread across these vaults, or b) there's a migration/upgrade path for vaults that communities can opt-in to, which would move the funds to the new vault and locks the old one.

Let's think about what a reasonable path would be.
I personally liked the approach that @3esmit has taken in the staking project. Maybe we can use the migration methods there as an inspiration for the community vault migration as well?

@gravityblast wdyt? Please discuss options/ideas here.

[0xb337r007]

@0x-r4bbit
I have 2 ideas for now but let me know if you have any other ideas.
I'm thinking about:
1 - manual migration of the tokens
2 - contract upgrade executed by community managers

With manual migration we can implement something like this POC main...feat/migrate-tokens

Otherwise we can explore a way to let community owners upgrade the Vault implementation. With this option we still want to let the community admins be the owner of the proxy.

With option 1 we have a simple implementation but migrating might be expensive when the vault has a large amount of tokens.

With option 2 the upgrade would be very simple, but implementing it might be more difficult.
A minimal proxy might be an option, but all this implementation usually have one address that can be the admin. So we would need this admin address to be another contract owned by the community admins.

[0x-r4bbit]

Thank you @gravityblast for putting this up.

Option 1) seems very straight forward, easy to follow and I'd say rather "predictable".

If we explore option 2) the way I could see this work, and this is just me thinking out loud, we'd have:

• A communityWalet contract (the way it exists right now), but it'd really just as a destination for funds
• A communityVault, which would operate on the wallet

Community owners can then deploy and change communityVault implementations, maybe even combining it with some sort of proxy so that their endpoint address never changes, and the vault contract would always operate on the underlying wallet contract.

Then, if there's a new vault implementation, it just needs to know the wallet address and then does whatever it needs to do on top of that. We wouldn't need to migrate funds as they always stay in the same location, but we'd be changing the business logic and access to it.

@0xb337r007 do you think it makes sense to build a (simple) PoC for such a set up as well? Or maybe this is totally off?

[0x-r4bbit]

@0xb337r007 let's get your PoC in shape to close #33 as a starting point. It'll do the job and if we think later that we need a different path, we can revisit this.