NEM - 100% new code. Easy APIs. Integration with Bank and over 5000 Business

  • Nem Release Nano Wallet v 1.4.13


    • Allow sub-namespaces and mosaic names to start with a number
    • Fix secondary accounts: In occasional cases, secondary accounts private keys can start with '00' but BIP32 was omitting it, giving a 62 characters private key. Those secondary accounts will fail to send anything out even if password is valid (but recoverable).
    • Update languages


    Cross-platform: 7121e96fe105c76b8475bb55b7206a0377c4a864129f1c4da780e4120b9ed58e Linux64: ad847eb23c28c0015f14352d790ee5f9bddab3dfd0afd18be9bce71c66b6dafa Osx64: 5ad6572a60e3f9ee473767d784387fd3cb2881ed7ae29650702e7cce7b00a1f4 Win64: 55a4eb5582cb7fd5c09faad73f8aecada6b79591e5b42aa39484e9c941d2d753


  • Status of the NEM Library Project

    We would like to make an announcement on the project that was proposed by Aleix and Guillem on the NEM Library earlier on, seeking funding from the community fund to the tune of 1 million XEM.

    The response from the community has been a resounding yes, for the project to go ahead. The core team has done some deliberation on it and they are of the opinion that both Aleix and Guillem’s contribution and work are valuable for the greater NEM, and that they should be considered for permanent employment by the foundation instead.

    We have decided that the community should only fund them for the work they have done to date (i.e., 600K XEM) and have them paid by the foundation from there on as employees.

    Both Aleix and Guillem have gracefully accepted our alternative offer. To that end, they are now employed under Foundation as part of our plan to expand and recruit more programmers.

    Catapult is more or less completed for its beta release, but the project is huge. As you can imagine, it took us 15 months to release NEM version 1. But the Catapult is already taking 20 months now. Further, the design of the Catapult is based on knowledge already known to the NEM developers during its first iteration. Obviously, a lot more design work has been put in place to make the Catapult a better project.

    Both Aleix and Guillem were drawn into the project immediately to help expedite and hasten its completion. Their involvement was to work on the APIs so that they can be documented, tested, and expanded.

    Aleix and Guillem have reviewed on the catapult features, ideas and concepts. They have been working on the NIS2-API (i.e., Catapult API) and have been testing them. Lots of hours have been spent on finding ways to automate the generation of SDKs for different programming languages. We must report that they seemed to have found a good architecture for this automated generation of SDKs.

    These include:

    Creating API generator routes and models. Implementing integration tests for all endpoints to validate correct behaviour of APIs. Coming out with a solution to test different serialization libraries to build transactions. Verifying these serializations by creating end to end testing for all transactions implemented in the Catapult.

    More work is still required. These will include:

    Generating a shippable nem-javascript-sdk adding websocket support and other features. Generating SDKs in other languages. Exploring options for a complementary GraphQL API End to end blackbox testing

    Jaguar0625, our lead programmer has been very pleased with their progress thus far. With additional help, it is hoped that the Catapult can be completed earlier.

  • NEM (XEM) Release v0.6.93

    Merge branch 'testnet2'


  • NEM Hot/Cold Wallet: The First Ever NEM Cold Offline Wallet You Can Use To Send And Receive Funds

    The NEM team would like to thank Anthony (Telegram user @antownee) for creating this app and blog.

    NEM Hot/Cold Wallet


    Part 1: Introduction Part 2: Build the first ever Hot/Cold Wallet Part 3: Tuturial on using the Hot/Cold Wallet

    Part 1: Introduction

    In this blog, we introduce a new and revolutionary idea in cryptocurrencies and blockchain technology. We will set up a cold wallet, i.e., a wallet that has never touched the internet, that is also a hot wallet, i.e., a wallet that can easily send and receive assets. This means a user has the security of an offline cold storage but that they can actually send and receive XEM. This is thanks to NEM's powerful APIs and tiered architecture designed from the ground up with 100% new code.

    The advent of cryptocurrencies has seen an increase of interest and investments into this new space and with this comes the need to focus on security. Fortunately, in an ideal situation, blockchain technology is built with this in mind, provided you are in control of your private keys.

    NEM is consistently ranked in the top 10 via market capitalization and provides an easy and intuitive way to interact with its blockchain to further help developers and users alike bolster their security. To achieve this, we shall essentially implement "air-gapping" a wallet; meaning this wallet will never touch the internet nor directly connect to another device that is connected the internet (e.g., hardware wallets), yet still be able to send and receive cryptocurrency.

    So what can you do to ensure more safety? Well, if you have two computers, you can always keep your private keys separated from the internet, protecting them completely against cyber attacks. All you have to do is, create your transaction online, sign it offline to protect your keys, and broadcast it online again. This is what is known as “air gap” protection or "cold storage."


    The idea behind air-gapping is to have two separate devices. One that can access the internet and the other that will NEVER connect to the internet. The emphasis on the NEVER is quite clear as this is the device that will hold your private keys; in this case, we will use an Android phone that is no longer being regularly used. What we are essentially doing is splitting the transaction creation and signing from the broadcasting of it. The creation and signing will be done on the offline device while the broadcasting will be done on the online device. This has in theory been possible before in the past by technically savvy devs, but for the first time, we are now offering an experimental app that almost anybody can use and without having to buy additional hardware. It should be noted that this is an experimental Proof-of-Concept app and should be treated as so and used with caution. The NEM team is not responsible for the loss of any funds that occur as a result of using this app.

    Part 2:

    Development process

    Create-sign app (Cold)

    Both apps were built using an Ionic framework to enable cross-platform compliance. As well, the nem-SDK was used extensively for this app which is available on npm via npm install nem-SDK

    For the creation-signing app, I had to achieve the following:

    • Scan mobile account QR
    • Decode QR and wallet to retrieve private key
    • Use obtained private key to create and sign transaction
    • Generate QR

    I won't go into detail about the entire process but here's the GitHub link to the full code.

    However, I'd like to talk about the bit that proved challenging as it wasn't properly documented: Decoding QR and decrypting wallet.

    Decrypting the QR code was fairly straight forward and it yielded a similar json object:

    // Foo
    let walletinfo = {  
    "V" 1, 
    "type" 3, 
    "date": { 
    "name": "test-WLT" 

    The following function was used to decrypt the wallet with the above object

    // Decrypting wallet
    decryptWalllet(walletinfo, password) {  
            return new Promise((resolve, reject) => {
                let salt = CryptoJS.enc.Hex.parse(walletinfo.salt);
                let encrypted = walletinfo.priv_key;
                let key = CryptoJS.PBKDF2(password, salt, {
                        keySize: 256 / 32,
                        iterations: 2000
                let iv = encrypted.substring(0, 32);
                let encryptedPrvKey = encrypted.substring(32, 128);
                let obj = {
                    ciphertext: CryptoJS.enc.Hex.parse(encryptedPrvKey),
                    iv: convert.hex2ua(iv),
                    key: convert.hex2ua(key.toString())

    The result of this function is the wallet's private key with which it will create and sign the transaction.

    // Sign Transaction
    signTransaction() {
            // Set the private key in common object
            this.common.privateKey = this.nemPrivatekey;
            // Check private key for errors
            if (this.common.privateKey.length !== 64 && this.common.privateKey.length !== 66)
                return {
                    error: true,
                    message: 'Invalid private key, length must be 64 or 66 characters !'
            if (!nem.utils.helpers.isHexadecimal(this.common.privateKey))
                return {
                    error: true,
                    message: 'Private key must be hexadecimal only !'
            // Set the cleaned amount into transfer transaction object
            this.transferTransaction.amount = nem.utils.helpers.cleanTextAmount(this.nemAmount);
            // Recipient address must be clean (no hypens: "-")
            this.transferTransaction.recipient = nem.model.address.clean(this.nemAddress);
            // Set message
            this.transferTransaction.message = this.nemMessage;
            // Prepare the updated transfer transaction object
            var transactionEntity = nem.model.transactions.prepare("transferTransaction")(this.common, this.transferTransaction,;
            // Create a key pair object from private key
            var kp = nem.crypto.keyPair.create(this.common.privateKey);
            // Serialize the transaction
            var serialized = nem.utils.serialization.serializeTransaction(transactionEntity);
            // Sign the serialized transaction with keypair object
            var signature = kp.sign(serialized);
            // Build the object to send
            var result = {
                'data': nem.utils.convert.ua2hex(serialized),
                'signature': signature.toString()
            // Show the object to send in view
            return {
                error: false,
                message: JSON.stringify(result)

    Thereafter, a QR code will be generated which will then be scanned by the broadcast app.

    Here’s the code in its entirety for your perusal.

    Broadcast app

    The broadcast bit was fairly straightforward. All it had to do was scan the generated QR code by the cold wallet and broadcast it into the blockchain by making a POST request to the given endpoint.

    Note: This end-point was selected from a list of available NEM mainnet nodes that are accessible here.

    this.nodeUrl = "";
    //Broadcast transaction
    broadcastTx(signedTransaction: any): Promise<any> {  
            this.signedTx = signedTransaction;
            let headers = new Headers({ 'Content-Type': 'application/json' });
            let options = new RequestOptions({ headers: headers });
            return, this.signedTx, options)

    Here is the entire code repo up on GitHub.

    Part 3: Tuturial on using the Hot/Cold Wallet


    An extra layer of security while moving your funds is added by the use of paper wallets. In achieving so, you will have achieved an almost completely cold wallet environment. As previously explained, you will need two smartphones where one will never connect to the internet while the other does. Alternatively, a wallet could also be created via an offline iOS/Android/NanoWallet app and backed up before moving the wallet to the transaction signer app.

    We suggest using an unrooted Android phone with freshly installed OS on it. Then to install the transaction signer app, and then turn the phone into airplane mode for the life of the device. Note: connecting the app to the internet after turning on airplane node negates the security provided by having an offline signer application.

    Install the apps as follows:

    • Transaction Broadcast app: Install it on the phone that will connect to the internet.
    • Transaction Sign app: This will be installed on a smartphone that will not connect to the internet

    Advance preparation

    In this step, we will create a paper wallet, preferably on a PC that is not connected to the internet. This further bolsters our cold environment approach to moving our funds to and from our wallets. Download the paper wallet generator app and follow the below information:

    • The QR code on the left has account address information of NEM that can be openly shared with anyone. Funds will be credited by remitting to this address.
    • The QR code in the upper right has information on the private key encrypted with the password. Both the NanoWallet and smartphone apps have the same structure as QR which contains the private key.
    • The lower right QR code is the private key itself. A general QR code reader can read the secret key string itself.

    How to withdraw funds from Cold wallet

    NEM Hot/Cold wallet

    Launch this app on your old smartphone or on the phone that will not connect to the internet. This is the app that signs your transaction offline.

    • SCAN WALLET QR: We are able to obtain your private key by scanning the QR code in the upper right corner of the paper wallet.
    • MANUAL ENTRY: Enter the destination address/remittance amount/message/private key manually. However, it is also possible to scan a prepared invoice QR code. Invoices can easily be made in the NanoWallet or Android/iOS NEM apps available at


    Enter the password in the popup to decrypt and obtain the private key.

    After inputting it, the QR reader will start up, scan the QR code and eventually fill in the private key field of the provided wallet.

    On this screen, the private key is automatically filled on successful decryption. If you have a prepared invoice QR, you can hit 'SCAN INVOICE' which as before, with prompt the camera to scan your invoice QR code. Therefater, your 'NEM address,' 'Amount' and 'Message' fields will be automatically filled.

    Upon filling of all required fields, the 'SIGN TRANSACTION' button is then enabled.

    Once the 'SIGN TRANSACTION' button is pressed, a new page appears containing the eventual QR code that should be broadcast to the network.

    This QR code will be scanned by the 'Transaction Broadcast' app.

    Transaction Broadcast app

    Launch this app that you have installed on your regularly used smartphone. e.g., the one that is connected to the internet.



    Press the SCAN QR CODE button and scan the generated QR code on the 'NEM Hot/Cold' wallet app on your other phone.

    Upon a successful scan, the 'BROADCAST' button is enabled, and the transaction can be broadcast on to the NEM network.

    A successful broadcast will give a similar message as shown below. Complete with a transaction hash and a 'Success' or a 'Failure' message.

    In case of insufficient funds etc., an error message will also be displayed.

    And that's it. You have now received and sent from an offline wallet, the NEM Hot/Cold Wallet.


  • The Healthcare Blockchain and NEM

    The NEM team would like to thank Telegram user @Aenima86 for contributing this blog

    This blog post will discuss the potential of using the NEM public or private blockchain for data management within the healthcare sector. This could lead to several important advantages.

    • Patient-centered access management
    • Improved data security
    • Improved sharing of patient data
    • Increased data availability
    • New opportunities for medical research
    • Inclusion of wearable sensor data
    • Inclusion of Patient Reported Outcome Measures (PROM)

    The use case

    Hannah is a chronic diabetes patient; she needs to regularly visit the hospital and her general practitioner (GP) for monitoring of her disease status. This includes several blood samples and a yearly eye exam. Besides routine checks, she also daily injects herself with insulin with subsequent measurements of her blood glucose. Furthermore, she also uses a Fitbit to track physical activity and sleeping patterns. Hannah generates a lot of data, and it is difficult to keep track of all her data and which persons have access to her data.

    A well-designed healthcare blockchain solves many of her problems. All of her devices are linked to the blockchain, uploading measurements into the chain. She can overview all her data from one application. Both the data generated by herself and the data generated by the hospital are now at her fingertips. Moreover, she can view and control which persons have access to which part of her data. Maybe she would like to share sleeping patterns with a diabetes clinician at the hospital. On the other hand, she might not like to share the results from her other specialists (mental health/transmitted diseases/drug treatment), as this may not be relevant for the treatment of her diabetes.


    Blockchain technology has the potential to disrupt and improve the way we utilize and share patient data. Cross-institutional sharing of patient healthcare data is complex and as a consequence data is not always available for a healthcare provider treating a patient.

    Furthermore, the patient is often left without control of their personal healthcare data and not involved in which persons have access to which part of their information. Ideally, the patient would have control over their data and thereby also potential empowering the patient to be further involved in the treatment. Many patients do already measure a broad range of disease indicator data such as vital signs, medication compliance, exercise, sleep quality, physical functioning, diet, mood and life quality. However, these data are not always utilized by the healthcare provider because of technical difficulties in sharing these data sufficiently.

    How can we use the NEM platform

    Blockchain technology has potential to solve many of these challenges in healthcare data management, especially the NEM public or private blockchain platform is suitable for patient-centered governance of health data. The concept consists of using multi-signature contracts for access-control of data management and encryption of data to allow privacy and control of one's healthcare data.

    Furthermore, the blockchain is an ideal platform agnostic database for many different service providers and consumers to share content. NEM works via JSONrest API meaning that each company with its own proprietary system can easily connect to the NEM protocol to share data while remaining fully firewalled and secure. In this case, NEM provides a secure and encrypted medium for cross-platform exchange.

    The patient will have full access to his data and control over which persons/institutions her data will be shared. The patient can set access permissions and designate who can read and write healthcare data to his account. This access-control management could be utilized using an off-chain application. The application would allow the patient to see which persons/institutions have access to data and allow the patient to assign new permits and revoke already issued permits and/or make limited time sessions for reviewing data.

    This concept would provide transparency and allows the patient to make central decisions about what healthcare data is collected and how the data is shared between relevant persons/institutions.

    In one model for providing blockchain based healthcare records, when a healthcare entity is approved access to the patient's’ health data, it queries the blockchain for the data and uses the account bound key mixed with a SALT to decrypt data. Second layer intermediary software can act as a further form of encryption with the data encrypted with a SALT that is time bound. The healthcare entity could utilize a customized application to view and analyze the data. Querying the blockchain is API-based, and this would allow any programming application to interface with the blockchain. This means that a hospital using an EHR system could easily integrate their system with the NEM blockchain.

    In another model, the architecture is built around cryptography, mosaics (NEM assets) and the multi-signature contracting available on the NEM protocol. The multi-signature contract enables several entities to admin the activity of an account, control assets from one account, such as mosaics, or create additional contracts. NEM’s multi-signature makes a contract that assigns rights and powers of a certain account to other accounts; this contract can be edited. You can create the multi-signature contract in such way that any number of the signatories need to sign a transaction. This is called m-of-n multisig, where m can be any number equal to or less than n. In the architecture of the healthcare blockchain, we would use a 2-of-n multisig contract.

    In such a case, the patient would control two keys in the contract and each healthcare entity included in the contract associated with the patient's account would hold one key. This means that the patient will remain in control of the account because he has the required number of keys to edit the contract. Healthcare entities still have the ability to view the account information (such as encrypted messages) and initiate transactions. The patient would still need to co-sign transactions initiated by other entities, but that could be set up to be done automatically or within certain rules in the off-chain application layer.

    New data would be stored on the blockchain in the following manner: the patient or a healthcare entity with at least one key associated with the patient’s multi-signature account would initiate a transaction, sending a data-mosaic with included data as a message. The message would be encrypted, and the decryption key would be sent back to the multi-signature account in another transaction. When the data-mosaic transaction is co-signed manual or automatic the transaction is sent to an account related to that specific data type. This ensures that only persons/institutions with access to the patient's multi-signature account can read the patient's data using the decryption key(s). In practice the patient would control several multi-signature accounts – each account would be allocated to a specific type of data. This architecture would allow differentiating access to different type of data between healthcare providers.

    In yet another model, data can be encrypted with Shamir's Secret Sharing model. In this method, each data input can be sent with multiple passwords. There can be an individual password just for that line of data and message, or passwords that are included for multiple messages and therefore unlock multiple blocks of messages. This latter example could be used to associate a set of messages with a doctor, hospital, or medical record category. So, for instance, a patient that wanted a specific doctor to see said information can include the doctor's secret key in each message. Or in the case that one patient had multiple doctors in many regions over long time spans, they could have one password that unlocks all the messages for those specifically related health issues.

    In some cases, a patient is not capable of releasing their records due to their medical condition. In the case the patient is incapacitated, the necessary access permit in cases of emergency where the patient is unable to approve new persons for reading and viewing rights can be solved by using a trusted party. A trusted party could hold an additional key-pair, and the emergency procedure can be regulated by local legislation.

    Data with large volumes such as medical images are not suitable for storage on the blockchain. This can be resolved by adding a data lake storing encrypted data with references in the blockchain holding the decryption keys. Data lakes are highly scalable and can store a wide variety of data such as images and time series.

    Another viable option already being applied to some blockchain projects is to apply the above-mentioned methods with IPFS where each file is stored in encrypted format on distributed servers hosted by healthcare providers and can not be accessed without both the link and the password to decrypt the data. These can be encrypted or secured with the methods in the sections above for privacy and security.


    The potential for improving healthcare data management is enormous. The healthcare sector is known for being conservative in structural changes. Hopefully, this blog and similar ideas could lead the way and demonstrate that already working and proven technology, such as NEM, could be used for implementation of ‘The healthcare blockchain.'

    Working Applications on NEM

    One such company in India specializing in AI, Big Data, Blockchain, and IOT, RapidQube Digital Solutions, has already been a working prototype built on the NEM Blockchain implementing an advanced medical health records application.

    Their app utilizes the NEM protocol to allow patients to share selective medical records with their medical care providers in time locked sessions on an as-needed basis. This gives patients full rights to their data and makes them more active participants in their treatment process.


    Icons made by DinosoftLabs & Freepik from, Creative Commons BY 3.0


  • ioNEM - Transferable, On-Chain IoT Ownership with NEM

    The NEM team would like to thank Nikhil Jha (Telegram @ReverseCold) for contributing this project.

    The Internet of Things (IoT) is a massive developing category with a lot of potential applications. Unfortunately, many IoT implementations today rely on a centralized server to stay operational. Alongside the IoT movement, we have the blockchain movement, which provides distributed, secure computer systems to use. Let's combine the two categories into one using our very own NEM blockchain!

    What We Can Do

    1. Facilitate the ownership of one or a group of IoT devices of any kind on-chain.
    2. Control, manage, and secure the daily use of IoT devices off chain (fee free and secure).
    3. Allow IoT devices to communicate with others through the chain if necessary.

    The third point is not discussed in this blog post, but here are a few scenarios where it could be useful.

    An IoT device breaks and needs a replacement part. The IoT device sends a message to the user's phone with an order for the replacement part as well as labor costs to fix it. The user approves of the order, and the IoT device is fixed.

    An IoT solar panel produces extra energy that the owner does not need. Other IoT devices want cheaper energy than the normal on-grid provider, so then they make an off-grid bid for that electricity and the IoT solar panel sells it to the highest bidder. This can be done either with approval from the user or without in the case it is automated with an off-chain smart contract.

    The Basics

    There are a few NEM concepts that are central to this project. In this section, I will give a quick overview of a few of them.

    With Apostille, you can notarize a file on the blockchain. The notarization process creates a new account which is "colored" with that file.

    In NEM, accounts can own other accounts, so one can make it such that they own the account that was colored with the file. The account colored with the file is now useless without the private key of the owning account. Additionally, the ownership of other accounts can be transferred by the owning account. These multisigged accounts essentially act as colored accounts that are updatable, can hold memos, and are transferable.


    What if we created a file that represents a group of IoT devices? For example, we could create a file for a house. It would be a plain text file containing the address, description, permissions for that certificate, a random string, and any other relevant information all in plain English. It doesn't matter what the file is at all, since the actual action occurs on the blockchain.

    Once the file is notarized by Apostille, we have a private key account that can be owned by other accounts. Going into NanoWallet and converting it into a multisignature account with a single owner does exactly this.

    At this point, the owned account and its private key can be given to the IoT device. This enables an application to make a signed and encrypted request to the IoT device (for example, switch fan to speed 3).

    It is here that we run into a problem. In order for an IoT device to determine what account owns it, the device needs to make a request to an NIS. Unfortunately, it is possible for a 3rd party NIS to relay back malicious or incorrect information. The simple solution here is to run a node on every IoT device. Unfortunately, that can not happen due to space and processing constraints.

    This issue can be resolved by storing a list of 30-40 supernodes and picking a few at random to check from and verify the answer.

    Now that the IoT device has the public key for the account that owns it, the device is able to verify the signature, complete whatever action was sent to it, and send a signed/dated response to the sending application.


    Whew, that was a lot of information. Let's look at how we would actually implement this in an IoT device. Due to the current fragmented nature of IoT, there is no one platform to build on that would support this method. As such, here's everything you need to implement this system in your own devices. The author of this article has a homemade IoT system secured by NEM on a Raspberry Pi, which will be shown in the video at the beginning of this post.

    Key Generation

    First of all, an owned account must be created. This can be done by an end user through NanoWallet on any major desktop platform. Alternatively, a business could create a plain text file containing the company name and serial number of the device along with a random string and give it to the user to put into Apostille. The IoT device can then ask the user for the Apostille zip on setup and retrieve the relevant keys from there.

    An even easier solution for the end user is if the IoT device itself creates an account and securely transmits the private key of the account that owns it. The user can then remove the temporary account from ownership and replace it with their own account.

    The private key, even though it is temporary, should not be sent over the internet unless absolutely necessary (more on this in the next paragraph). The key can instead be displayed through any display the device has or locally using any other available method.

    If the private key were to be sent insecurely over wifi, an attacker could take the key and bind it to their own account. This would disable the IoT device, as the user can no longer bind the given address to their own. This means that while an attacker can not actually take over an IoT device without the user's knowledge, it is still best practice to show the key locally. In a future update to NEM, codenamed Catapult, upgrades to NEM's multisig and multiple txs in one called "aggregate transactions" will offer elegant solutions to this problem.


    Commands can be sent to the device in whatever format is desired as long as they meet the following criteria:

    1. Timestamped with a reasonable amount of accuracy and precision.
    2. Signed with the key of the owning account.
    3. Encrypted with the public key of the device.

    It is also recommended to pad the commands with some random data to potentially reduce any unforeseen attack vectors with a specific vendor crypto implementation.

    The demo later in this video simply encrypts messages in the following format (before signing and encryption).


    Sample Implementation

    Let's take a look at a sample implementation! If you would like to try this yourself, you will either need to have devices that are controllable by making web requests, or you can modify the code yourself to be anything you would like. This can be done with IFTTT if you would just like to see a demo, but note that using IFTTT doesn't give you the same security guarantees as a local, finalized version.

    IoT Controller / Hub Code

    For demo purposes, this can be run on any computer. In a final application, it would be run on an IoT hub. Alternatively, in a future where every device is its own hub, similar code could be run on each device.

    Controlling Application Code

    For demo purposes, this code needs to be run on a computer. Again, in any final vendor implementation, this would probably be a mobile application

    Additionally, no effort is made to do device discovery. The "IoT Hub" network address must be input manually. This is already implemented in nearly all IoT devices, and reimplementing it is complex as well as outside the scope of this demo.

    How to Use

    Apostille a picture of your house or an "IoT" device.

    Clone the hub and app from git. Edit app.js in your favorite text editor and replace the variables at the top with relevant variables.

    Do npm install to get dependencies.

    First, start the server with node hub.js and then run the client with node app.js.

    For more details (or an updated version of the instructions), please visit the Gitlab page:


Log in to reply

Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.