Catapult Launch Announcement 1
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.
Translations:
Representatives of each entity have been working together since July 2019 in a steering committee comprised of a team with extensive experience and diverse qualifications - analysing and discussing the various options, challenges, implications and opportunities relating to public release of Catapult.
We would like to share our current plan and next steps so the NEM community can see what is planned at present and which recommendations have been made to-date. A lot of work has been undertaken by various parties, including Core Developers who released Catapult Elephant version 3 in early September after 3.5 years of work. Catapult represents a brand new technology stack, with cutting edge features that have never been available on a decentralized system, including aggregated transactions and multi-level multisignature accounts, while building on the already solid feature set we know and love from NIS1.
After many discussions and much consideration, The Catapult Migration Team has reached an approach, which has been recommended to and reviewed by the NEM Core Team.
The primary decisions are summarised below and further explained in more detail:
Networks/Chains: Two
Token Names: Two
Type of Launch: Opt-In to new chain
Being Migrated: XEM Balances, Multi-Sig accounts, Root Namespace
Not Migrated: Everything else
(Sub-Namespace, Mosaic, Mosaic balances, Tx data etc)
Two Networks/Chains
This is likely the most complex issue to consider; it has taken several weeks of debate, legal advice, planning & testing, analysis and consideration. Here is the key reasoning for this decision:
-
The technology stack between NIS1 and Catapult is not compatible; this was decided at the start of our Catapult work and that means an in-situ upgrade of the existing nodes would be very difficult, It would require lengthy coordination and risk to upgrade them all effectively as they are distributed, decentralised, and under no obligation to do so.
-
Considering the above, the only way to adopt a single chain approach is to have a coordinated switch on of Catapult and switch off of NIS1. This requires centralised control over NIS1, which is not present and it would be going against several core principles within the Blockchain and DLT space. It would also require a central decision to compel everyone to move from the old NIS1 chain to the new Catapult chain - again a centralised decision that would not desirable. Furthermore, this approach raises a number of complex legal issues and is likely to require facilities such as the ability to refuse and demand the equivalent in FIAT, or liability for anything that goes wrong, as well as limited ability to fix any post go live issues without performing a Chain Reorg.
-
Two chains co-existing in parallel is a scenario that comes with its own challenges, which we will be addressing in our tokenomics work shortly, primarily around incentivisation and node assurance on both networks. However, given that it is nearly impossible to practically upgrade in situ, and a centralised decision to shut down a decentralised chain is not appropriate, then the Two Chain approach is what prevails.
The plan is to introduce the Catapult chain in parallel with NIS1. No centralised shut down of NIS1 is planned, and there will be cross-ecosystem efforts to ensure this is supported for a significant period of time. This approach means that all the data on NIS1 remains intact, immutable and queryable. As well, projects and holders can choose the point they wish to cut over and that NIS1 can be used as an immutable, verifiable source of truth for the opt-in process below.
Two Tokens
With the two chains, we will have two tokens and each chain will have a native currency to pay for on chain transactions.
Therefore XEM will continue and a new token will be created for Catapult. The name of this new token is being worked on at present, and the process presents a number of challenges and opportunities. More news on this is due to be released as soon as practical some great work has been done by the go to market team to date. There are several branding, partner engagement and legal processes to work through, which our timelines are dependant upon.
Opt-In Token Allocation
When considering how to allow the movement of XEM holdings from NIS1 to Catapult in a two-chain scenario, there are only really three main options:
- Snapshot: Copy all XEM balances, for all accounts over from NIS1 to Catapult at inception. The migration of Multi-Sig security controls is problematic under this approach, which risks placing large NIS1 Multi-Sig accounts under single signature control which is a security risk for holders\exchanges who have consciously chosen the higher security Multi-Sig offers. This is also a centralised decision and forces everyone to assume ownership of Catapult tokens on day 1, whether they want to or not.
There are a potential Tax, Legal and philosophical challenges with this and the approach is generally used in Hard Forks where a chain is splitting due to community splits (BTC -> BCH -> BSV or ETC/ETH) or bugs, etc. Neither of these is the case for Catapult.
-
Token Swap: Under this model, holders are free to opt in pre-launch or post-launch, surrender their XEM and be given Catapult tokens. This is a philosophically strong approach and avoids the splitting of value over two tokens at account level. However, in the instance that we are running two chains, it introduces several challenges which are considered a higher risk by the group:
-
NIS1 ownership becomes more centralised (exponentially over time) as people opt-in and burn tokens; undermining the stability of NIS1 which is still being used by projects not yet ready to migrate and also for the opt-in process. There will be valid reasons why people can’t/don’t want to opt in immediately, this stability risk presents challenges for some post-launch opt in.
-
There are also potential legal complications for entities (and individuals) involved in the process and our legal teams have advised the boards of all NEM entities and core team against this.
-
Token Allocation: Under this model, holders are free to opt in pre-launch or post-launch, it does not require surrendering of the XEM tokens and are given Catapult tokens. Holders opt-in pre Catapult launch by sending a transaction from Nano Wallet (or programmatically) which indicates their desire to take part, but does not require them to burn their tokens. The Catapult Nemesis block then distributes Catapult tokens to those accounts that have opted in. Any tokens that are not claimed by the Nemesis block will be placed under a legal entity with transparent by-laws/trust deeds and leadership team, to be claimed post go live up to an as yet to be defined deadline - it should be years long, so is likely to be significant in nature and it is probable; a new entity will be created for this purpose and legal analysis is underway to guide this, we will provide further information when it is known. It is imperative that this entity has clear, transparent and legally enforceable rules which bind its management to work for the ongoing health of the NEM ecosystem for the future. This will take some time but is worth getting right.
After much deliberation, the migration committee has voted that the best approach to take is the Token Allocation Opt In, which is also the same mechanism that Ethereum is using for their One Way Bridge opt in to Eth 2.0, probably for similar reasons.
In Scope (Public Keys, XEM Balances, Multi Sig & Root Namespaces)
We will migrate all Account Public Keys, XEM balances, Multi Signature configurations, and Root Namespaces for those that choose to opt in pre launch. This opt in will be performed on chain on NIS1 and the data used by Catapult Nemesis at inception of the new chain.
It will not be possible to migrate the Root Namespaces post launch, meaning all unclaimed namespaces will be freely available immediately post launch. Everything else will also have a post launch opt in mechanism which as far as possible will be automated; details on this will follow in due course as we test several approaches technically.
This approach restricts the amount of irrelevant data that is migrated to Catapult and the chain will get a clean start with only the data that is required for protecting token balances, securing accounts and avoiding namespace squatting.
Out of Scope (Everything else)
Everything else will still be available on NIS1 and accessible beyond Catapult launch. The NEM Foundation and NEM Studios are working on several tools that will help projects that wish to migrate additional data (transaction payloads, sub namespaces, other mosaics, other mosaic balances, etc.). Further updates on this will be given in due course, as they become available for testing on the two testnets.
Next Steps
Now that the big headline recommendations have been accepted and we have a concrete path forward, the immediate next steps are:
1.) Define the Scope - what exactly is and isn’t needed to consider the v2 Catapult based network and related efforts ready to launch and beyond.
2.) Planning - compile information from the leads on how long the Scope will take to deliver.
3.) Implementation: actively monitor execution, providing the community with regular updates on progress.
Some of these components are technical, some are legal, some are commercial, and some are brand related to help ensure the holistic combination of all the factors come together in order to launch not just an upgraded chain, but a revamped product that has all the supporting components it needs to succeed.
The collation of this information is underway and has been for a few weeks already. We hope to be able to complete the high level view of this imminently, that will then drive the answer to the big question - “When Catapult?” Whilst we will provide a date for this soon, it may be subject to risk of change due to factors outwith the ecosystem’s control and any rework needed etc.
In parallel with the above, work is ongoing to validate a full tokenomics model which we intend to share in the coming weeks.
We Want Your Input
We value your input, and are now at a point where we are ready to gather our community’s views on which potential features are most important to you with respect to the Catapult Product Launch. We have produced a Google form to collate any input you wish to provide – no personally identifiable information is required and we would encourage you to have your say by completing this form.
This form will be widely shared on our channels in order to get as much feedback as possible, and the feature set that emerges will help inform the scope (and therefore the exact launch date). We hope to have this information in a few weeks, so stay tuned for more updates.
Thank you,
Catapult Migration Committee
