Category: NEM (XEM)

Migration Committee Community Update #3 – Revised Recommendation

Public Communication: Catapult Migration (3) – Revised Recommendation

Migration Committee Community Update #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:

Decision	 Recommendation      Comment
Networks/Chains  Two             Some people would prefer a technical upgrade and 
                                 one chain, but accept that is not possible.
Token names/tickets  Two         Exact names yet to be confirmed, there is
some preference for Catapult retaining the XEM ticker
Data to migrate	  See comment	 XEM Balances, Multi-Sig
                                config, Root Namespace
Token Supply	  Unchanged	 9bn NIS1, 9bn Catapult
Token Allocation  1NIS1 : 1Catapult
Rate		
Type of Launch	  Token Allocation keep XEM and
                  (Opt Out or      receive same amount
                  Opt In)          Catapult Tokens (see
                                   notes below)

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

This article was originally published on: The NEM Blog on