Catapult (v2) Update + Community Feedback

Hi NEM community! :wave:

The planning and launch of the v2 Catapult-based network has been a focal point of the Migration Steering Committee (which includes key leaders and members from NEM Foundation, NEM Studios, NEM Ventures, Tech Bureau, and core developers.)

Since then, there’s been a lot of hard work and conversations happening behind the scenes and the core devs have been helpful to nudge the Catapult Migration team to share these outcomes.

Like Jaguar0625 is indicating in his tweet, changing the vantage point and getting some different and objective points of view on some decisions coming from outside the migration team is a good thing and we want this… I know I do.

As the v2 launch testing is progressing, let’s use this space in the forums to share migration progress and feedback. Updates will be forthcoming. :eyes:

In the scheme of things, when we look back 5 years from now, nobody wants this time period to be regrettable because folks were speculating and fretting about “when Catapult” … If we take a step back and look at the perspective of the time and expertise that has gone into Catapult development, this window around Q4 2019 will look pretty small but the outcome of the launch has the potential to be substantial.

The migration committee’s goal is to provide a path forward for a successful launch of v2 network, and preserve the values and interests of the NEM community.

So thanks for your patience and support.


Hi Alex, I’d appreciate it if you could tell us when there will be an update regarding the migration process of XEM tokens. I think many hodlers and investors would like to know. Also I think if somehow NEM ends up with two chains and value dillutes I think trust in NEM may never recover. So right now I think this should be priority and the rest of migration processes ought to be considered of secondary importance I think.

1 Like

As a first thank you for this post. However, I would like to have more information on the arguments from which the best transition from one chain to another is made, just like Sky …
And not on Slack but here in the forum. Even if unloved arguments appear. You have to endure it and put it down again. But at least that’s how you take people with you.

You should now have noticed that the community is not as big as it used to be. And even Tech bureau has meanwhile transferred a large part of the ICO funds (comsa) to zaif.


For sure - this is one of the first aspects the migration committee will most likely address. I expect community will hear more on this fairly soon. Keep in mind that in a situation like this, there’s just not a perfect solution.

For me personally (and not speaking on behalf of the migration group), I’ll share that my preference leans toward staying true to the integrity of a brand promise and I’ve seen many brands transform from their low points and rebrand to become powerhouses (ex. Apple and Lego are two classic case studies on this.)

I really like the idea of Token Swaps (any accounts that opt-in, their balance of XEM on NIS1 at a given date/block height is removed and they are given an equal one on Catapult.) I think this solution keeps true to the brand promise of NEM. I also think it’s a legal pain. :grimacing:

I’m curious to see community’s views on this too. (This is where migration committee can shed more light in the near future.)

To Garm’s point above, the industry and NEM community is very different now than it was in 2014 when the project began. (That can be said of most projects in this space.) There is just overwhelming noise, competition, and hype. Adoption comes in part from building practical business applications. Catapult brings forth new opportunities and features to do just that. It’s worth recognizing that this "community project’ has the opportunity with Catapult to become a full-featured enterprise solution.

I would like to see this happen and am respectful of the teams and processes that are working in the background to get us to this place. My view is colored by the fact that Foundation has dramatically transformed/reorganized in less than a year. In fact, Foundation didn’t just go through a “reorganization”. It was a reformation (to make something better, correct/amend.) I’m looking forward to us (and Catapult) evolving.

Thanks for your patience.


For clarification, core devs are in communication with the Migration Steering Committee but we are not members of it (by choice).


Couldn’t agree more. Too much has been happening behind closed doors. It’s time to let the sunlight in.

We need to reinvigorate the community. Catapult is really one (last) chance at rebirth.


Thanks for the clarification Alex. I think for Nembers two things are important regarding the migration process;

  1. XEM will retain its value and its value will not be dilluted by having two chains operating at the same time
  2. Migration will not have tax consequences for XEM hodlers.

You mentioned an opt-in process, i think this is the most reasonable solution, that way XEM will retain its value, and migration should not have tax consequences as the same token just migrates to another chain. Also the process seems fairly easy to execute. However you think it could be a legal pain? Is that in regards to NEM foundation/NEM elements, or regarding investors? thanks a lot for being responsive in this time of need :).


as someone who design coin economics and blockchain feature sets since 6 years and study very careful what others did do and take into account lessons learned from multiple codebase changes and coinswaps of projects im involved i can give 3 prefered paths:

path one the easy one:

need support of exchanges explorers coinmarketcap platforms

a snapshot at date xy 1 day pre snmapshot all exchanges disable deposit and withdraws 2 weeks later the exchanges enable deposit and withdraws again meanwhile new chain started and all exchanges converted . all addresses with balances on old chain snapshot date get transfered the same ammount at new blockchain start transfered (its not opt-in everyone gets it) all exchanges and explorers all coinmarketcap trackers replace old XEM with new XEM. even if technical two chains exist an old abandoned one and a new one in reallity only one chain with coins stay existing since u use same coin name and all important 3rd party support the swap.

easy to do
done well it avoids a 2 chain 2 coins szenario because zombie chain dies a risc of an XEMclassic chain is low as NIS closed source noone can maintain it without open source
from legal point of view u can see it as no event as the same coin name is used and the same private key owns it and by all supported 3rd party exchange the new one replace the old one. it can be seen as a mandatory network upgrade with keeping balance but removing history. same as in all mandatory wallet upgrades the non upgrades nodes and their coin balances are seen as invalid. a valid fork coin only start to exist if there is a dev team supporting non upgraded nodes and they give themself a new coinname in that case they are the NEW coins with new name and any legal questions regarding tax relevant event is targeted at them
mossaics and namespace could i hope be migrated towards new ruleset

coins migrated but services transactions any history is not.
a possibility that a 2 chains 2 coins szenario can happen is not total out ofg scope even if unlikely if done well
its way weaker solution then make a mandatory node upgrade and still keep history events of old blockchain
all services that did write data on chain lose old data access but they have a history available in old blockchain copies so there would be ways to read and migrate must have events data
possible issues with multisig u need to transfer migrate multisig relevant data (whats keys can sign for what)

path two the dream szenario:

here u make a mandatory wallet upgrade that is able understand NIS created blocks and messages and catapult created blocks and at trigger block xy catapult type blocks and rulesets are active still NIS created blocks can be read so u have full access to history.

no question at all about 2 chains risc because no new chain is started
no question regarding tax relevant events because no new coins or ownership change happend
no question regarding transaction history or by services created assets and blockchainentries as all history is readable no data lost

additional dev work needed to teach new client for few days create old blocks and forever read old blocks
even if history is readable services and apps need to adapt their software to use the new catapult comands and api

path three the interesting 2 chains one coin path:

u could start catapult chain without coins and have an bridge that allow transactions between NIS and catapult chain . have a look on xDAI blockchain which did follow that idea they started without a native coin and all of the native currency is created by transfer DAI over a bridge from ethereum. as i think cross chain transactions is a part of catapult skillset this should be in reach only need to teach old NIS to do that too. u could make it one way only or even bidirectional. in any case a XEM is a XEM no matter if he runs on NIS or catapult chain because all together on both chains we have the coinlimmit of 9 billion.

no tax relevant events just transactions
no instant shutdown of NIS based chain all services and apps stay working
free choice for projects when to migrate
free choice of exchanges what chain they have listed because currency is same worst case user need to move his coin towards the chain exchange supports (still ideal most exchanges move to new chain but like one stay supporting direct deposit from old one)

contra: old chain will lose importance more and more and after some time u spend energy to keep it alive even if noone really use it any longer


I think the best way to do it - to have 2 separate chains. I’m talking about making a snapshot and giving for free coins from a second chain for users who have them in a first chain. It will only increase the value of all tokens which each user has. And I really don’t like an idea to swap coins.


I can’t see cleary what is problem for catapult migration. You can do a community vote by summarizing the main points and issues, merit and demerit about migration pattern.


I’m on @garm side. It would be nice to know about the arguments made by the committee on each of the options before we see people flooding this thread with their ideas of what the best option(s) should be.


I dont mind the opt in option either.
Im still happy with 2 seperate chains though. I dont think two chains will water down value, if anything, it could give holders more value as you will have two chains available.
Making it open source lets community manage it if they wish and someone may find ways to use it as a cross chain platform with catapult anyway.
Just remember that dogecoin still is alive with no active devs.
It can sit there and do its own thing, but will still have some amount of value.
The way with opting in is that it avoids any tax implications as you just opt in when ready and you will only be liable for tax when your tokens arrive to your account on the new chain.
This way you can decide when to recieve the tokens depending on the market price at the time and choose when you want to opt in, rather than having a tax burden upon you on launch day.


The new chain (Catapult) needs to take over the past NIS1 transaction history. It is important thing. It is not wise to start over from block 1.


It’s encouraging to see the feedback on this thread. :+1: If you see discussion in Telegram or Twitter, please send community here so as the Migration Committee posts updates, more meaningful discussions can be had.


Looking forward to what has been discussed and who provided which input so far. (Unfortunately, I have no access anymore to migration discussions from NEM EU around this time last year.)

Here are my first thoughts from top of my head:

Obviously Catapult was communicated as V.2 of NEM for a few years and is already priced in in the xem price. So, it should be a goal for investors to maintain their value.

I’d like to see a snapshot at a certain height (+ all of the history on version 2). I hope you inform exchanges (as described above: no trading for xyz days) when to add support for the second chain - and tell them the second chain will be priority. (Exchanges can then easily support XEM_new and XEM_classic)

Since there are a few applications running on NIS1, and the chain has been running for years while Catapult will be at a more infant stage - it makes sense for NF to officially support both for some time and have them run in parallel + provide guides for developers to make the switch.


In Japan, many people are concerned about taxes.

If we get a new XEM using the 2chain-snap-shot method. By that, if we are regarded as income at the market price when we get new XEM and we need to pay taxes, that’s exactly hell.

Japan has the second most super node in the world. They may quit node operations and sell XEM for tax payment.

That is really the worst. The predecessor profit is lost. Especially the efforts of the old NEMber are lost. This problem must be avoided absolutely.

We have great expectations for Catapult. But many people should not suffer from taxes because of Catapult. And there is no need to hurt part of our lives.

The NEM Foundation said Japan is one of the important markets, does the migration committee include Japanese legal or taxation experts or something? I don’t think so. So I’m more worried.


I stayed quiet for a long time, but I feel that I should give some input to the migration topic.

I would raise the question, why do we have this discussion at all?

From my understanding there are two main reasons:
(1) NIS APIs are not compatible with Catapult
(2) NIS database / data format and data structure is not compatible with Catapult

From my understanding, if those both points can be solved, a way forward is obvious and there won’t be a discussion like this.
I don’t have enough insides to propose solutions, but I would like to share my opinion and raise some questions.
Both points from above make it hard to go forward in a single event, as existing solutions must be adjusted and data from the current chain is required for them to work as expected.

Regarding (1): Would it be possible to create some kind of “Data Translator” that supports (most of the common) NIS API calls and translates this to Catapult requests?
If this it is possible to support the most common NIS API calls it would offer a way forward for most of the existing solutions out there without the need of an immediate adjustment.
The “Data Translator” would be placed in the middle of the existing solution and the Catapult chain.

Regarding (2): History must be migrated - at all cost. The current chain is NEM, it’s blocks are all that matters, if you start with a new chain without keeping history it is just a new coin - it’s not NEM anymore.
NEM is THE platform for timestamping and proof of origin, this is imo. the main attribute that gives value to NEM at the current time and that makes it stand out. If you lose history with (sorry devs) “just an update” you go against the fundamentals of blockchain.

If we start new, with just make asset/coin swaps possible or airdrop balances to a new chain - it’s just a new coin, it is not NEM and it should get a completely different name.
Realistically, no one will be able to keep NIS alive in the long run imo., tech is outdated and it will fade away.
If I would be a business having all my secured history in NEM (and this is the only fundamental reason having a blockchain at all) and it is not taken over during an update - this would be the time for me to move the business to a different platform as the main purpose is lost at this point.
I would also lose all confidence as future updates are likely to discard history again - this makes blockchain useless.
From my understanding a data migration can be an archived (even if it takes longer) and there should be no discussion about this – keeping history is a must - otherwise you end up with a new coin (with no trust) and NEM as we know it is dead.

If you look at the current situation - there is huge competition out there, Catapult is really great tech but there is only one try to get the attention it deserves. Kept history will bring trust to the platform, a new coin is just good for speculators, but it will destroy all value NEM has built up over time as a blockchain solution.

Just my 5 XEMs.

Have a good day.


Definitely share your sentiment here. Japanese Nembers are the most loyal of all, perhaps without them NEM would not even be (anymore). Therefore this XEM migration thing ought to be the highest priority, even more important than “Catapult when?”. How would an opt-in solution be considered in Japan from a tax point of view? I think it’s an absolute must for Foundation to make sure there are no tax implications for Japanese Nembers. Shouldn’t be too hard to figure this out with Japanese tax experts.


it’s sad actually. This should be the time to look forward to the biggest release of NEM and looking forward to making blockchain history. Instead of that investors worry whether their token will retain value and whether they will end up with fiscal issues. This could and should have been avoided beforehand by announcing whatever happens with the migration NEM will retain its value and there will be no tax implications. I think now is the time for NEM Foundation to show they really care about the community and fix this issue ASAP. Might be the last opportunity to retain faith and loyalty from the community, there ought to be reciprocity in this regard…


I am Hokkaido from Japan. Thank you, Alex, for giving us a chance to say something about migration. Recently, I put my personal idea for migration using cross-chain-swapping between NIS1 and Catapult.

I am sorry for this article written in Japanese with a picture explaining my idea in English. But, basic idea is we can keep 2 chains as long as we can keep NIS1 alive. The people send their NIS1-xems to an exchanger (I thought we need use exchangers to send and receive crypto currencies), and exchanger will send them (or someone who keeps all the Catapult-xems). will swap the NIS-xems to Catapult-xems and send them back to exchangers. Then, exchanger send the same amount of Catapult-xems to people. All of these transactions can be made altogether, if we use cross-chain-swap function.