Public Communication: Catapult Migration (3.2) - Post Launch Opt In Process
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
It is a follow up discussion point from Migration Committee Community Update #3 (Revised Recommendation)
Post Launch Opt In Process
This topic is specifically focused on how we manage any NIS1 token holders that for whatever reason to not take up their allocation of Catapult tokens on day 1 but decide to delay it to post launch. This could be for any reason and we are not interested in debating the details of why, we have had sufficient feedback that it is need to validate it as a requirement. The discussion is more on the HOW.
Under either the Opt In or Opt Out approach discussed further in this topic. There will be a proportion of tokens that are created in the Catapult initiation, but cannot be allocated to the token holder that is entitle to claim them. So what should happen to them?
The original recommendation by the Migration Committee was to place all unclaimed tokens under the control of a Special Purpose Vehicle (SPV) - a legal entity that is responsible for managing the tokens until the end of the claim period (length to be decided, likely 5-6 years at least) and then burn them at the end of the period. The process could be manual or automated but there would be a single legal owner of them until claimed or burned. The SPV would have fully transparent trust deeds/articles/by-laws and a known management team, it would be legally liable for managing the funds in accordance with the decision and the rules governing the organisation.
The feedback from the SuperNode Holders group was that the use of an SPV is not preferred and either a solution similar to the NIS1 SuperNode monitor or a process managed by supernode holders is preferred, however the voting was not definitive and further input from the community would be beneficial.
Further analysis needs to be conducted in relation to:
The technical options for extending the supernode monitor solution to ensure it is actually viable
Legal analysis to ascertain if any/all/some of the supernode holders would be incurring legal liability if they were to be managing the unclaimed tokens and if so, that those involved accept that liability in a transparent manner.
Similarly the legal position of someone changing the Supernode monitor and hosting it to perform this role.
A move to Opt Out (from Opt In) does provide an opportunity to include acceptance of whichever solution is used for for the Post Launch Opt In process as part of the Ux, effectively signing into a contract for their tokens being managed by the agreed process.
The previous Opt In approach would assign all unclaimed coins by default to be managed post launch, with no interaction from the holders. Opt Out explicitly requires interaction and therefore explicit decision/permission.
This may change some people’s philosophical position to how the unclaimed tokens are best managed, or it may not. It is important that whichever group undertakes the management of the unclaimed tokens on behalf of the ecosystem is fully aware and accepting of the legal liability that may come from doing so in the event of any issues.
We are interested in all ideas, comments, questions etc on this topic as it is one very much that the community needs to be ok with and there are pros/cons to all options.