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
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.
Thank you. I understand.
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.
exactly, the problem is late opt-in through “legal entity”.
- opt in with address-X before reference point
- move coins to exchange after reference point
- move coins out of exchange and do late opt-in through “legal entity”
- 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?
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
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.
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
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
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?
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
Unfortunately, it’s still not clear for me. In your example:
- Who can make the reference point?
- How many reference point can be made?
- 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.
- 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.
- exactly one
- for each opt-in there has to be a check for the given address, yes. I see no way around that.
8 Likes
the actual implementation and timing with exchanges are critical. Let see how things going forward.
Everything sounds very difficult here and as it seems it is really extremely difficult such a swop or hard fork.
I just hope that it will work and not some walle get even bigger, this must not happen.
The best would be to bring the whole blockchain to a standstill and then execute the hard fork so that only 1 coin remains. of course such a procedure is not decentralized and probably also not possible but that would be the best.
A HardFork is always bad and the people are not worried if NEM 1 will be used anymore or if everyone switches to NEM Catapult.
Would now normally say let the community vote on how it should happen, but I dare to doubt that only 5-10% understand what is most correct. It seems to be very complex
Translated with www.DeepL.com/Translator
1 Like
It can still be circumvented since post-fork opt-in is possible. If I have 1000 coins and I opt-in pre-fork I get my 1000 catapult. I then send those 1000 to an exchange and sell them. I buy back 1000 which I then instruct the exchange wallet to send to some unknown new wallet. So no connection to my original wallet. I opt-in with the post-fork option, get my catapult coins. I then repeat the process.
Reread what i wrote. i don’t think it can be tricked.
3 Likes
this scheme means that all those who want to receive catapult coins should withdraw Xem from all exchangers before the block x?
1 Like
name must be NEM2 nothing else
is important name will be NEM2
1 Like
So all opt-ins have to occur before actual launch - so pre-fork? Meaning that when block height X hits all opt-ins will be recorded and no more opt-ins will be accepted after this snapshot? So all old XEM not opted-in pre-fork will never represent a catapult token post fork? So the post-fork opt-in only refers to the date/block when you will actually receive your coins? I was under the impression that opt-in could occur at any time - pre or post-fork because post-fork the committee designated for that would evaluate my request and dish out tokens.