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: Link.
  • Spanish: Forthcoming
  • Mandarin: Forthcoming
  • Italian: Link.
  • Russian: Link.

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


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/tickers 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 Rate 1 NIS1 : 1 Catapult
Type of Launch Token Allocation (Opt Out or Opt In) keep XEM and receive same amount Catapult Tokens (see notes below)


  • 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: https://twitter.com/Jaguar0625/status/1189735316497879040

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


thx a lot for update!
i think we have a much better view now what we can expect just little details are missing

and the block naming and branding and cointicker of catapult chain
but afaik this will follow soon


I do not understand where to store nem coins in order to get catapult coins.
If coins are stored on the binance and yobit exchanges, how will the catapult coins be credited.
I did not find the answers to these questions.

The most secure way for normal user is to store your XEM on NanoWallet, which you can download from nem.io
Binance maybe give you CAT tokens too, but is ia without warranty. So, if you want to be for 100% sure that you will receive CAT tokens, please send your XEMs from exchanges to your NanoWallet.


It’s about time we agreed on a schedule. No matter which decision is made, the time to introduce Catapult in Q1/2020 is running out.


Yes. Would like to iterate that coins stored on exchanges are the responsibility of exchanges and it will be up to these exchanges to make the decision.

I would recommend not storing XEM in exchanges especially during the migration process and to have the private keys to your tokens.

Agree on this. I am looking forward to the tokenomics and branding aspect especially. I think the Recommended Approach is a positive step forward and it looks like there is also interest in the Opt Out version more. Looking forward to the next update.

Would like to see more details on this if possible as well.

I just watched @lewisfarrell 's Video at https://www.youtube.com/watch?v=_LShCAb4_9I
Good job, nicely explained!

I have a question.
That Opt-out means that you “won’t get the tokens” but retain the right to “claim them once you’re ready” in the future. To my best knowledge the main argument in favor of “Opt-Out” was taxation applicable to Airdrops.
Wouldn’t an approach where you DO HAVE access to, but don’t activate (claim) your tokens render the profit-mitigation (tax-mitigation) argument invalid?
Because tokens (only) you have access to, direct or indirect, are yours and yours only. To opt-out of the profit, you would need to opt-out -without- keeping a backdoor for “withdrawing later”. Or am I on the wrong track here.
So, in conclusion, I’d say that an Opt-Out solution can’t be argued for as a tax-mitigation effort.
Correct me if I’m wrong! I might overlook something.
Or in case I’m stating the obvious - sorry for wasting your time :slight_smile: