Public Communication: Catapult Migration (2)
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.
- Japanese: Forthcoming
- Spanish: Forthcoming
- Mandarin: Forthcoming
- Italian: Forthcoming
- Russian: Forthcoming
Over the past four weeks, the committee has filled out and discussed the scope survey off the back of key recommendations that have been made prior. Having minimum requirements for a successful catapult product launch has now enabled the project managers to nail down a better baseline and develop a milestone chart on the current project trajectory. As we progress through discussion on how pre-nemesis “First Movers” will look like, and what kind of support is needed – the team is reaching an agreement determining the minimum amount of nodes necessary for launch (and other pre-NEMesis considerations).
As more key recommendations are being made since the commencement of the task force, we can now engage with exchanges in a more meaningful way (in regards to migration preparation and listing). In addition to migration team members doing outreach, NEM Foundation has allocated additional resources toward exchange outreach by assigning an exchange task force comprised of Anton Bosenko, Alex Tinsman, Flora Fang, Pedro Gutierrrz, Jeff McDonald, and Greg Evias to head discussions and prep exchanges for migration. This also includes the support of technical team
Cryptobeliever and Ъ!!!11.
Based on the Scope survey conducted internally and externally, it is agreed that the minimal number of exchanges needed to jump on-board for launch would be 2-5 medium to large exchanges. These 2-5 exchanges will be chosen based on geographic location and XEM volumes traded (a FAQ doc is now being finalised in order to drive these engagements).
In parallel with the exchange engagement plan, the committee is also prioritizing tokenomics and a NIS1 assurance proposal to ensure the viability of the chain post launch in hopes for it to be suitable for all community stakeholders.
With the information and resources available at the present, the current milestone timelines are as follows:
Timelines may change due to external variables
Assumptions & Considerations:
- Engineering estimates approximately 3 months of testing and verification from the time of the release candidate. This is a central scenario with little rework required.
- Pre-Nemesis timelines not scoped, two weeks has been suggested
- Timeline above doesn’t include exchanges. Discussions with exchanges continue on this.
Launch Date Targeting Q1 2020
Based on the milestone timelines above, Catapult launch is now targeting Q1 2020. We will keep everyone posted as things progress.
Front End Development
Progress revolving the front end development are as follows:
Desktop Wallet: The Desktop wallet will include full functionality that will allow end users to utilise new Catapult features on their computers (targeted for Windows and macOS). This includes the creation of restrictable mosaics, the publication of aliases with namespaces and the execution of transaction URIs – which can contain anything disposable digital contract.
Mobile Wallet: The Mobile Wallet will feature a minimalist focused design that will allow end users to utilise core transactionary functions within their mobile phones. Accounts managed on the Mobile Wallet will be compatible with the Desktop Wallet such that QR Codes can be generated to switch from one wallet to the other.
Block Explorer: The Block Explorer will allow users to observe the contents of individual blocks, transactions, transaction histories and balances of addresses on the new Catapult network.
Hardware Wallets: Catapult integration with TREZOR and Ledger has started.
Foundation has made a contract with Hackerone for bug testing for wallets and block explorer. More details will be forthcoming soon. We look forward to the community participating!
Block Explorer, Desktop Wallet and Mobile Wallet are all on schedule to be tested and completed in December 2019. An early beta phase has been initiated for some of these projects. You can view the source code of these packages on Github:
Progress involving backend development are as follows:
- Catapult Server released 2nd October
- REST Server RC build target 7th October
- TypeScript SDK RC build target 9th October
- Java SDK RC build target 11th October
Testing Environment: The testing environment for Catapult will be up and running with the Release Candidate.
Testing: Testing for the Catapult network is scheduled to be completed by Q1, 2020.
Depending on the results of said testing, lead times may extend to ensure quality management.
Public Launch Problem Solving
Questions may arise as to why some of the migration recommendations were made. The following list is an attempt to give more visibility on the side of the community with regards to actual problem solving and decision making:
What are the hurdles of a migration approach resulting in one network?
- Catapult technology has been rewritten from scratch and is not meant to be compatible with NIS technology. Catapult re-defines all transaction types, it has a different signature scheme and uses different account and multi-signature information.
- While discussing the possibility to launch a Catapult public network as soon as possible, problems arose with regards to partners / exchanges / supporters who would be obligated to migrate. With the knowledge that these, for the most part, could have business processes running on the NIS1 chain, it seemed very unlikely that all partners, all exchanges and all supporters would upgrade their software by said date – strong deadline to consider.
What is the reason for making a copy of XEM balances, keys, multi sig accounts, and namespaces only ?
- During a migration process, a snapshot of the balances must be taken at a certain block X. On the current NIS public network, this is possible only for the XEM mosaic as it is the only mosaic for which there is historical balance data. That is, for XEM it is possible to query the balance of Alice for block X – this is not possible for other mosaics. It is possible for others as well, its just undesirable/lot of work and most of it is likely not required. We also aren’t taking xem balance histories/txes for this reason.
Can we copy multi-signature contracts over to Catapult ?
- Yes, it is possible with user interaction.
- Catapult technology introduces an incompatibility in multi-signature accounts where a cosignatory must now confirm that he/she wants to be added to a multi-signature contract – in fact, he/she will have to confirm by sending a cosignature of the multi-signature contract transaction.
- In other words: in order for multi-signature contracts on NIS to be re-created on Catapult, it will need end user interaction. In case we would have skipped user interaction, the multi-signature contract may have been created but would have been unverifiable.
Can we copy namespace registrations over to Catapult?
- Yes, it is possible with user interaction.
- Namespace registration transactions could be included in the nemesis block without being signed by the owner. The migration committee recommended to avoid this as it is undesirable to include unverifiable data onto a newly launched public blockchain network. The data would be unverifiable because the transaction would be signed by the nemesis account, which is not the owner of the namespace being registered.
- In a matter to reduce the risk of namespace squatting on the Catapult public network we also recommended to migrate root namespaces given end user interaction. In this optic, namespace owners on NIS will be given the possibility to sign a Catapult namespace registration transaction pre-launch, which will then be included in the nemesis block.
- Subnamespaces are numerous on NIS and the creation of these on the Catapult public network is trivial for the end user. As such it is recommended to not migrate sub-namespaces as doing so would result in a bloated nemesis block with too many sub-namespace registration transactions.
Work has been progressing well on the Catapult branding and go-to-market strategy, run by the Brand Steering Committee (comprised of Alexandra Tinsman, Nate D’Amico, the new Foundation CMO Lewis Farrell, and David Shaw) who are working with an external branding agency.
Following an extensive audit of the competitor landscape, and looking at inspirational brands as benchmarks, the agency has made significant progress to develop the brand to launch Catapult. A key part of this work has been to establish a ‘brand narrative’, setting out our ambition, what we believe in, our brand proposition, and who our audience is. This provides the groundwork for every communication and expression of a brand, so it has been important to get this right, different and credible. They’ve also shared an in-depth review of our competitors and how they express their brand visually and tonally, which further helps us identify our point of difference and uniqueness. And, they have been developing a shortlist of potential names that we can use for Catapult.
Next steps will be to develop the proposition further, developing visual and verbal examples of our brand that will guide how we communicate across multiple channels and touchpoints, and through trademark experts, ensuring the appropriate legal due diligence on the brand names we shortlist is done. More details will be forthcoming in future updates.
The migration committee has been strategically engaging with global exchanges with regards to the listing process for Catapult. For perspective, XEM is listed on ~100 exchanges worldwide and our teams have developed strong partnerships with some of these exchanges over the years.
Regarding the process for exchange listings, it’s important to note that most exchanges have stringent listing processes and may require a listing fee. The outreach with exchanges includes digital assets which meet our standards and comply with local laws in the jurisdictions where they are made available for trading.
Due to NDAs and discussions with the exchanges, we cannot share names of exchanges we are engaging with but we can share that exchange listings are targeted by the following criteria:
- Volume / Liquidity
- Geographic alignment with NEM community
Supernode Owner Engagement
Representatives from the migration committee have set up a communication channel with verified Supernode owners and the core developers to discuss feedback on the migration committee’s recommendations. Feedback is also being collected via a survey and then will be shared across teams for consideration.
Thanks for your continued support,