NEM Foundation Catapult Roadmap and Vision

NEM Foundation Catapult Roadmap and Vision

Japanese - here
Mandarin - here
Spanish - here
Russian - here
Italian - here

Access to downloadable document of NEM Foundation Catapult Roadmap and Vision: here

Access to downloadable document of NEM Foundation Catapult Roadmap and Vision: here

For media enquiries, contact [email protected].


so there isn’t any release on 2019Q2 for catapult :confused:

Congratulations and thank you all at NEM Foundation and the developers for the hard work. And thank you, the community, for all the supports. What a birthday gift. :slightly_smiling_face:


i have a question,
Can Catapult support atleast 10000 tx/s on 2019Q4 ?

Thank you! Bright future ahead!

1 Like

As you can see in the above graphic, Catapult testnet is realsed Q2. The link is actually there for the testnet if you like to experiment and build!

1 Like


would like to hear more on the new POS consensus algorithm that preserves important features of POI.

  1. Would delegated harvesting works the same?
  2. Plan for supernode

Still missing one of the most important questions: how will we switch from nis1 to nis2?


Hi there, from the Foundation side, since these features are not finished yet, we can only answer in generalities. However:

  1. See @jabo38 reply below.

  2. Supernodes may look different but that configuration is not up to the NEM Foundation. We hope to include more technical aspects when they are made available from the Core.

Hope that helps, keep the Q’s coming!

There will be full migration support and documentation made as well as how-to videos and a dedicated channel to assist projects moving over from NIS1 to Catapult. In the interim, do try out the testnet and see how it works.


Yes, it will work the same but there will be even more options.

The following is a conversation on Github.

Nate: This feature is to track the implementation of new harvesting capabilities to be added. The goal is to allow for deployed networks to create a nice incentive structure for supporters of the network to run full nodes and having the ability to get compensated for doing so.

BR: A node owner that is letting other accounts harvest is getting a certain percentage of the fees that are harvested.

The percentage is the same for all nodes in the network and can be found in The name is “harvestBeneficiaryPercentage”. The node owner can specify the account that is credited (file, field “beneficiary”).


to be honest that roadmap looks more like a start of development thing where we all where expecting a close to release thing…

i think have a very small core dev team boomerang us now with way slower release cycles then other big chains thats why we move out of top 20 because we develop like top 100 and not a top 10 coin in terms of development progress and team resources.

so im here with mixed feelings the stuff u plan to do sounds good just we where expecting it to be released soon and not end 2019 a first version with many things coming not before 2020.

jump on lightning 2020 might be only a cool thing if u mean cross blockchain lightning with hybrid nodes that run BTC and XEM and maybe other coins that taking part in an cross chain lightning network

POS+ and new supernode ruleset will also be a make it or break it point because 400x 3 million coins is a big part of total coins by fuck up supernodes in future ecosystem u would enourmous destabilize XEM

but lot things can not be judged by just read a one sentence about it and not get access to deeper details

the details can make this way better and more promising in best case (or worse in bad case…)

Why is Golang not considered one of the core SDK’s?


Please tell me more about this.

“Stable Coin - A price-stabilized token on the blockchain”

What does this mean?

1.NEM Foundation will issue Stable Coin with NEM
2.NEM Foundation will support to operate who want to issue Stable Coin
3.NEM will add Stable Coin issue function


It is nice to have Golang and it is definitely being considered for the next round of SDKs. The reason why not all SDKs are being built at the same time is to make sure best practices are set in one, then a few, and then the rest of SDKs to follow so that all will have a clear structure and methodology that that compliments all the other SDKs. By doing this it makes working across different SDKs easier for many different parts of the ecosystem including the SDK devs, documentors, and devs building on the SDKs. Where as in NIS1 we had 10 different SDKs (often times a few for the same language) and each one did things differently.

I assure you the devs have built tech into Catapult that none of the top 10 and definitely none of the top 100 chains have produced.

I understand your frustration that development has gone slow, we all wanted Catapult out in 2018 not 2019 but all things considered when I look under the hood and compare Catapult to any other top 10 coin, I’m quite proud of what the core devs have done.

For instance, even if Ethereum gets to POS which we already have, they will still have the Infura problem and nobody is even talking about that because they are so focused on POS as they need that to scale, and yet NEM devs have already solved the Infura problem in Catapult. And this is before Ethereum is even taking it seriously.


Thanks for the response. Yea, I get that the other languages you put in the core set are the most widely used right now so it may make sense. It’s just a bit odd for me since what brought my project to NEM originally was the promise of a Golang SDK (At a conference, Nelson told me there was one when there wasn’t haha). for me this was what really set nem apart from all the other chains we were considering. That made us look closer and only then did we find out how awesome catapult could potentially be. Even look at one of the first major acts of Proximax, it was to write that Go SDK. It’s powerful. Nobody thinks “Find me a chain where I can develop in Typescript” :joy:

while statistically PHP etc are more commonly used, I think you will find more forward thinking companies being largely written in Go. You may be getting the number covered with your choices but it’s possible that they’ll be off target. Go should be a priority IMHumbleO.

im more talking about dev team size and speed not about quality and concepts

u agree it looks like good development goals just i would love they get support in make it happen there must be code parts that they can give to helping people

a genius architect also dont build the houses he plan all alone


If you have deep knowledge of GO and some time
maybe you could come to an agreement with @jabo38
or foundation to help with developing the NEM2GO SDK when time comes
and in case there is lack of resources regarding the GO programming language.

Is this a question that any council can not answer ?