The Nxt 2.0 token distribution

Details about the Nxt 2.0 token distribution have been announced.

Those who have been following  Nxt 1.0 know that the launch of Nxt 2.0 (Ardor) will be a big and important step forwards, not just for Nxt but for blockchain technology in general. With the amazing and broad set of truly disruptive, stable features already running on the Nxt 1.0 blockchain, the next leap forward will be the solving of the blockchain bloat problem inherent to all existing blockchains.

This can make Ardor the first globally scalable crypto platform, and in addition to this, Ardor will enable any individual, business and community to launch their own fully secured customised private ledgers. In short, a Nxt 2.0 Main Chain token (ARDR) will ‘forge’ (~ stake/~mine) all the childchain transactions and thereby secure them. The first and default Nxt 2.0 childchain (Ignis) to be launched with the genesis block will be a ledger which integrates all the functionality of Nxt 1.0.

Ardor’s prime innovation is to split the blockchain into a main chain that is used for consensus creation only, and multiple child chains that keep separate ledgers of transactions, each child chain using its own coin/token.

In the announcement Jean-Luc writes that:

The Nxt 1.0 branch will continue to run

Nxt 1.9 is going to be the last major release on the Nxt 1.0 branch.

Nxt 2.0 is not a fork of Nxt 1.0. NXT tokens will continue to exist.
Existing 1.0 users will be able to log in to Nxt 2.0 with their existing passphrases.

The Nxt core development team is committed to providing support for Nxt 1.x for at least one year after the Nxt 2.0 launch. Additional GUI functionality may or may not be added to the NRS Client.

The distribution of Nxt 2.0 tokens

The Core Developers recognise the tremendous contributions of the investors and holders of the original Nxt 1.0, without whom Nxt 2.0 would not be possible, and have decided to grant them exclusive rights to the new 2.0 tokens.

Ardor tokens

ALL Nxt 2.0 Main Chain tokens (ARDR) will be distributed among the holders of Nxt 1.0 tokens.

Nxt 1.9 will be announced shortly with a hard fork for the ARDR distribution without API changes.

The only way to get ARDR is by holding NXT in your account during the snapshot phase (which starts when Nxt 1.9 is released and will run for about 3 months).

Jean-Luc writes:

The Nxt Software will start taking periodic snapshots of all users’ NXT balances, at regular intervals (most likely once an hour), for a period of three months.

The NXT balances in each account will be averaged over this full three month period, and at the end all accounts will be automatically credited with a token representing their ARDR holdings, issued as an Asset on the Nxt asset exchange.

This ARDR Asset will be freely tradeable.

The distribution of the real ARDR coins will be based on the ownership of ARDR Assets taken at the point of time when the 2.0 Genesis block is created.

There will be no burning of Nxt 1.0 needed in order to receive either ARDR or [Ignis]  Tokens.

ARDR tokens will be used for forging (i.e. staking / mining) to maintain and secure the full Ardor network and incentivize people to set up nodes. Users of any Ardor childchain will have to pay bundled transaction-fees to ARDR forgers.

Riker explains:

Holding the ARDR token provides the ability to bundle many child chain transactions into a ChildChainBlock transaction on the main chain (i.e. become a bundler) and forge transactions on the main chain.

Ardor Mainnet is scheduled to launch in Q3 2017.

IGNIS; the Nxt childchain tokens

Introducing: Ignis.

As stated above, Nxt 1.x will continue to run; you will get to keep all your current NXT tokens.

The Nxt 1.x equivalent chain which will launch with the Ardor genesis, is a new Nxt ledger. Its transactional token has been dubbed Ignis. The Ignis token will be the only transactional token on the Ardor network when it launches, and until new child chains can be spawned.

Ignis tokens will be distributed ~ 50/50 to NXT holders/Nxt core development team.

The ~ 50% Ignis which are to be distributed to the core development team will be theirs to use for funding the continued development of the Nxt 2.0 platform.

Jean-Luc writes:

[Ignis] will be created in the Genesis block of Nxt 2.0. At the moment NXT holders will get 50% [Ignis] of their NXT balance. The other 50% will be reserved for the devs, for instance to do an ICO with, or something else. As this is still one year in the future, the exact method of this is still being debated.

This means, that in addition to the Main Chain tokens (ARDR), NXT 1.0 holders will be accredited a number of Ignis (Nxt 2.0 transactional tokens) equal to ~ 50% of the NXT they hold in their account when Ardor launched in Q3 2017.

As a warning to traders, Riker states that: “If you keep your NXT on a centralised exchange you’ll need to check with the exchange how they handle the ARDR/Ignis distribution since it will be distributed to the exchange account. The exchange will get the ARDR / Ignis tokens and will decide what to do with it”.

Our best advice would be for you to keep your NXT in your own Nxt account with your own passphrase.

Nxt Developers – feel safe to code with Nxt

Nxt has had issues with breaking backwards compatibility when preparing for the switch to Nxt 2.0 / Ardor.

Nxt 1.10.x API will NOT be changed, so developers working with the Nxt 1.10.x API can feel safe that their code will keep working on the 1.0 branch and that they can easily port their new or existing Nxt projects to the new Nxt 2.0 ledger, if they want to do so after it has been launched. The Nxt core development team is very willing to offer their help in that regard, in case it should be necessary.

One exception to the backwards compatibility-rule is, as announced on release, the Nxt add-ons feature (available for developers from Nxt 1.8.0e), as this will “undergo significant refactoring in 2.0”.

Use it to test, play with it, but like Jean Luc writes: “Keep any custom add-on code simple, and be prepared to have to change it for 2.0 or discard it”.

You can follow the Nxt development in nxtforum.org/, and if you’re in doubt about anything, ask the core developers.

Nxt 2.0 design

Nxt NRS has been successfully hard forked and updated to NRS 1.7.5, with new amazing core features added, such as stable 1 minute transaction times, Singleton Assets, Coin Shuffling, Account Control for phased transactions, and Data Cloud. Everything is running stable and smoothly, and the Nxt core developers have started brainstorming Nxt NRS 2.0.

2.0 is mainly about scalability. The idea is to spawn side-chains from the main blockchain.

Lead developer Jean-Luc writes:

We have been brainstorming the Nxt 2.0 design for some time now, and here is our current proposal. This is a high level summary, and many details are not yet known, more specific design decisions will be made as the development moves along. What we propose is a significant architectural change, not just a bundle of features. And it will take us some time to get there.

– A new main chain will be created, on which NXT becomes a token used for forging only, “forgingNXT”. The current NXT ecosystem will become a child chain, preserving all features and holdings except the ability to forge. At the hard fork block, each NXT owner will have his NXT converted to both tokens in 1:1 ratio, and all other holdings migrated to the NXT child chain.

– It will always be possible to exchange NXT to fNXT, so small stakeholders not interested in forging may decide to sell their fNXT to large stakeholders running forging nodes. This would lead to some centralization, but also to a higher percentage of the (f)NXT stakeholders forging and thus securing the complete Nxt ecosystem.

– Child chains will all run the same code, but each one can be configured to have only a subset of the all possible features if needed. The NXT child chain will have all possible transaction types enabled.

– Each child chain will have its own native token/currency, in which payment transactions are denominated, asset ask/bid orders are placed, digital goods are priced, etc. Child chain transaction fees will also be in the native token.

– All transactions from all chains must be processed by all nodes. All nodes will carry all child chains for the last 1440 blocks at least. Archival nodes can opt to store one or more child chains longer, or indefinitely.

– Transactions on the child chains will be pruned completely after 1440 blocks on nodes not configured to archive them longer. A new node downloading the blockchain from scratch must make the assumption that since the forgers and all nodes that were running the blockchain at the time the prunable data was still there approved those transactions, they must have been valid at that time, even though the data to validate them again is no longer available.

– It must be possible to validate though that the effective fNXT balances of the forgers were indeed those that they claim to be. This is why transactions on the forging chain which change fNXT balances cannot be pruned, and must be kept to a minimum of essential transaction types.

– The child chain “blocks” will be implemented as a prunable attachment of a single (one per block per chain) transaction, of type ChildchainBlock, on the main chain. Anyone can create a ChildchainBlock transaction. However, it is up to the forgers that create blocks on the main chain to decide whether to include this ChildchainBlock transaction in a block. Forgers, just like all nodes, do full validation of all child chain transactions included in a ChildchainBlock, as long as the data has not been pruned yet.

– If there have been no transactions on a chain, there is no need to create a ChildchainBlock transaction for it, unlike the main chain where we continue to have blocks every 60s even if they are empty. We can think about reducing the main chain block times in order to allow for some child chains to have more frequent blocks.

– The forgers will accept fees in fNXT only, with the minimum fee required by the protocol for each transaction type also denominated in fNXT.

– When a ChildchainBlock transaction is included by a forger in the main chain, its creator pays a fee in fNXT to the forger. The amount of this fee is up to the ChildchainBlock creator, but must be at least equal to the total of minimum fees calculated in fNXT for each child chain transaction included. In return, the ChildchainBlock creator receives the fees, in native child chain token, paid by the senders of those child chain transactions.

– The exchange rate of child chain token to fNXT will therefore be determined by market forces. If no-one is willing to include a child chain transaction in a ChildchainBlock, it would mean that the fee offered in native token is not considered equivalent to the required minimum fNXT fee for this particular transaction, and such transaction will expire unconfirmed. If the value of the child chain native token drops to zero, no-one will be willing to create ChildchainBlocks for it, and transaction processing on this childchain will stop.

– Child chains will compete with each other for inclusion into a block, since at the end the forgers will still look at the fee/size ratio for each transaction and will want to maximize their forging profits, subject to main chain block size and transaction numbers limits.

– Before the pruning, each node must verify not only that the hash of the ChildchainBlock transaction matches, but that all transactions of the child chain enclosed within it are valid, i.e. there is no double spending, and all other validations. For that the node needs to know the current balances for all account holdings, on that child chain. To be able to still do pruning, we need a snapshot transaction, which takes a snapshot of the current child chain state only, without any history that led to this state. Then, after this transaction has been accepted in the blockchain for more than 720 blocks, we can assume that it is valid, prune all history for that chain before that snapshot, and discard the previous snapshot.

– The snapshot transaction for each child chain is created at regular intervals, such as 1440 blocks, by the forger of the current block. It will only contain the hash of the snapshot, not the full snapshot data.

– The snapshot data itself does not need to propagate through the network when the snapshot transaction is created. Each node that already is up to date, already has the state of the child chain being snapshotted, so it can generate such a snapshot for itself. It must only validate that the hash the forger calculated for the snapshot indeed matches its own snapshot.

– It is only nodes that are downloading the blockchain from scratch that would need to download the latest complete snapshot, and this is another reason that each node must generate and keep around this snapshot, to be able to serve it to such new nodes. The snapshot download can be in a torrent-like manner, different pieces from multiple nodes.

– Because every up-to-date node needs to validate all current transactions, even though we significantly reduce the long term blockchain bloat problem in terms of disk space used, and bandwith to download the blockchain from scratch, there will still be a bottleneck in terms of CPU for processing data on all chains, and the bandwith of having to receive and process current transactions for all chains. But since nodes don’t need to validate past child chain transactions that have already been pruned, overall downloading the blockchain from scratch should be faster and less CPU intensive.

– The forging chain which all nodes share guarantees security, even for child chains that don’t have many users and have transactions only occassionally. In return, each of the child chains gets the ability to be pruned. Child chains no longer need to keep all their old data going back to genesis in order to be secure, because they do not forge.

– As a first step, we will start with just the forging main chain, and the NXT chain as a single child chain to it, and perhaps a test child chain. Once we have this working, we implement the features required to be able to dynamically create a new child chain, or edit the properties of existing child chains.

Originally posted on Nxtforum.org.

Author: Jean-Luc. Join the discussion here: