Migration Committee Community Update #1

Catapult Migration
#30

Thanks for the update. A couple of questions:

  1. When the time to opt-in for Catapult token allocation starts, will the NIS1 XEM currency still be tradable on (major) exchanges?
    This will determine if the speculative trading market will be at risk of being gamed by big players in order to obtain more XEMs; and therefore more Catapult token allocation for them.

  2. Will there be any kind of filter for claiming the Catapult token from (known) bad addresses? E.g.: CoinCheck tagged addresses, etc.

2 Likes
#31

Good question!

#32

Great point! Could be lethal!

#33

Haha the Committee in their infinite wisdom has decided they want both tradeable. So yes XEM will dump to 0 instantly on swap then big players will probably buy the depth and get even more catapult tokens and have more power. I’ll bet someone on committee is thinking to do exactly this. Very corrupt operation we have here.

4 Likes
#34

So no community vote on such an important matter? Just a fait accompli decision from on high? How is that “decentralized” when even the biggest holders have no actual say in something like this?

So what are the audited XEM holdings of these Committee members? Is someone making decisions that might benefit them financially at the expense of everyone else? Conflicts of interest are important to disclose when such power is achieved.

4 Likes
#35

There will be block height announced that is reference point, all opt-ins will have to happen BEFORE that block height.

So in case you describe at block height X, only address-B will have balance, so address-A won’t be seeded at all.

4 Likes
#36

I totally agree! SWAP AND BURN! I actually automatically presumed this was the case, hence I asked the questions. We need a swap and burn in order to prevent tax implications and the illusion that there is uncertainty regarding the future of NEM1 compared to NEM2. I don’t think there is a conspiracy though, but hopefully Migration Committee will elaborate its views soon and take into account your considerations.

3 Likes
#37

Does that really address the problem? At block height X there will be a snapshot and only address B will be seeded on the Catapult chain with XEM; got that. However, the way this proposal is currently written seems to mean that NIS1 XEM can be opted-in at any point after the snapshot as well - that being the point so there is no rush to migrate, tax reasons etc. So in theory wallet A XEM could be seeded on Catapult at block height X and then that NIS1 XEM could be moved to another wallet which could then be seeded post-launch as well. I assume this would be a manual process though and not an automated one made upon request at this point? It still seems possible that someone could collect at least 2x.

#38

Thank you. I understand.

#39

However, the way this proposal is currently written seems to mean that NIS1 XEM can be opted-in at any point after the snapshot

I misunderstood because of same reason. I can not understand about treating any tokens that are not claimed by the Nemesis block yet.

#40

exactly, the problem is late opt-in through “legal entity”.

  1. opt in with address-X before reference point
  2. move coins to exchange after reference point
  3. move coins out of exchange and do late opt-in through “legal entity”
  4. repeat 2. and 3.

Legal entity has to accept my coins because there are other people eligible for late opt-in on that exchange and XEM token is 100% fungible.

I honestly dont see any solution for this situation that would stop pontifier from screaming “who has my coins” for years to come.

is there some?

#41

Say there is a reference height X for opt-in. When someone is making a request to opt-in for an account, only the xem that were on the account at height X will be given on the catapult side.
That is my understanding.

4 Likes
#42

Yes, that would be opt-in before Catapult launch. But after you could move your NIS1 XEM around and opt-in all over again because that will be allowed. So more Catapult XEM.

#43

It wont be allowed. Its very easy to get an accounts balance at a particular block. If acc B did not have a positive balance at block X, any xem that reach that account after block X will not entitle that account to catapult tokens.

3 Likes
#45

Example:
Reference height is X.
At height X account A has 1000 xem, account B has 100 xem and account C has 0 xem.
If you opt-in for Account A at height X and then move the xem from account A to an exchange and from there to Account C and try to opt-in for account C after catapult launch at some height X + 100000, then the commitee doing the opt-in process would look at the balance of account C at height X. Since there was 0 xem on the account at height X, there would be no xem given in the catapult chain.
If you would move the xem from account A to an exchange and from there to account B and opt-in for account B at height X + 100000, then only the 100 xem that were on account B at height X would be given in the catapult chain.

Clear now?

6 Likes
#46

it will not work with exchange account.
they have millions of xems, so i can in and out my 100k xems multiple times

Or you exclude exchanges acc from opt-in, and you need to withdraw coin first?

#48

aha ok,
so you need to save private key of adders holding xem at reference point.

This needs to be explained clearly. I still can see pontifier screaming, but it looks acceptable to me.

1 Like
#49

Unfortunately, it’s still not clear for me. In your example:

  1. Who can make the reference point?
  2. How many reference point can be made?
  3. Will the opt-in committee check ALL addresses at ALL reference points whenever an opt-in is requested?

I think we need a better example of multiple use-case scenario’s.

#50
  1. Since there is no reference height that is especially good or bad, it can be chosen arbitrarily within some reasonable interval. The migration commitee could do that for example.
  2. exactly one
  3. for each opt-in there has to be a check for the given address, yes. I see no way around that.
8 Likes
#51

the actual implementation and timing with exchanges are critical. Let see how things going forward.