Migration Committee Community Update 3 (4 parts)

photo_2019-11-02-08.15.57-1

Migration Committee Community Update #3 (Revised Recommendation)

Public Communication: Catapult Migration (3) - Revised Recommendation

This is a joint message for our community on behalf of the Catapult Migration Group, comprised of the NEM Foundation, NEM Studios, NEM Ventures and Tech Bureau Holdings.

Translations:

Japanese: Forthcoming
Spanish: Forthcoming
Mandarin: Forthcoming
Italian: Forthcoming
Russian: Forthcoming

A Frequently Asked Question post also exists for reference: Catapult Migration Frequently Asked Questions (FAQ)

Context

The Migration Committee Community Update 1 was released on 15th Sept following assessment of a variety of options available for the upcoming launch of Catapult and inclusion of existing XEM holders and NIS1 data.

Following that announcement, a lot of community discussion ensued with a variety of constructive input and ideas. One of these was a desire for Super Node holders to be able to express opinions and have discussions in arena that protected anonymity while allowing free and frank discussion to occur. In response to this an Open Letter to Supernode Holders was issued. A group of approx 50 long standing, significantly invested community members joined the discussion over the past 3-4 weeks (and tens of thousands of TG messages!). The net outcome of this approach a refinement of the initial proposal from the migration team. Which is not yet a decision, it is still a recommendation and is being shared here to capture further feedback.

The updated recommendations can be found below:

Screen-Shot-2019-11-02-at-9.26.28-PM
Notes

  • Recommend against Token Burn on NIS1 and against full snapshot with no ability to refuse tokens
  • SuperNode group general preference is to receive tokens with no action but be able to Opt Out; but there is still discussion ongoing on this and strong opinions exist on both sides, please make your voices heard if you have a preference here

There are a few subjects that need further discussion and are noted later in the post, I will create a seperate post for each so discussions can happen on topic (please wait for those posts before replying, I will link them here). These primarily need input from a wider cross section of the community before being finalised.

Summary of the Recommended Approach

Catapult be launched as a fresh network and chain, with a subset of data from NIS1 being migrated into it at Nemesis/Genesis block.

The data to be included will be NIS1 token balances on a 1 for 1 basis, Multi Signature Account configuration and Root Namespaces.

There will be facility for NIS1 token holders to be included in the Token Allocation at Block 0 of Catapult, or not to be included at that point and to be included at a given point in the future (with the same number of tokens as if they were included in Block 0…not more, not less) within a predetermined time frame (years).

This approach necessitates that Catapult and NIS1 run in parallel, which also allows projects to choose to point at which they wish to migrate onto the new chain.

A cross ecosystem support plan will be put in place as part of the migration work to ensure NIS1 stability is maintained as a result, where possible this will be underpinned by the Tokenomics model.

The running of two chains, implies two tokens, one for NIS1 and one for Catapult. These will be named differently and branding work is ongoing to inform this decision.

Outstanding Discussions/Points to Note

The following points had broad consensus in the Super Node group but still require further discussion or solutions to be found so are highlighted here. Each of these will have a separate the forum topic created to try and segment the discussion

Opt Out vs Opt In
Multi Signature Account Configuration
Post Launch Opt In Process

Jaguar has summarised this graphically in a Tweet as well: here

In addition, there is a broader subject of Tokenomics (for both NIS1 and Catapult) and the Branding work, these will be covered in future updates, for now we are trying to keep focus on the migration mechanisms required to move over to Catapult

// See original post here


Migration Committee Community Update #3.1 - Opt Out vs Opt In

Public Communication: Catapult Migration (3.1) - Opt In or Opt Out

This is a joint message for our community on behalf of the Catapult Migration Group, comprised of the NEM Foundation, NEM Studios, NEM Ventures and Tech Bureau Holdings

It is a follow up discussion point from Migration Committee Community Update #3 (Revised Recommendation)

Translations :

Japanese: Forthcoming
Spanish: Forthcoming
Mandarin: Forthcoming
Italian: Forthcoming
Russian: Forthcoming

Opt Out vs Opt In

The subject of this thread is to try and flush out more discussion around the pros, cons and preferences of the community about whether we prefer an Opt In or Opt Out approach. There is a brief definition provided below for those who don’t have any context on this and several links at the end of the article.

The original recommendation was to utilise a Token Allocation approach, which NIS1 token holders would Opt In to. The feedback from the Super Node group and community generally appears to support that approach but to allow holders to Opt Out from being included instead of having to Opt In, there is a subtle difference:

  • Opt In - NIS1 token holders make an active interaction to signal they want to receive tokens on Catapult, either before or after Catapult launch.

  • Opt Out - All NIS1 token holders are allocated tokens on Catapult UNLESS, they actively Opt-Out, if they do decide to Opt Out, they can still claim their tokens later via an Opt In.

The two options are both variations of a Two Chain, Token Allocation approach, so it is positive that we have narrowed the generally supported recommendation to a single approach - we are discussing details at this stagen to large concepts. Both options are envisaged to be delivered via a NEM Wallet (Nano Wallet) plug-in that generates transactions to known addresses with a specific message, they can therefore be sent by other wallets or programmatically, as subsequent post will be made to show how this could work.

The exact Post Launch Opt In period duration is yet to be defined, but is expected to be several years, at the end of that period they will most likely be burned. This aspect is the subject of a seperate discussion so will have its own follow up thread posted shortly after this one (insert link when posted)

Further input from the community, (particularly the Japanese & Russian speaking communities but others as well) is sought prior to solidifying this option. To date input has been primarily from the English speaking community and this of the 3 sections to highlight is likely to be the more contentious and impacting for holders.

Some strong concerns have been raised by some parties against both Opt In and Opt Out; questions have been raised in the forum as well. I will leave it to the community for a few days to state these to avoid influencing discussion in the original post, if its not forthcoming I will look to add it in a follow up post.

One item that cannot be avoided is that if Opt Out is taken, then a decision must be made on how long the period to be able to Opt Out should/must be between announcing it and the block height at which we take the balances snapshot.

Useful information when considering this topic:

// See original post here


Migration Committee Community Update #3.2 - Post Launch Opt In

Public Communication: Catapult Migration (3.2) - Post Launch Opt In Process

This is a joint message for our community on behalf of the Catapult Migration Group, comprised of the NEM Foundation, NEM Studios, NEM Ventures and Tech Bureau Holdings

It is a follow up discussion point from Migration Committee Community Update #3 (Revised Recommendation)

Translations:

Japanese: Forthcoming
Spanish: Forthcoming
Mandarin: Forthcoming
Italian: Forthcoming
Russian: Forthcoming

Post Launch Opt In Process

This topic is specifically focused on how we manage any NIS1 token holders that for whatever reason to not take up their allocation of Catapult tokens on day 1 but decide to delay it to post launch. This could be for any reason and we are not interested in debating the details of why, we have had sufficient feedback that it is need to validate it as a requirement. The discussion is more on the HOW.

Under either the Opt In or Opt Out approach discussed further in this topic. There will be a proportion of tokens that are created in the Catapult initiation, but cannot be allocated to the token holder that is entitle to claim them. So what should happen to them?

The original recommendation by the Migration Committee was to place all unclaimed tokens under the control of a Special Purpose Vehicle (SPV) - a legal entity that is responsible for managing the tokens until the end of the claim period (length to be decided, likely 5-6 years at least) and then burn them at the end of the period. The process could be manual or automated but there would be a single legal owner of them until claimed or burned. The SPV would have fully transparent trust deeds/articles/by-laws and a known management team, it would be legally liable for managing the funds in accordance with the decision and the rules governing the organisation.

The feedback from the SuperNode Holders group was that the use of an SPV is not preferred and either a solution similar to the NIS1 SuperNode monitor or a process managed by supernode holders is preferred, however the voting was not definitive and further input from the community would be beneficial.

Further analysis needs to be conducted in relation to:

The technical options for extending the supernode monitor solution to ensure it is actually viable

Legal analysis to ascertain if any/all/some of the supernode holders would be incurring legal liability if they were to be managing the unclaimed tokens and if so, that those involved accept that liability in a transparent manner.

Similarly the legal position of someone changing the Supernode monitor and hosting it to perform this role.

A move to Opt Out (from Opt In) does provide an opportunity to include acceptance of whichever solution is used for for the Post Launch Opt In process as part of the Ux, effectively signing into a contract for their tokens being managed by the agreed process.

The previous Opt In approach would assign all unclaimed coins by default to be managed post launch, with no interaction from the holders. Opt Out explicitly requires interaction and therefore explicit decision/permission.

This may change some people’s philosophical position to how the unclaimed tokens are best managed, or it may not. It is important that whichever group undertakes the management of the unclaimed tokens on behalf of the ecosystem is fully aware and accepting of the legal liability that may come from doing so in the event of any issues.

We are interested in all ideas, comments, questions etc on this topic as it is one very much that the community needs to be ok with and there are pros/cons to all options.

// See original post here


Migration Committee Community Update #3.3 - Multi Signature Accounts

Public Communication: Catapult Migration (3.3) - Multi Signature Account Configuration

This is a joint message for our community on behalf of the Catapult Migration Group, comprised of the NEM Foundation, NEM Studios, NEM Ventures and Tech Bureau Holdings

It is a follow up discussion point from Migration Committee Community Update #3 (Revised Recommendation)

Translations:

Japanese: Forthcoming
Spanish: Forthcoming
Mandarin: Forthcoming
Italian: Forthcoming
Russian: Forthcoming

Multi Signature Account Configuration Migration

The original recommendation from the Migration Committee was to require all accounts (Single and Multi Sig) to actively opt-in. This offered an opportunity to have Multi Signature accounts perform a couple of actions which meant the data on Catapult would be verifiable on chain.

With a possible move towards an Opt-Out process, there is an option to include or exclude Multi Signature accounts by default, or require them to Opt In actively.

The SuperNode Holder group voted in favour of including Multi Sig configurations without an opt in process but subsequent discussions mean it is necessary to garner further input from the community on this before deciding. It is technically possible but generates some philosophical questions that are worth discussing.

The net effect of that decision would be that the Multi Sig configuration data on Catapult would not be verifiable and a workaround would be required for a new feature on Catapult that requires Cosigners to accept being added to a new Multi Sig account; essentially back filling the migrated data from NIS1 with “dummy” data or an unsigned transaction to add the cosigner. For some people that is a problem, for some people it is not, there is no right answer on this one, it is personal preference, hence the call for input.

This raises two challenges:

  1. During discussion the Core Developers said that on a surface assessment, a workaround would be possible, this would need to be tested/validated in detail but we believe enough has been done to make it very likely this would work without problems at a technical level.

  2. There is a philosophical aspect to having seed data on Catapult be non-verifiable, strong opinions are held on both sides of this issue and there appears to be general acceptance that Opt In for Multi Sig accounts given the numbers involved is likely to be acceptable to most people.

The alternative is to adopt a hybrid approach is we use Opt Out for non multi signature accounts, and use Opt In for Multi Signature accounts.

It is worth noting that Multi Sig accounts represent approx 10% of all tokens, most of those are known accounts and likely to be engaged enough to opt in, we do not believe there would many if any accounts that would not Opt In and if they do, they would still be able to claim post launch.

There will be a separate post coming soon with a suggested way of achieving (link here when posted) this in NEM Wallet ( Nano Wallet) as a plugin but it would be possible to mimic all these transactions via another wallet or programatically and the technology for doing so can be release, an Alpha tool was created to validate this is possible.

// See original post here

© NEM.io Foundation Ltd (Singapore) 2014 - 2018 | All Rights Reserved | NEM ™