Handling of smart contract upgrades (or re-deployments)

[philippecamacho]

How to we handle upgrades? Deploy new version, use proxy etc. making sure it works with all the components.

Information from related issue: notion page

" how do we think about upgradeability? (also a Q for eng) -- if we need to integrate with DeFi down the line do we need to think about this now? what are the things that are difficult to upgrade? (eng Q)

[alxiong]

I suggest we use non-upgradable contract for now since there's no clear benefit of making it upgradable, and only make sense to consider it during mainnet launch further down the road. (Even for Uniswap, their V2 and V3 are all non-upgradable contracts, I think easier to reason about trust issue in proxy pattern)

If we have to go for upgradable contract, use OZ's plugin

[sveitser]

I agree on not using an upgradable contract.

I think there are some remaining questions on how (or when) we would deploy a new versions of the contract.

From the top of my head:

• How likely are we to deploy new versions of the contract after the initial launch? If the the answer is "extremely unlikely" we can skip the other questions below but I don't think it is that unlikely.
• Do we need to migrate any state if we deploy a new version? I don't know if this is feasible but at least doesn't sound easy.
• Do we consider everything in the old version lost (probably easiest) or do we have to do better?
• How do coordinate updates if multiple components need to be updated together?

[alxiong]

Do we need to migrate any state if we deploy a new version? I don't know if this is feasible but at least doesn't sound easy

I have never heard of any project migrating contract state. We can safely assume we won't do that imo.

Do we consider everything in the old version lost (probably easiest) or do we have to do better?

yes, the former, like Uniswap V2 and V3 co-exist, but with official UI directly to the latest contract by default, and advocating Liquidity Provider to migrate their liquidity over by themselves.

How do coordinate updates if multiple components need to be updated together?

same answer as above, just versioned access https://v1.cape.net and https://v2.cape.net; inside our code, we would probably have to add feature flag for version-dependent logic/functions, or if they are too pronounced (such as smart contracts), then we would split them into a separate repo.