On the RSK to rollup migration

On the community call today @yago mentioned a couple of options for when Sovryn launches the mainnet rollup version:

  • Users manually migrate
  • The protocol migrates funds for the users

I’m generally of the opinion that SOV holders (the governors of the protocol who would be making this decision) should never migrate user funds. Ideally they wouldn’t even have this capability, and I think we should remove this capability as soon as possible.

If we intend to no longer maintain the RSK deployment of the contracts and interface, then we could put a modal on the Sovryn dapp that basically “forces” users to either withdraw from Sovryn or manually migrate their funds to the rollup – but not interact with the current contracts otherwise.

If we intend to maintain both the RSK and the rollup for some time then we can put a “migrate” button somewhere prominent in the app (maybe up next to the account module) and users can always migrate whenever they want. And users can switch back and forth between the chains using a network dropdown module (RSK Mainnet/RSK Testnet/Rollup Mainnet/Rollup Testnet).

5 Likes

You raise two separate issues, which I will address separately.

1. Should the Bitocracy even have the power to move user funds?
I will answer is a qualified yes. Part of the reason is, I am not sure it is even possible to construct the protocol as upgradable, without having the ability to migrate funds. It is possible to deploy upgrades and then hope the liquidity moves, and this sounds like a theoretically ideal mechanism. However, the practical implications would require the users to move from where there is liquidity, to where there is not. This introduces a collective action problem, which is exactly what having a Bitocracy is designed to overcome. In other words, without this ability, the protocol becomes un-upgradable. Every “upgrade” would basically be a competing system.
Ok, so why not just shut down the old system, as you suggest. I think this is strictly worse. If we are working to build an uncensorable system, we should not have the ability to shut it down.
So, how can we make the system uncensorable if we can move funds?
think the answer is that when we have a proposal that would move funds, we allow ample time for users to withdraw their funds AND the ability to refuse to have their funds moved.
Fine, but this still puts a huge amount of power in the hands of the Bitocracy! Yes, indeed it does - and that should be written on the tin, which is why we are discussing it. It should require very high consensus. Currently that would be at least 70% of the vote and it should always be opt out - currently there is a minimum of 3 days to opt out - but this should be expanded in the future.

2. Should we have users migrate to the rollup without this mechanism?
I’m not sure. My sense is that the protocol is young, the planned migration is being signalled early and the migration would be easiest for users if it was a programmatic migration. That said, if there is a good may to migrate users (ie. by shutting down the main UI) then maybe we can try it first and discover that we don’t need upgradable contracts after all.
However, I am concerned that this might create a danger of making the current UI too important. So its a complicated matter.

So I am glad we are having this debate.

Yes Uniswap had to go through the same thing with the update from v1 to v2. Here’s how it went:

v1:

v2:

Screenshot_2021-02-22 Uniswap Info

The collective action problem was I think primarily resolved by incentives (many tokens listed on Uniswap, including Uniswap themselves via UNI, either launched liquidity mining programs on or migrated their liquidity mining programs to v2, and liquidity followed) though I think the much-anticipated improvements of the v2 contracts attracted liquidity early on as well.

To clarify, I didn’t suggest shutting the old system (let’s call it v1) down. I suggested not supporting v1 in the interface any longer (this is the “hard migration”) – users would of course always have the ability to self-host or run locally an old version of the interface that supports v1, or to interact with those contracts directly via CLI. I also suggested what I’ll call a “soft migration”, where both v1 and v2 are supported in the interface, and v1 users are merely presented with an alluring “migrate to v2” button in the corner of the screen until they finally do the migration. I’m personally fine with either option, as long as users have a long enough time to prepare leading up to the “hard migration”.

Even if the execution delay is extended - and yes, in any case I agree it should be - I think the protocol should evolve in the direction of governance minimization. Switching off upgradeability should be one of those steps imo.

Can you unpack that? Too important in what way, or compared to what?

1 Like

I think using liquidity mining incentives and UI support to encourage migration is growing on me. Good arguments.

1 Like

I’m mostly just here to learn. But some comments from my experience are that I still have some ERC-20 TRX. Not enough to manually migrate, so I’ll have to transfer to binance in order to convert them. Let’s remember that a lot of crypto users are cyclical with the bull market. So some SOV users may get their tokens and then the market could tank and people stop paying attention for a while… like years sometimes. It’s not really SOV’s responsibility to babysit these dormant users, but it is an important gesture IMO to allow migration to occur indefinitely in the UI. Prominent V1 to V2 token migration button in the UI seems like a good idea for a year or two. Then it can be tucked away in a menu later on after most have migrated.

I also agree with @light 's thinking regarding removing capability for the Bitocracy to move user funds. Especially because of SOV’s value proposition of sovereignty. Every effort should be made to limit the power of the bitocracy over the individual token holder. The bitocracy has the potential to become a monster of its own, similar to centralized governments, we must be clear to limit powers in favor of the individual rights. Perhaps we need to develop SOVRYN “Bill of Bitcoin Rights”. That would be a cool marketing approach and it could provide value to the whole blockchain community to enshrine the values that have already garnered so much attention and investment in SOV. There are a lot of concessions in decentralization being made right now, even by pretty devoted decentralists, so it could be an opportune moment to remind everyone why Edan got into blockchain in the first place. Seeing the use cases for permissionless, autonomous, borderless store and transfer of value are the impetus for financial sovereignty.

Cryptocurrency Bill of Rights:

  1. Freedom of transaction. Transacting value is a form of speech that must be protected. The right to own one’s private keys and transact across decentralized networks in permissionless environment shall not be infringed. This includes the right to approve or deny any transaction or smart contract in which users’ cryptocurrency is spent.

Even just trying to clearly articulate the values in the few sentences above, I can see huge problems with this language. But I think it’s a worthy pursuit to have a community driven articulation of blockchain values. Many perspectives will facilitate crafting language intentionally. We could revisit the Satoshi white paper for inspiration.

How do you feel about SOV staking rewards vs SOV liquidity pool incentives vs SOV liquidity mining incentives? What should their relative reward values be? What factors will determine the rewards? Initially it seems most important to highly incentivize a few different LP pairs. But I also think an attractive BTC stake pool and also a SOV stake pool will be most highly coveted. That’s what I want to use personally. I’m down to stake some liquidity but I’m also pretty burnt out on “impermanent loss” so LP rewards have to be pretty high to motivate me. But give me an option to stake BTC or SOV with no concern for automated market makers or impermanent loss… and I’m very interested!

Can app.sovryn. generate BTC-SOV and/or rBTC-SOV and/or wBTC-SOV and/or ETH-SOV liquidity pool that only requires deposit in one currency? Seems like it would be possible to have AMM liquidity pair pools that are limited by the size of separate individual pools. It seems like that’s what the app is doing already. I just went looking through the gitbook and this part really caught my attention:

Liquidity providers will be able to earn from trading fees as well as earn yield from Sovryn’s future liquidity mining program. Unlike other AMMs that only accept a 50/50 ratio among a pair of cryptocurrencies, you would only need to deposit one in order to start earning swap fees. The fees will start at 0.1% per swap per coin for liquidity providers.

Lending - Sovryn

Blockquote Can app.sovryn. generate BTC-SOV and/or rBTC-SOV and/or wBTC-SOV and/or ETH-SOV liquidity pool that only requires deposit in one currency?

Already exists - that’s how our AMM works. :slight_smile:

There is also a lending pool, so we got u covered Sovryn.

2 Likes

Nice! Yeah, this is exciting. Is SOV first to market doing this?