Symbol Launch Discussion Topic (1/3) - Post Launch Opt In

General Discussion
#1

Post Launch Opt In Discussion(s)

Hi all,

This is the first of three discussion topics we are opening this week. The intention of this post is to gather input, discussion, opinions, questions etc about the Post Launch Opt In process.

The below is a proposal/start point for how NGL is thinking the Post Launch Opt In process could run, this is a discussion and not set in stone, we are specifically asking for likes/dislikes, problems/opportunities etc. that the community can spot here.

Attached is a longer requirements document but the high level bullet points would be:

  • Post launch opting in to start as soon as practical after Pre-launch opt in closes. This may be before launch or may be just after launch depending on the delivery timescales for the post launch opt in UI components (they work slightly differently to Pre-launch)

  • Post launch token allocations (pay outs) will not start for a period of approx 6-8 weeks post launch, this is to allow a period where things can stabilise, any issues can be resolved and the tech teams can focus on any tidy up work from launch.

  • Opt ins that are for NIS1 balances of 100 XEM and over at snapshot block will be sent to one account on NIS1, those that are < 100 XEM will be sent to a second account (see discussion here on this one)

  • Fees payable for transfer of tokens on the Symbol chain will be deducted from the recipient’s balance, there will be a minimum snapshot balance requirement of ~1 XEM to opt in Post Launch (exact number to be confirmed one multi-sig is easier to test on Testnet).

  • The intention is to make weekly token allocations for the first 6 months, after that it will change to monthly.

  • The Post Launch opt in will only allow migration of XEM balances to XYM based on the XEM balance at snapshot block height; no migration of namespaces, multi-signature configurations or VRF keys

  • If the volume of Post Launch Opt Ins is large, we will process the balances that are >=100 XEM first and then treat the <100XEM balances as a backlog. We do not think this will be necessary but also cannot be certain in the early weeks what kind of volumes are to be expected so may implement a max threshold for weekly allocations to ensure they can be performed reliably and with appropriate accuracy.

Full document with the requirements, process steps and operational processes (settings should allow google translate, please let me know if they do not)

Please do let us know if there is anything in here that is wrong, needs another perspective, generates questions etc the best way to ensure this works how everyone wants it to is to have these conversations.

4 Likes
Symbol Launch Reporting & Single Source of Information
< 100 XEM balance - XYM allocation
#2

Seems ok to me, apart from the post launch delay of approx 6-8 weeks for token allocations (pay outs).
“Allowing things to stabilise” is a little vague. Also, can there be any unstabilities that cannot be anticipated then? Which ones and why? I would like this to be clarified or explained in more detail.
Thanks in advance.

2 Likes
#3

Every point looks great to me.
I’m glad the decision around the <100 XEM has been changed to allow them to at least opt-in after launch.
IMO 6-8 weeks is quite long, I would like 4 weeks and a fixed blockheight where allocations would start. And communicating the blockheight at or around launch.

3 Likes
#4

Everything is OK from my point of view, just 6 - 8 weeks of delay for token allocation is too much. It should be less I think. Or please be more specific what is the problem.

#5

Thanks for the replies above @garp @meyns and @janikjan

The delay post launch is more for non-technical (people/processes) stabilisation rather than technical stabilisation - we do not expect to be going onto public chain with any technical issues that require stabilisation (if we are in that position it will be a launch delay conversation. Sorry that wasn’t worded very clearly in the first post.

The things we are thinking about on that side are things like:

  • Until launch we can’t fully test all the operational processes (monitoring new opt-ins, governance to make sure they are legitimate, multi sig control of accounts) on the actual public chain. We will do it on the Testnet but given how important it is, it is necessary to ensure it works correctly on the public chain before trying to scale it out

  • All the teams are working extremely hard right now to keep achieve launch by the 17th, this places stress on people, causes non launch critical things to back up etc, and we want to ensure things have settled back down properly.

  • If we say 4 weeks from launch about half of that is over the Christmas/New Year window, even though we will have people available, it won’t be full, normal operations so it just gives some breathing room to ensure after people come back there is time to get fully operational in a reliable, well governed way

  • There probably be a few things which we prioritise immediately post launch, that were not launch critical but are still very important, the 6-8 weeks allows us to ensure those are all cleaned up.

What I am getting loud and clear from the above though is that 6-8 weeks is too long (and the fixed block height is also a good way to frame it). I will have chat with the tech and operations team and see what the tightest we can make that time is without any adverse impact. It will probably take me a few days just due to all the other stuff that is going on right now, I will come back on it though

3 Likes
#6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.