IGNIS ICO Report 1

The long awaited crowd sale of the IGNIS token has begun.

For sale are 440,000,000 Jelurida tokens (JLRDA) out of 1,000,000,000 total.

The Nxtchat.slack has been buzzing for weeks with anticipation and discussions of how to get your hands on these JLRDA tokens and this article contains some important information pertinent to your investing decisions.

1st round sold out in a flash


Live data from the Nxt blockchain

IGNIS logo

Boom – first round is over…

Eager participants from all around the globe were ready, eagerly staring at their desktop clients with the ICO window open in their NRS Client, excitedly building tension in Slack, ready to purchase.

And then…

The shock – as everyone realized that the first ICO round was over even before Jelurida’s exchange offer had hit the client GUI! The first 5M JLRDA tokens had been sucked up by a single whale in a flash.

1% of the JLRDA tokens available in the ICO had been sold without anyone even seeing the offer let alone having a chance to place their orders in the client!

What happened?

Take a look at the whale’s account.

https://nxtportal.org/accounts/11731960900805566730

Lots of phased transactions. Buy offers put into every block within the announced time frame of the first round, just waiting for his approval to be executed.

But how could he react so fast? One sound theory is that the buyer had a bot listening to the network and as soon as the exchange offer was put by Jelurida, still unconfirmed, he executed the transaction in that same block.

First reactions were harsh. From emotional accusations from disappointed users that the ICO round had to be an “inside job”, to conspiracy theories and sad claims that all IGNIS tokens most certainly would be sucked up by rich investors only, “just like in the fiat world”, hit the world wide web by storm.

And now, few hours before the next batch of 5M JLRDA tokens are to be released, we can only wait and prepare for our second chance to get in. No, “MAAC” did not play it fair in Round 1 but after all, he played it well AND played everybody by the rules of the tech. Rules that can be dug into by everybody, by the way.

Here’s a statement he made, sent from his phasing account:

Jelurida has released a schedule of the availability of the batches for the first round of JLRDA. 55 M tokens are left in 11 bins of 5 M, staggered by 12 hours to make it harder for whales (people with massive amounts of NXT) like MAAC to buy the entire amount.

The release schedule is as posted from Jelurida:

Aug 5th between 06:45 – 07:15 UTC and between 18:45 – 19:15 UTC
Aug 6th between 06:45 – 07:15 UTC and between 18:45 – 19:15 UTC
Aug 7th between 06:45 – 07:15 UTC and between 18:45 – 19:15 UTC
Aug 8th between 06:45 – 07:15 UTC and between 18:45 – 19:15 UTC
Aug 9th between 06:45 – 07:15 UTC and between 18:45 – 19:15 UTC
Aug 10th between 06:45 – 07:15 UTC and between 18:45 – 19:15 UTC

In the coming hours and days, we will keep you posted about the progress of the ICO, as well as explain in much greater detail about IGNIS, Ardor, and all the advantages of this revolutionary new platform.

The coin sale will last for months so do not worry if you are not able to participate immediately, there will be many opportunities to participate.

Let’s see what happens. Meanwhile, the discussion is ongoing:
https://nxtforum.org/general-discussion/ignis-token-sale-progress/

In addition to the ongoing ICO, approximately half of the IGNIS coins in existence will be distributed automatically to NXT holders based on their account balances at the time of the Ardor Genesis Snapshot, at 1 NXT = 0.5 IGNIS ratio.

IGNIS ICO Report 2 >

Ardor v2.0.0e

Ardor v2.0.0e

THIS IS AN OLD RELEASE. FOR THE LATEST NRS VERSION CHECK HERE

Not available yet

Digital signature: "Stichting NXT"

.sh Sha256: 32ed1df94300275cf8aac9966a3f26bc6cf607c646fda54f7966953cab9aa882  ardor-client-2.0.0e.sh

Release 2.0.0e: https://bitbucket.org/JeanLucPicard/ardor/downloads/ardor-client-2.0.0e.zip

2.0.0e .zip sha256:b814ec631d37e2afc1319a458525d1cfd61c583f61f1d77d8312bc7249131711  ardor-client-2.0.0e.zip

Ardor testnet is here

Ardor 2.0.0e is the first public release of the Ardor testnet.

Read more about the launch in this post.

Learn more about the Ardor platform from www.ardorplatform.org.

ARDR assets representing real Ardor tokens are traded on exchanges.

 

Release notes

This is the first release of the Ardor software, for testnet only. It represents the first milestone in the building of the Ardor platform.

New Features

The main new user-visible feature is the existence of a single forging chain, using the ARDR token, and multiple child chains, each with its own token.

Forging Chain

The Ardor chain is used to establish the proof-of-stake consensus, using ARDR balances only. It supports only a few transaction types: ordinary payments, balance leasing, and coin exchange. Prunable plain or encrypted message attachments are also supported, but not permanent or standalone arbitrary message transactions.

Child Chains

The child chains support all transaction types as previously implemented on the Nxt platform, with the exception of balance leasing which is only available on the Ardor chain, and tagged data extend transaction which has been removed as unnecessary. A child chain can optionally be configured to disable certain transaction types, which has been done for testing purposes on the EUR child chain, disabling the Asset Exchange and Digital Marketplace.

Coin Exchange

To allow trading of child chain coins to each other, and also between child chains and the Ardor chain, a new Coin Exchange module has been implemented.

For trading between child chain coins, the coin exchange transactions are submitted on the child chain of the coin being sold. For trading between a child chain coin and Ardor, the transaction is submitted on the Ardor chain regardless of whether it is a buy or sell, and the fees for such transactions are higher.

Bundling

The bundling process is used to group child chain transactions from a child chain into a transaction on the Ardor chain. Bundlers accept the fees from those child chain transactions, in the corresponding child chain coin, and pay fees in ARDR to the parent chain forgers. Bundlers can be started from the cogwheel/bundlers menu, defining the coin to ARDR exchange rate they accept, a limit on the total fees in ARDR a bundler will pay, and an optional overpay amount.

When a bundler is running, it checks the unconfirmed transactions pool every time a new transaction from the child chain being bundled arrives. If the transaction fee included by the transaction sender, in child chain coins, when converted to Ardor using the exchange rate accepted by the bundler is at least equal to the minimum Ardor fee required for this transaction, the bundler will generate a ChildBlock transaction, including in it this and all other currently unconfirmed child chain transactions satisfying this requirement.

The Ardor fee the bundler will include for the ChildBlock transaction is equal to the sum of the minimum required Ardor fees for each, plus the calculated overpay amount, if any. Such overpay amount is optional, and may be used by bundlers willing to pay more in order to have their transactions included in block instead of those of competing bundlers.

The new ChildBlock transaction will displace from the unconfirmed pool any ChildBlock transactions of the same child chain that include only a subset of the same child transactions.

When propagating through the network, ChildBlock transactions will only be accepted by peers if they either include child transactions not already included in other ChildBlock transactions the peer already has in its pool, or offer to pay a higher fee for the same transactions. This ensures the network is not flooded with ChildBlock transactions even if every node is running a bundler, and allows bundlers to compete for propagating their transactions through the network by offering to pay higher fees.

It is now possible for child transactions to be submitted with zero fees, in child chain coins. If a bundler is willing to pay the Ardor fees for those, they will be included in the blockchain in the ChildBlock created by such bundler.

To prevent the unconfirmed pool from being overfilled with such zero-fees child chain transactions, once the maxUnconfirmedTransactions limit (configured in nxt.properties, default 2000) has been exceeded, child chain transactions will be dropped unless a bundler has already submitted a ChildBlock transaction which includes them.

Bundlers advertise their accepted bundling rates to other peers, signing such rates announcements with the private key of the bundler's account. To prevent fake rates announcements, they can be filtered based on this account effective balance (default set in nxt.minBundlerBalanceFXT is 1000 ARDR).

The GetBundlerRates API can be used to retrieve known bundlers rates, again with optional filtering by minimum bundler effective balance.

Peer Networking

The peer networking has been fully re-written and optimized to use socket connections and binary messages instead of http and JSON.

Block and transaction propagation through the network has been optimized, by sharing with peers the inventory of transaction IDs in the unconfirmed pool or in recent blocks, and only propagating the missing ones, if any, when a new block is generated, or a child block is bundled.

The hallmark feature has been removed as it is not needed anymore, hallmarks are no longer supported.

New APIs

APIs of the new Coin Exchange feature:
ExchangeCoins, CancelCoinExchange, GetCoinExchangeOrder, GetCoinExchangeOrders,
GetCoinExchangeOrderIds, GetCoinExchangeTrade, GetCoinExchangeTrades,
GetExpectedCoinExchangeOrderCancellations, GetExpectedCoinExchangeOrders,
GetLastCoinExchangeTrade.

Bundling related APIs:
BundleTransactions, GetBundlers, GetBundlerRates, StartBundler, StopBundler.

Other new APIs:
GetBalances, GetEffectiveBalance, GetFxtTransaction.

API changes

All APIs that are now chain specific accept a new chain parameter. Either the chain name or the chain ID can be used.

Transaction IDs are no longer 64-bit longs but 256-bit hashes, necessitating changes in all APIs that accept transaction ID parameters or return such in the JSON fields. For transactions on the Ardor chain, 64-bit long IDs can still be used with the getFxtTransaction API, as those are enforced to be unique. For child chain transactions, the getTransaction API now requires a fullHash parameter, in addition to specifying the chain.

Prices and rates are now defined relative to a whole unit of the holding being bought or sold (asset, currency, coin), not to a QNT indivisible unit.

All priceNQT and rateNQT parameters and JSON fields have been renamed where appropriate to priceNQTPerCoin, priceNQTPerShare, rateNQTPerUnit, etc., to reflect their changed meaning of price per whole unit of each holding rather than per QNT.

All "units" parameters in the Monetary System APIs have been renamed to unitsQNT.

DividendPayment API accepts holding and holdingType parameters to allow paying dividends in another asset or MS currency. The amountNQTPerQNT parameter has been renamed to amountNQTPerShare and now refers to dividend amount in NQT per
a whole share of the asset rather than per QNT.

The GetAccount API no longer returns balanceNQT and unconfirmedBalanceNQT, as balances are now chain specific. The GetBalance API should be used to get chain balances instead, or GetBalances for querying multiple chains.

APIs which accept holding and holdingType parameters now require holding to be set to the chain ID when holdingType=0 (coin).

Since 0 is now a valid fee value for child chains, all CreateTransaction APIs will accept it, instead of using it as a request for the server to calculate and use the minimum fee. To let the server calculate the child transaction fee, a value of feeNQT=-1 should be used, and a new feeRateNQTPerFXT parameter must be supplied, to indicate the exchange rate to use when calculating the fee (since minimum fees can only be calculated in ARDR). If feeRateNQTPerFXT is also set to -1, the server will query the currently known bundlers rates for this child chain, also subject to the minBundlerBalanceFXT limit on effective bundler account balance, and use the best one for the fee calculation. As bundlers rates cannot be trusted blindly, the transaction will not be broadcasted in this case, the returned transaction JSON including the fees calculated should be reviewed by the user. The bundler rate used will be returned in the bundlerRateNQTPerFXT JSON field, -1 if no bundlers are known for the chain.

The following APIs have been removed: ExtendTaggedData, GetPhasingPolls, GetTaggedDataExtendTransactions, GetInboundPeers, MarkHost, DecodeHallmark.

Transaction types and bytes format

The numbering of some transaction types has changed, due to the internal reorganizations of the TransactionType classes. Transaction types on the Ardor chain use negative numbers, e.g. -1 for ChildChainBlock, -2 for Ardor ordinary payment. Some transaction subtypes have been moved to a separate type, e.g. voting and phasing related transactions have been moved out of Messaging to a new Voting transaction type. The output of getConstants should be consulted for a full list of the current transaction types and subtypes.

The transaction bytes format has also changed, adding a chain ID, reorganizing the ordering of attachment and appendix bytes, and allowing prunable attachment parts to also optionally be represented in the bytes format, for the purpose of sending them more efficiently over the peer to peer network.

The JSON transaction representation is still supported, even though it is no longer used in the peer networking. Some attachment fields have been renamed for consistency with the API changes - units to unitsQNT, priceNQT to priceNQTPerShare, rateNQT to rateNQTPerUnit, amountNQT for dividend payments to amountNQTPerShare, etc.

Entity IDs

As part of designing child chain transactions to be prunable, it is no longer possible to enforce uniqueness of the 64-bit transaction IDs for child chains. This affects the IDs of derived entities such as Assets, MS Currencies, Polls, Digital Goods, Shufflings, etc.

For global derived entities such as Assets or Currencies, the 64-bit long IDs are still unique and used in the corresponding APIs. Note however that this uniqueness is now only within the same object type, i.e. it is not guaranteed that an Asset and a Currency will not happen to have the same 64-bit long ID.

For child chain local entities, such as Polls and Digital Goods, the 64-bit IDs are still unique, but within the same child chain only, and still used in their APIs. Again, there is no uniqueness guarantee across different entity types anymore.

For entities that are prunable, such as prunable messages, tagged data, and shufflings, the full 256-bit hash must be used as an ID now, and the appropriate APIs have been changed.

Phasing and Account control

Only child chain transactions can be phased. Therefore, when account control is set for an account, it can no longer submit Ardor chain transactions.

Phasing parameters which refer to transaction IDs must now use transaction full hashes instead, prefixed with the chain ID separated with ':'. It is possible to refer to transactions on other chains when approving a phased transaction, or setting up a by-transaction phasing voting model.

The controlMaxFees parameter when setting mandatory approval now accepts multiple values, each fee being prefixed with the child chain ID and ':', to indicate which child chain the limit applies to. If no max fee has been set for a child chain, there is no phasing transactions fees total limit on it for the controlled account.

Transaction selection, sorting, limits and fees

An Ardor chain block can contain up to 10 (ten) transactions, this including both native Ardor transactions and ChildBlock transactions. There is no total payload size limit.

A ChildBlock can contain up to 100 (one hundred) child transactions, subject to a total payload limit of 128 kbytes. Prunable child transaction parts are also counted towards the payload size limit.

There is a limit of one ChildBlock per Ardor block for each child chain.

As in Nxt, it is up to a block forger which transactions to include in a block and how to sort them. The default forger behaviour is to select transactions ordered by Ardor fee (not fee per byte as in Nxt, since there is no block payload limit), and then sort them based on arrival timestamp.

It is also up to the ChildBlock bundler which child transactions to include in a ChildBlock, and this selection can be customized by defining a custom filter in the nxt.bundlingFilter property. The default bundler behaviour is to select child transactions ordered by fee per byte, up to the count and payload limits of a child block, creating several child blocks if necessary. Within a child block, child transactions are sorted based on their full hash, but executed based on sorting them after adding the block hash to the child transaction hash, i.e. the execution order of child transactions within a block is deterministic but not predictable and not controllable by the bundler or by the forger. This is in order to prevent front-running of asset exchange and other trading orders.

Ardor fees from ChildBlock transactions paid to the block forger are shared with the previous three block forgers in 1:1:1:1 ratio. Other Ardor chain fees are fully kept by the block forger, and child block transaction fees (in child chain coins) are fully kept by the ChildBlock bundler.

The back fees sharing which was applied in Nxt for some other transactions types such as currency or asset issuance has been removed, however the limitations of one such transaction per block for scarce blockchain resources are preserved.

Default fee for Ardor chain transactions is 10 ARDR. Default fee for child chain transactions is 0.1 ARDR. A ChildBlock must contain at least one child chain transaction, but there is no minimum ChildBlock fee requirement, i.e. such a ChildBlock with a single transaction in it would require only 0.1 ARDR fee if this is the minimum fee for the child transaction it contains.

Fees for child chain transaction types have been scaled depending on their impact on the blockchain, e.g. asset issuance fees are still 1000 ARDR as assets are global and kept permanently. There is a 1 ARDR extra fee added to transactions that create a new account.

The above fees and limits are set for the current testnet only and are subject to change before the production mainnet release.

Testnet accounts

The testnet genesis block has been created based on account balances from the Nxt testnet, as of 2017/01/01 (block height 1061208). Users who had testnet accounts as of that height should find their ARDR and NXT testnet balances imported into this testnet, to ARDR and IGNIS tokens respectively, plus an approximately equivalent amount of BTC, USD, and EUR child chain coins for testing. To allow for developers testing and running forging and bundling nodes, account holdings have been reduced by 50% which have been allocated to developers accounts.

Upgrading from Nxt

The Ardor release is not an upgrade and does not in any way affect your existing Nxt account or client installation. Both Ardor and Nxt should be possible to run simultaneously on the same machine, as long as the hardware capacity allows it.

The included ArdorNxtComparison.pdf document summarizes the major differences between the Nxt and Ardor platforms, for those deciding which one is a better fit for their use case, or considering a migration from Nxt to Ardor. More documentation should be added as Ardor development and features mature and stabilize.

Source: https://nxtforum.org/nrs-releases/ardor-v2-0-0e/

Also see: Nxt 2.0: Ardor childchain blockchain platform

Nxt announces: ‘ARDOR’

Nxt-announces-ardor

ARDOR is brought to you by the core development team from Nxt. After years of building and testing the Nxt platform, the team is going to involve the public even more. As the first Blockchain 2.0 platform, the community has continually improved Nxt and now looks forward to release Ardor for companies, organizations, and of course, users.

ar•dor(ˈɑr dər) 
n.

1. great warmth of feeling; fervor.
2. intense devotion; zeal.
3. burning heat.

Also,esp. Brit., ar′dour.

The Nxt core dev team is letting anyone get into the blockchain space with a new child chain platform, ARDOR, which will incorporate the technologies proven for years by the Nxt 1.0 cryptocurrency and blockchain. Soon, anyone will be able to create their own solutions using the blockchain technology with the Ardor child chains.

Nxt is undergoing a dramatic evolution. Research by the Nxt team has led to Ardor, a platform that uses child chains and incorporates all of Nxt’s latest blockchain innovations while being backed by the core developers of Nxt. Ardor is more than just about money: It’s about making a blockchain platform that is open to everyone, from single users all the way up to FinTech startups and governments, and one where anyone can create their own child chain and interact with the whole blockchain ecosystem. That means anyone, anywhere, will be able to utilize blockchain services with relative ease.

We can’t give away too much until the final features of Ardor are tested repeatedly.

A few of the features coming with the new Ardor release:

Blockchain as a Service

Ardor will open blockchain development to organizations and individuals across the world. The high barriers to getting started with blockchain are about to vanish.

Manageable Blockchain Size

Ardor will solve the problem of scalability by separating transactions and data that do not affect security from those that do, and moving all of those that don’t affect security onto child chains. The Ardor team will create the first child chain to house many Nxt 1.0 tools as well as future features. This small size also comes with short transaction times so processes need only a fraction of time compared to Bitcoin to execute functions.

A Decentralized Asset Exchange

Building off of the Asset Exchange on Nxt, Ardor will enable the ability to trade assets on any child chain for any of the child chain tokens. This allows child chains to interact with each other and opens up numerous opportunities for collaboration as well as allow cross chain asset trading, a long-requested feature within the Nxt ecosystem.

Decentralized Voting and Governance Systems

Ardor will be at the core of decentralized consensus in the future. Secure and anonymous voting will be an available feature on all child chains as it is on the Nxt platform.

Phased Transactions

Users can set multiple conditions before a transaction is executed, such as a minimum number of votes and a set amount of time. Like Nxt, Ardor will use Smart Transactions. With this, users will only need to submit the parameters necessary for the transaction and the ID of the functionality they want to use. The transaction process is also completely decentralized. No centralized server, service, or application, like Ethereum’s Oracle, is needed.

“Rather than providing smart contracts, NXT is focused on implementing the important use cases and functions directly into the core of both Nxt and Ardor. This approach has proven to be scalable and secure and will become more so when Ardor is released” – Riker

These are a few of the things Ardor will give you and the cryptocurrency community. As development continues and testing is finalized, you’ll get a detailed analysis of each of the new tools, as well as the core features built into Ardor. We’ll also reveal, step-by-step, a list of our partners and what they’re doing with our technology.

This is all possible because of new developments within the Nxt community. Decision-making and planning is becoming more professionalized. The community and team structure are adjusting to the new demands while the Nxt and Ardor technology remains entirely open source. Ardor is more than a cryptocurrency – it’s a blockchain platform specifically designed to let anyone build decentralized tools with the latest innovations in blockchain technology.

How to get Ardor

You’ll be able to participate in Ardor right away. As Ardor continues testing and development, Nxt 1.9 will be released. With Nxt 1.9, you’ll get your first chance to own a piece of Ardor. All those who hold an amount of NXT will also get a piece of Ardor. Snapshots will start be taken on an hourly basis, starting on July 14th to October 12th. Then, your total NXT will be averaged, and you’ll receive that amount in Ardor tokens on October 12th, which will be freely tradeable up until the Ardor system launches.

At block 1,000,000 on October 12th, 2016, snapshotting will stop, and you’ll be allowed to trade your Ardor tokens in NXT 1.9 in preparation for the launch of the Ardor blockchain.

After Ardor has launched, Nxt 1.0 will remain active and supported. Nxt 1.0 is the giant on which Ardor is built and it will remain running as a core component of the Nxt eco-system, functioning as a complete blockchain solution in its own right, as well as assisting in the development and refinement of the Ardor blockchain platform.

There’ll be a lot more news in the weeks and months to come. Ardor aims to be a powerful platform for users and businesses alike by building on the technology pioneered by Bitcoin and Nxt. If you would like to be a part of it, acquire NXT now and get your stake in ARDOR!

Source: https://nxtforum.org/core-development-announcements/(ann)-ardor-or-nxt-2-0-a-scalable-child-chain-platform/

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 – should investors and asset issuers be afraid? [video]

Here’s some great listening for you – Nxt core developer Riker chatting about Nxt, other cryptos and investing with Marc De Mesel, an investor who has 35% of his investments in NXT.

Marc wants to learn about Nxt’s anonymous lead developer Jean Luc, about where Nxt is now, compared to Ethereum and other blockchain ‘competitors’, and also about the recently proposed changes to the Nxt protocol (the NXT 2.0 proposal).

Riker explains how Nxt 2.0 aims to solve the blockchain bloat problem and make Nxt the first ever globally scalable crypto platform.

Also: how Nxt, if version 2.0 were to proceed, would become a sidechain and how, with version 2.x, more sidechains could be added. Instead of implementing Some Asset < > Some Asset trading, Nxt 2.0 would make all Nxt AE assets tradeable across all sidechains, globally.

Having a sidechain pegged to a fiat value, and other sidechains pegged to crypto coins like Bitcoin, Nxt assets would become tradeable on several new markets thereby, in effect, creating a fully decentralised, multi currency, low fee, globally scalable asset market, powered by Nxt AE.

[youtube id=”tN4FjZ-31uk” width=”600″ autoplay=“no”]

Nothing is yet set in stone, but as the Nxt 2.0 design has been discussed and refined for at least 6 months already among the Nxt core developers, there is every indication that Nxt 2.0 in its essence will be programmed as proposed, with all the remaining details hammered out in cooperation with the users, the active Nxt Community.

Riker mentions how Nxt 2.x could also be of benefit to companies, a user category which has shown a lot of interest in the Nxt Monetary System (MS) but been reluctant to use it because of the current need for users to pay transaction fees in NXT.

Now, with Nxt 2.0, they would be able to launch fully secured sidechains with Nxt features but without the sidechain users having to buy NXT to use it. As an example, Nxt MS tokens could be used as concert tickets, and only the business running the sidechain would have to pay fees to the Nxt main chain forgers.

Another obvious use case, via the Nxt MS’s crowdfunding feature,  would be to run crowdfunding campaigns in the sidechain currencies, such as fiat or Bitcoin.

Some organisations would probably want their own private blockchains, and ask the Nxt core developers for their help. But would any such private work which the Nxt core devs might get paid to do ever benefit the Nxt investor? Should we be looking for companies which would be willing to pay for the core development of the open sourced Nxt? Or would such companies get too much power over development?

Also read: Jelurida Q&A; Nxt core devs mean business

Is there a risk that, if Nxt became a sidechain with Nxt 2.0, the value of NXT would CRASH bringing down with it all AE asset prices, as some people have been claiming in the ongoing discussion regarding the design proposal? If so, should AE asset issuers and asset investors run away from the Nxt blockchain asap?

You’ll have to decide for yourself, of course. The crypto market is volatile and unpredictable, so who can really tell.

Lots of noise on this video, lots of good information too.
Thanks to Marc and Riker for doing this interview in Amsterdam.

Discuss the Nxt 2.0 design proposal in Nxtforum

To follow Marc De Mesel on Youtube, you can subscribe to his channel.

arc-de-mesel-nxt-blockchain