NEM Ecosystem - Symbol Launch Plan

NEM Ecosystem - Symbol Launch Plan


Edited: To include additional translations

Useful Files

Foreword from David Shaw (CEO)

It’s been a busy first week getting NEM Group up and running. We set out with 3 initial priorities, the most important being to share a detailed launch plan for Symbol within 10 days of the initial announcement. The multifaceted nature of the delivery of Symbol was a key driver behind the creation of NEM Group, and the purpose of this announcement is to align the ecosystem and discuss next steps.

This is the first test of our new approach and I’m pleased to be able to share this plan with you today. What isn’t so easy to tell you is that the launch is later in the year than some people’s expectations. Please take some time to read through this update as well as the detailed plan that we are publishing today as it provides more clarity on anticipated timelines, our reasoning and why we are confident in this plan. I want our conversations to be honest, straightforward and mature, and we are here to answer any questions you may have. It’s as important as ever to not to look back, but to get behind the launch of Symbol. It’s in all of our interests to make this a success.

This is the first announcement by NEM Group, following @Jaguar0625’s recent post outlining the governance alterations to the NEM entities. In the post, we committed to sharing a plan for Symbol launch by 18th April; and this post delivers on that commitment.


We have spent a lot of time over the past 3 weeks, surveying the various workstreams, products, activities and what is left to do, as well as identifying interdependencies between all of the tasks required to get to launch. Below is the summary of this work.

The top line message, as we noted in the original announcement, is Symbol will not launch in Q2 of 2020; at present the estimate is mid to late November 2020.

This will be perceived by some as a delay, however it is actually the first confirmed date to be communicated that is based on detailed planning in conjunction with the Core Developers, other development teams and the non-technical teams. Put simply, there is a lot of work to be done; some of it has significant outstanding effort and is necessary for launch. As a result, we have put together a known critical path, which is explained below and helps illustrate the timings required.

We invite everyone to absorb the detail and ask as many questions as you like. Regarding launch date, to bring the date earlier, some of the work either needs to happen faster or elements need to be removed from scope. If someone spots opportunities for that, we are very open to these conversations and would be happy to adjust accordingly.

The plan is a living document, it will be updated and shared regularly, which we anticipate to be every 2 weeks. The community should expect individual dates to move within the plan as more certainty emerges and work is completed. We don’t expect the final date to move significantly, in either direction, at this stage unless something unexpected occurs. The aim is to manage work and deliverables in accordance with this plan, and the main assumptions and risks to the plan are also outlined below.

The headline approximate dates that most people will care about are:

  • Opt In Opens: Mid-late June
  • Dev completes: (Core, SDKs) Mid Aug
  • Testnet starts: Mid Aug
  • Opt In Closes: Early Nov
  • Testing complete: Mid-Late Nov
  • Snapshot: Late Oct / Mid Nov
  • Launch: Mid-late Nov (as close as practical to snapshot)

Further AMA sessions will be run in the week commencing 20 April 2020, see text for details.


The image is a Google Slides presentation, it is published as an image at the link below

17-Apr-2020: Symbol Launch Roadmap (High Level) Published to Web


It is important to note that parts of the plan are key to delivery, and rely on measured assumptions based on the information that is available, these are explained below:

Core Server Development Scope

The Core Server underwent a Protocol Review/Penetration Test by a 3rd party and the findings have been assessed. The intention is for all of the recommended security updates to be included in the final public network target release, some of the changes started being introduced since the release. The final set of targeted updates are related to making harvester selection non deterministic and adding block finality (if you are not familiar with the topic of finality here is a useful article). While being vital to strengthen and protect the network, these changes also open up the utility of the network to a wider range of use cases and asset types.

In reviewing the options for releasing the public network without these consensus related updates, then targeting a future network upgrade or delaying the public release, it was decided that it’s in the best interest of the project, partners and network to apply these changes before the network is launched. This approach was reviewed and agreed with the Project Management Committee (PMC ) members, Core Developers and NEM Group leadership.

The design of these final changes has been completed and is under review by the same 3rd party that conducted the initial review. Development estimates are based on the design as it currently stands, the review results are expected in 2-3 weeks and it will be refined if necessary.

Testing Approach

A lot of testing has already been conducted, with 11 testnet resets to date. From the time the team build the “final” release candidate (RC 1.0), which is expected to be the public chain version, the formal testing will happen as below:

  • The quality assurance manager will run 2 initial rounds of automation testing and bug fix before accepting the release for deployment to the testnet for the formal soak to begin
  • The formal soak will last 3 months, as has been communicated since mid 2019
  • We assume soak testing will pass with minor bug fixes due to prior testing. If a major issue is found late in the soak, the response will be assessed, and is likely to result in another 3 month clock reset. We are doing everything possible to try and set this soak up to run smoothly, however this risk is present. The community can help early in this cycle to ensure we have a better chance of finding issues early. Details for how will be provided well in advance.
  • You will see in the plan that a Cycle 4 is present and set to 0. It’s there in case we need to reset so it’s clear on the plan what the impact is, it can be ignored for now and will be used if required in a later update.

Japanese Regulatory Process

Some in the community may be unaware that the process to be approved for digital asset listing in the regulatory environment in Japan requires the following steps:

  1. A licensed exchange wants to list and commits to gaining regulator approval for an asset

  2. The exchange applies to the JVCEA, who write a report to the FSA

  3. Submission to the FSA for review and approval

The timescales for these points are outside a project’s control, as no direct communication occurs between the project and the regulatory entities. It is performed by an exchange that wishes to list XYM completing the documentation.

The plan contains estimates of 5 weeks for both the JVCEA and FSA steps. The actual estimates are from a Japanese company assisting with the Exchange documentation, they are 4-6 weeks each. If these dates extend, a decision will need to be made, by the community, on the correct path to follow.

We are minimising this risk as much as we can by engaging with a company in Japan who knows NEM very well and has experience in the environment - Stir Network and its CEO @Shohei_Kamon. We are also offering exchanges as much help as possible with direct access to the leadership team. Taking the lead from NEM Group will be Iain Wilson who has 25 years experience working in regulated financial markets and will help ensure we provide the level of detail that is expected.

Snapshot Process

The current plan shows a simple linear approach to Opt In ending and a snapshot being taken. It deliberately shows a range within which the snapshot can occur. As development and testing progress, this will be refined.

There are several options for this process. Our intention is to present viable options and engage the community to choose between the options, rather than a binary accept or reject the recommended approach. These will be detailed and shared in due course.


  • Documentation: There is a section in the plan for documentation that will expand as additional scope is added and report on the actual delivery of the tasks. This is not on the critical path at present and it is likely this will expand over the coming weeks, it has no impact on delivery date.

  • Symbol Academy: Is not in the plan at present. This is primarily because the team has not yet had time to fully review its position and what is needed for it to launch. We do not expect it to be on the critical path and additional information will be published over the coming weeks.

  • NIS1: There is known NIS1 work that is not included in this plan because it is contingent on a community vote on the proposal and as a result will be managed as a separate project

  • MS Project: The number of tasks (~250 lines) with multiple interdependencies has meant we have opted for MS Project. It is an enterprise grade tool and was chosen after we tried other options that are simpler for non project managers to use, but they were incapable of the functionality that was needed to produce the plan. The MPP file is available to anyone who can open it. Fortunately there are tools available for anyone who wants to see the details but doesn’t have MS Project, and other similar tools exist, see later in the announcement.

Project Plan Detail

This section provides an overview of the work that has been done in order to reach the conclusions above. Every line is available to the community for inspection and nothing is held back (see end of section). However, as there is a lot of information, some key areas are highlighted below.

Critical Path

Critical path, for anyone not familiar with the term, is a technique to identify the main tasks in a plan that if they alter for some reason, will impact the launch date. The following are the primary items on the Critical Path at present and will be the most closely monitored and managed by the team during delivery:

  • Development work: While this may seem obvious, this work is the starting point for everything else on the Critical Path

  • Soak test: Starts soon after the development work completes, can’t start without it. If something happens during the 3 months, especially near the end, that requires a breaking change or reset, this may have an impact on launch. At present, it is very hard to see how this testing period could be shortened without impacting quality

  • Japanese Regulatory Process: The regulatory requirements outlined above mean Exchange partners in Japan cannot support XYM until the process is complete. Clearly Japan is of huge importance to NEM, and if everything else in the roadmap is finished except this, it may have an impact on launch. This may lead to a community vote on how to proceed, although this is not currently an issue. We are comfortable Exchange partners in all other regions will be able to work with this timescale.

At present the development work and soak test largely drive the timeline. However if the Japanese regulatory work extends by a few weeks, it will become longer than development and soak work on the Critical Path.

It should be noted for anyone concerned about Finality inclusion being the reason for the time to launch, removing it saves only a few weeks due to the Japanese regulatory process being next on the critical path. We would need to launch without both Finality and Japanese Exchange support to make any significant change to the date, which we do not feel is an advisable approach for obvious reasons. The other reasons for Finality inclusion have been given above.

Detailed Project Plan

Everyone is free and encouraged to review the details of the MS Project Plan, we recommend using one of the below for anyone without an MS Project licence. This appears to work best with Chrome and for other browsers there are similar extensions

Once you have installed your application of choice in your Google account. You can use the link below to access the file (we will try not to change this in the future, but will inform if it does):

Note: if you have multiple Google accounts, check you are still signed into the correct account, as it seems to change quite frequently. Wait a few seconds and the menu below appears, select your app of choice and it should open.

Opportunities to Bring the Date Forward

There are a few potential opportunities to bring the date forward. We have planned as realistically as possible, with conservative estimates in place but no standard contingency. In some plans you may see for example a 20% contingency included, that is not the case here. The estimates are what we currently forecast to be required to deliver.

The following areas are worth watching for opportunities to shorten the time frame:

  • Core development work: is estimated between 60-70 days, we have allocated 70 days. If it comes in quicker, other elements of the plan move forward and vice versa if issues are found in development that extend it

  • Testing: although it’s unlikely the soak time will be reduced, dates could move forward if development is shorter than expected. The more the community can get involved in finding issues and bugs early in this testnet release, the better. This will be clearly communicated well ahead of time.

  • Japanese regulatory process: by being as diligent as possible with our exchange partners, and this has already started. There is potential for the work to be on the lower end of the 4-6 week estimate, right now it is planned based on 5 weeks. This is largely out of the project’s ability to assist with and will depend on the quality of applications submitted by Exchanges, workloads of the regulatory agencies, how many questions need to come back as part of approval, etc.

Ask Me Anything (AMA)

We intend to run further Ask Me Anything (AMA) sessions in the week commencing 20th April. These will focus purely on questions pertaining to the launch plan. For efficiency, and given the workload and timescale involved, these will be run on Twitter and work similarly to the initial AMAs:

You can tweet your question to the @NemberAMA account before the session or during by either including @NemberAMA in the Tweet or using #NemberAMA (using # is preferable as it is easier to find but both will work). We will also follow up on unanswered questions following the AMAs.

The Japanese session is early, we are aware. This is due to trying to find a timezone that the team can all be present, that also works in Japan. The session will be 2 hours long. We encourage the community to submit questions ahead of time and we will answer the early ones during the session, following up on unanswered ones as soon as practical afterwards.

The times are below. Where possible, we will have the entire NEM Group team available and Core Developers in some, as well as local language support from the various teams:

  • Monday 20th of April 2020
  • Tuesday 21st of April 2020



This is a long update and there is a lot of detailed information to absorb, we expect there will be many questions and are ready to answer them as openly and frankly as we can. Please post any initial questions on this forum post, or in the AMAs above and let’s take the conversation from there.

Finally, I would like to thank the community and team for all the work that has been required to get the plan to its current stage. We appreciate the projected date is not going to please some of the community, even though it is based on the known work required to get to launch.

With that in mind, we hope that you take the time to absorb the details and focus constructive energy on what you think could change in the plan to move that date forward, while ensuring the most effective launch possible.


Ya…good luck.

1 Like

2021 wow!

1 Like



If the XEM price does not go up, NEM will not have enough participants, and there will not be enough test nodes for the Symbol test network.


Our progress has been delayed for a long time, which makes me want to sell all XEM …


We lost a lot of players who love NEM.


I still like XEM, but it really makes me feel helpless.


This is the last chance I’m giving xem/ symbol. If this isn’t working by December, I’ll sell all my xem and forget about it forever. It’s been many times while we’ve been faithful in the community and it seems that it’s not serious anymore. It takes months to gain trust but only seconds to lose it. Lies and delays can no longer be trusted.


Promising development.


1 Like

NEM is good, just screwed up …

Although I agree that quality is important, it may not take a long time to test. Many public chains have various problems and bugs, but it do not affect their price rise and popularity.

1 Like

This is the time to support the team. If the software is not ready for mainnet, the last thing we want to do is to push the release. The new infrastructure must provide uncompromising security and trust to create value, otherwise there is no point in having it. Distracting the devs will not help either.


It’s standard development practice. Ethereum do the same thing.


Yes, you are right.But we are not Ethereum. We are NEM and face our own problems. We should make adjustments according to our own problems, not just follow standards or other chains.


from Q3 2019 to maybe Q4 2020.

Thanks Alex for destroying 1 whole year of NEM :slight_smile:

2 possible reasons for this (very big) delay:

  1. Alex and her friends are uncompetent so they thought they could finish in 2019 despite it was impossible
  2. Alex and her friends did nothing so far except sueing / banning people and speaking good useless words.

I can imagine all those useless suckpuppets coming to say “OMG YOU TROLL, ALEX AND NF ARE THE BEST OMG” :slight_smile:

PS: Thanks David for your job, at least we can trust a competent person to lead NEM now :slight_smile:

I hope David will bulldoze all this by firing many useless people


roadmap is ok

what i miss is a clear statement that the already by poi confirmed xym tokenomics proposal is still the way it will be even after leadership change

for me tokenomics and that there wont be a ninjachange is the most important part

please confirm


Experienced people left, and inexperienced people stayed. Eventually leading to problems and delays


There’s no reason for this to be removed. The foundation has not done what they promised. If you make promises, you gotta be able to handle it when people are pissed that you broke them. The idea being, you shouldn’t make promises you can’t keep.