Migration Committee Community Update #3.2 - Post Launch Opt In

Catapult Migration
#1

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)

Translations :

  • Japanese: Link.
  • Spanish: Forthcoming
  • Mandarin: Forthcoming
  • Italian: Link.
  • Russian: Link.

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:

  1. The technical options for extending the supernode monitor solution to ensure it is actually viable

  2. 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.

  3. 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.

6 Likes
Symbol Launch Reporting & Single Source of Information
#2

Is there any way the opt in/out can be handled on chain in the means of a multisig contract?
That way, when you claim the tokens, you are basically signing your side of the contract after genesis block creation to receive the tokens.
Would have to have no expiry limit for signing to work I assume.
Added benefits would be that no person(s) are responsible.

1 Like
#3

The SPV is not preferred, but if there is not a better workable idea, then that would be the second best.
The best idea would probably be a supernode managing automatic fund sending solution, but not sure if that can work in reality or if it safe.

6 years will be plenty in my opinion and then burn the rest. The date has to be set at catapult launch and thoroughly communicated immediately.

#4

What is ā€œNIS1 SuperNode monitorā€?

1 Like
#5

The monitoring utility that checks supernode health and distributes payments - I couldnā€™t think of a better name for it, sorry if it was confusing

#6

This was looked at but there are a few challenges with it - you end up with X number of outstanding transactions that need to be stored on all nodes (bloat) and something needs to be able to sign it (what?..generally you end up back at the monitor solution anyway so in that case may as well use it to initiate as well)

#7

Agreed, exact details need fully working through assuming the general direction is agreed to be ok by most of the community.

6 years came from the statute of limitations in a DLT friendly jurisdiction so it lines up well from that perspective as well

#8

Thank you for your replay.
Is the below link NIS1 SuperNode monitor?
How do you use the tool like NIS Supernode monitor?
And then can anyone verifies the opt-in claim?

https://supernodes.nem.io/

#9

No problem, happy to help if I can.

That site is a public list of the supernodes.

There is a separate utility that runs as part of the network which checks supernodes are healthy, online etc and handles the payment of supernode daily rewards. Its not really a tool that you would use as a user, it just has some logic and manages distribution of tokens already for one purpose, so part of an idea was it could possibly be extended to handle the unclaimed tokens. It is a behind the scenes tool though.

2 Likes
#10

If this was to happen, will be highly recommended to have legal contracts in place and a very clear letter sent to all potential owners of the unclaimed funds on what the SPV does. Also maybe another letter to owners which have claimed their tokens that there should be no outstanding ā€˜liabilitiesā€™ if there were other tokens unclaimed - would assume that there would be multiple wallets for some individualsā€¦

Feels a bit top heavy on the legal side but to leave the unclaimed tokens untouched and burned at the end of the claim period is a good idea. I donā€™t think it should be done other way.

Looks like not the best of the option but well thought out. Thanks for working through this.