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.
Launch Date Targeting Q1 2020
What has been done to date:
- 02- 07- 2019 Migration Committee set up
- 15- 09- 2019 Initial proposal posted
- 02- 10- 2019 Tokenomics drafted
- 02- 10- 2019 FC Release F1
- 15- 11- 2019 Migration Committee recommendation/ update Issued
- 18- 11- 2019 RC Release F2
- 25- 11- 2019 Tokenomics recommendation made with POI
- 27- 11- 2019 Test Net available
- 12- 12- 2019 Wallets ready
- Dec 2019 Pen Testing complete (dependent on RC Release F2 outcome)
- 03- Jan- 2020 Branding guidelines/ toolset delivered
- Feb - Mar 2020 LAUNCH
- Mar 2020 Post launch re-evaluate and reconfirm future plans still stand
Based on the milestone timelines above, Catapult is still aiming for Q1 2020 launch. We will keep everyone posted as things progress.
A one-page recap for current migration discussions can be found here
Process For Catapult Launch
A common question from the community is in regards to what the process is for decision making to move the Catapult launch forward. This is the (high-level) recommendation from Foundation, Studios and Ventures to the core devs.
- Migration Committee forms an initial proposal for technical options, tokenomics and brand and shares with the community for feedback. Technical Options complete, Tokenomics and Brand ongoing, expected to complete in Nov
- Feedback is absorbed and balanced between what is wanted and what is possible, across various stakeholder groups (Core Devs, Super Node Holders, Wider Community, NEM Entities, External Parties) and creates three proposals
- Migration Path - approx 90% complete, awaiting Opt In vs Opt Out decisions
- Tokenomics - underway, expected to be shared by end of Nov at latest
- Brand - underway, expected to be shared by mid January 2020 at the latest
- A single summary proposal encompassing all three elements is drafted and put to the community for a decision. If it is rejected then it will be reworked but this may impact Q1 2020 launch and that must be balanced to avoid as a priority
Front End Development
Progress revolving the front end development are as follows:
Desktop Wallet: The latest release of the Desktop Wallet (v0.8.5) is compatible with private blockchain networks and just got updated to work with the NEM Foundation Experimental Testnet for Catapult as well. The desktop wallet and SDK teams are cooperating cross-entities to integrate latest protocol version updates. An early beta phase has been initiated for this project of which you can view the source code on Github (here).
Mobile Wallet: There is currently no public release for the Mobile Wallet yet but the package has been worked on and will be released in the form of a Google Play Store App as well as an Apple Store App. (iOS)
Block Explorer: The latest release of the [Block Explorer] is available as a demo and can also be used for private blockchain networks and with the NEM Foundation Experimental Testnet for Catapult as well. An early beta phase has been initiated for this project of which you can view the source code on Github (here).
Hardware Wallets: The hardware wallet integration for Trezor in the Desktop Wallet has started and has done good progress (click here for progress). The team at Labrys is currently working on the firmware integration of Catapult for Trezor devices A service provider of the NEM Foundation is also working on the integration of Catapult for Ledger hardware devices, this project is still in its early phase and has not been published yet.
Progress involving Catapult development are as follows:
The NEM Studios developers are working their way through all the latest Fushicho Server changes. We are targeting the last week of November for public release of the updated SDKs.
Review and Testing: The next phases of testing are beginning including new performance testing and penetration testing by a third party, as we begin the open bug bounty program on the security review platform HackerOne. These efforts will continue through release time.
Depending on the results of said testing, lead times may extend to ensure quality management.
The Branding Steering Committee has made significant progress in developing a new brand to launch Catapult. A key part of this work has been to establish a ‘brand narrative’, setting out Catapult’s ambition, brand characteristics, value proposition, and target audience in a way that differentiates Catapult as a competitive leader.
We’d like to encourage everyone to join in these brand discussion in the newly formed Catapult Branding channel in the NEM Forum (here).
Exchange outreach and engagement continues. The feedback from exchanges thus far has been encouraging.
All high level documentations were shared with the Supernode Holder’s Group (SHG) for discussion and comments. Talks have pivoted around those documents released and concerns addressed by the Migration Committee (MC). Members of the verified SHG group have shared proposals of their own for discussion, in areas they feel they can assist with.
As discussions continued and documents were analysed, the areas of discussion were structured into 3 main categories:
- Marketing/ Branding (details above)
The majority of the SHG that took part in the Migration discussion agreed on the following:
- The SHG broadly view Catapult launch as an upgrade, several key members view it as a Fresh Start however, the fresh start position is also held by the Core Developers
- The SHG agree with the Migration Committee that the migration dataset that can be most easily migrated is Accounts with same keys, NIS1 XEM balances (Opt in or Opt Out), Multi-Sig account configurations (opt-in) & root namespaces (opt-in)
- The SHG disagree with the Committee in relation to Multi Signature Account Configuration migration approach, SHG prefer a Snapshot of NIS1 config and to work around the cosigner confirmation in Catapult Nemesis, MC prefer the Opt In approach requiring explicit signing of transactions by cosigners for the migration
- SHG agree with MC that it is preferable if single accounts have the option to be able to choose if they receive Catapult tokens or not
- SHG prefer that all accounts opted in by default and they must actively opt out (can opt in later), this is not a view supported by the Core Developers
- SHG agree with the MC not to change the supply of the token (9 billion)
- SHG agree that in the case of unclaimed tokens remaining unclaimed- there should be a specific period for the tokens to be claimed
- In the case of unclaimed tokens remaining unclaimed and there is a defined period which then expires, the SHG preferred that the tokens should be burned
- In the case that there are unclaimed tokens remaining after the cut off date for claims, SHG prefers that we should create something similar to the SuperNode monitor approach to monitor NIS1 account for new opt-ins and Core control the unclaimed tokens, MC recommends they be placed under a legal vehicle with clear and transparent governance.
- IF one of the options are taken that permit user choice, then Tokens will remain untouched on NIS1 and it continues as it is today
Various members of the community, migration committee, and supernode holders group have expressed ideas/preferences. At present this information is being collated with a view to making a recommendation from the Migration Committee, the process will be as follows:
- 11/11/2019: A framework will be shared by MC representatives with a working group of long standing, significantly invested community members for input, it will be discussed for 1-2 weeks (shorter if possible) to identify a common position
- It will then be shared with the wider ecosystem teams for sanity testing/proofing (NF, NV, NS, Core Devs, Supernode Group & Forums). This is expected to be a relatively quick process due to the level of input received so far.
- Assuming no major opposition, it will be included into the Migration Proposal; target is the last week of Nov.
Priority is being given to Catapult Tokenomics as they are more complex, NIS1 will be run in parallel, initially slightly behind.
Thanks for your continued support,