1. QUESTION: Hi, why no mosaics moved to NIS2? What about the mosaic-based projects? XEM is a mosaic - so why devs refuse other mosaics redistribution?
ANSWER: In order to not rush partners and require them to upgrade their software stacks, it is best to allow a per-case migration of mosaics. Mosaic-based projects will be provided a tool to migrate mosaics - and potentially other data - from NIS over to Catapult. Additionally, mosaics on NIS - other than XEM - do not permit historical data queries making it more complicated to snapshot balances. We are migrating root namespaces (via opt-in) to ensure no ability to migrate mosaics is lost by those who already hold the namespace.
2. QUESTION: How can you prevent a Sybil Attack without burn?
- opt-in with address-A
- send XEM to address-B from address-A
- opt-in with address-B
ANSWER: Yes, it is prevented. The amount of Catapult tokens a holder is allocated at Catapult launch is the balance from the account that was opted in at a specific block height. In the example above, the tokens were either in account A or account B at that block, not both, so only one account will receive the tokens.
3. QUESTION: Will the new network be open source?
ANSWER: Catapult already is open source: https://github.com/nemtech
4. QUESTION: Why can XPX do a swap and we can't?
ANSWER: They have a completely different ecosystem and feature-wise it is not the same as the new Catapult network.
5. QUESTION: Will Catapult XEM have Trezor support?
ANSWER: Yes, Foundation is working on Trezor support now.
6. QUESTION: I just worry about the migration, what happens to hard wallet XEMs?
ANSWER: Nothing changes. Hard wallet XEMS will not be affected.
7. QUESTION: So, if you don't opt-in before catapult launch you lose everything?
ANSWER: No. You can opt-in post-launch. The cut-off date has not been decided but it will be a reasonable timeframe.
8. QUESTION: Will mosaics tokens migrate to the new network? How will the mosaic project owners be informed?
ANSWER: No. There are technical challenges with migrating everything; we bring over data that isn’t needed (bloat), in some cases automatic migration to the new network where people don’t want it and complicates the XEM migration; what to do with an account that doesn’t opt-in and holds a mosaic that does for example (or the reverse), ownership of the mosaics at creation and a few more. Tooling will be developed that simplifies the migration of them post-launch, root namespaces are being migrated optionally because that stops squatting which allows for recreation and distribution of sub-namespaces/mosaics when the owner is ready to migrate.
9. QUESTION: May you ask a dev why you are not creating one legacy block within the old chain, cut the data before and therefore you could simply go with the old chains legacy block as a starting point? I don't see the reason for a second chain tbh. Technically it's not difficult.
ANSWER: A proper seamless migration should only concern Supernode users having to upgrade from the NIS daemon to a Catapult daemon and nothing else. This could be done by writing a wrapper/proxy layer on the Catapult daemon to support the NIS API and network protocol.
Supernode users then upgrade from NIS to Catapult before a specific block height/date or forfeit the centrally issued supernode reward. Providing this economic incentive is enough to get an upgrade of 51+% of supernodes (it has to date with NIS upgrades) the majority can then blacklist network communications with the old NIS supernodes.
This method of providing a NIS network/API proxy through Catapult means you don’t need to worry about upgrading the entire eco-system as old wallets and applications would continue to work through the Proxy layer handled by the Catapult daemon.