Designing the protocol to be migrateable (but not upgradeable)

[PaulRBerg]

Description

I think that we all agree that making the protocol upgradeable would be too much of a liability for us. It would basically make us custodians.

It just so happens that I have recently been involved in a Twitter discussion about this very topic with Adam Cochran, who made this point:

I’m actually suggesting upgradable contracts are dumb. Hard code versions and let people migrate between.

I think that this is a known pattern in the industry but I can't recall off the top of my head how it's called. Anyway, the idea is the following:

1. We build the protocol in such a way that it has a "migrate" function that basically transfers a stream from the _streams mapping to another v2.x Sablier contract. The transfer would basically delete the stream in the v2.n contract and re-create the stream in the v2.(n+1) contract, all while not making any claim of funds for either the sender or the recipient.
2. We add a state variable nextSablierV2Linear of type address that is initially set to zero but which can be subsequently modified by governance. This is the future address of the v2.x Sablier contract.

Pros

I personally find this model great, because:

1. It gives us flexibility to keep developing v2.x in a proper, logical way.
2. It doesn't make us custodians in any way whatsoever.
3. It doesn't coerce users into accepting an upgrade of the contract. It's up to them to decide if they want to migrate.

Cons

1. Added development costs (and a bit of added complexity in the contracts themselves).
2. Huge maintenance costs at the front-end level. We would have to maintain the front-end for every v2.x release, and for every migration between them.

[PaulRBerg]

Unfortunately, it's quite likely that we will not have time for this.

[PaulRBerg]

Interestingly, centralized migration operations are a thing now. Maple V2 has been recently announced, and as part of this release, they auto-migrated all user funds from V1.

Taking such actions is obviously quite dangerous from a regulatory point of view, but it does provide a great user experience.

[PaulRBerg]

Closing since our recent decision to switch to a proxy design (as discussed in sablier-labs/v2-periphery#11) will automatically enable migrations.