NEM Wallet Beta 2.4.4 - Bug bounty paid in XEM

NEM Wallet Beta 2.4.4


  • Always make sure that you have your private key backed up before sending any funds to your account!
  • Always check that you have all your wallet files (.wlt) stored in a safe place before purging the browser local storage!
  • If you create a Brain Wallet, make sure to use a strong and unique passphrase.
  • It is highly recommended to use the LATEST version of Firefox, Chrome or Safari.
  • Microsoft Edge and Internet Explorer are not fully supported and could lead to the loss of your XEM if private key not backed up. For now, use of these browsers is locking the application.


This archive is certified using Apostille:
Apostille hash: 4e545903889c97342f48e6ff8f6f5fabd088ff0d5f60aa9aeb28ae94df24cf70f081cdef
Transaction hash: 0feb3658bb872b801bbff458a30d48aaf83a61f02b38269a77fffb94011d15a4
Sha256sum: 889c97342f48e6ff8f6f5fabd088ff0d5f60aa9aeb28ae94df24cf70f081cdef

Experimental chrome packaged apps:

The builds are not included in this release due to dependency issue.

If you have a Github account please report issues here: otherwise you can let a message in this thread. Thanks :slight_smile:

To receive a bug bounty, issues must be made in Github and have the payout address included. Jabo38 will filter and reward the bug bounties.

Previous Nano Wallet version 2.4.2:


  • Simple and mosaic transfers
  • Namespaces & mosaics
  • Create and edit multisignature contracts
  • Delegated harvesting & income chart
  • Plain & encrypted messaging
  • Apostille module
  • Transactions to alias (@namespace)
  • BIP32 accounts
  • NCC wallet support
  • Market information
  • Balance in many currencies
  • Changelly & ShapeShift Exchanges
  • Address book
  • Voting module
  • Trezor support
  • Offline transactions module

Detailed comparison with other apps:


I - How to use Nano Wallet ?

No installation or local server needed.
Once you have extracted the NEM-Wallet folder from the archive you can simply click on start.html to open the app in your default navigator.

II - How to import NCC wallet ?

Open NCC and your wallet, clicking on user icon should reveal a drop-down menu with “Export to ligthwallet”.
Once your have your wallet (.json format), open the NEM Wallet and import the file. It’ll ask for an upgrade and trigger the download of your updated wallet.

III - Imported accounts that are already harvesting using NCC

NCC is using a different way to generate the remote associated with an account. NEM Wallet uses BIP32 to generate it deterministically and make everything easier. In order to manage and monitor harvesting, you’ll need to deactivate the old remote account from NCC and activate your new remote account from the NEM Wallet.

/!\ Note for main network:
If you are part of the Supernodes program you will need to re-enroll your node using your new delegated public key.

IV - Update the NEM Wallet

Before update make sure that you don’t have any wallets stored into the NEM-Wallet folder (you can place them anywhere you want). Then, just delete old version and unzip new version.

V - Dashboard is empty and no balance is showing

It is probably that the node you are connected to is down.
Look at the navigation bar, at the top of the page.
If the circle next to Node is red, click on it and select another node from the list.

VI - What about bounties?
Bounties are paid out a multiple times a year. You must leave your NEM address in a well written Github entry to be eligible for a bounty. Bounties can range from 100-500 XEM.

The new bounty system is posted on the NEM website.

Known issues

  • Sometimes unconfirmed transactions does not show up for cosignatories

QR codes for account information and invoice are working with the latest version of Android and iOS testnet apps I have.

For those wanting to test the Android testnet app in conjunction with Nano, please give it a try.

Jeff found an issue on encrypted messaging, it works but can’t be decoded by recipient.
Bug is fixed in v1.0.6


jabo38 and Quantum_Mechanics,

I have a solution for the issue of importing an account with active remote harvesting. The solution should be included in Nano Wallet.

I’ll try to describe and document the solution. After that, I’ll come back to you. Now, I’m busy preparing some blockchain presentations and demo’s :wink:


Hi garp, thanks for your interest

Cool :slight_smile: Let us know when you can

Hi Garp, would love to hear about it.

Version 1.0.10

  • Fix simple signature changes in edit multisignature contracts.
  • Fix decryption of message for sender.
  • Fix autodetection of remote account status (locked or unlocked) on harvesting node change.
  • Better validation in namespace and mosaic modules.
  • Add extra information about operations
  • Minor design

What to do when importing an Account with Remote Harvesting active?

A user needs to create transactions to activate or deactivate remote harvesting. Therefore, all information about remote harvesting can be found in the transactions of the account on the blockchain. During the import process, these transactions can be retrieved from a NIS using the documented NIS API’s calls. By doing this, the client (NCC or nanowallet or any other client) can gather the information about the remote harvesting account in order to set the correct configuration of the imported account.

  1.   When importing an account, the user needs to provide the account address.

Get the info of the account to import, using the API call (this call is probably already used I suppose)
Check If the response includes the following in the “meta” field: remoteStatus: “ACTIVE”

  1.   If  remoteStatus: "ACTIVE" is present, then retrieve all outgoing transactions for the account using the API call documented in [](

a. Call /account/transfers/outgoing?address=…
b. As long as 25 transactions are returned, call the same function with an additional parameter:
/account/transfers/outgoing?address=… &id=…
with the transcation id of the last returned transaction as id
c. Once all outging transactions are retrieved, they can be processed. Consider only transactions with TransactionType 2049 (ImportanceTransferTransaction) and Mode=” Activate”.

d. The last transaction, based on the timestamp of the transaction, that corresponds to the criteria above will contain the public key of last activated remoteAccount.

If I’m right, this should work for the nanowallet, it works for me :wink:

1 Like


The problem is that to lock or unlock delegated harvesting you’ll need the private key of the remote account (You send it to the node).

It is easy to get the remote public key to monitor harvesting with your way :wink:
But if you want to lock or unlock, you still need the NCC to generate the key pair.

We could do it “watch only” but at one time or another you might need to handle lock and unlock of your account.

Oh, I thought it was obvious so I forgot to mention it:
A user who wants to import an account with delegated harvesting active, should off course be able to provide the private key of the delegated account. If a user has activated delegated harvesting in another client, they should retrieve the private key of the delegated account in that other client. When they want to deactivate remote harvesting in the new client, you could ask them to provide that private key. That is possible and seems logical, no.

Doesn’t that solve the issue? I know it would be enough for me.

If after deactivating remote harvesting, one would like to reactivate remote harvesting again, then it is perfectly acceptable it would be another remote account, generated by the new client.

If you have access to the private key you can simply build a keypair object then, so there is no need to look into txes to find the delegated public as you can directly extract it from the object.

See Keypair in lightwallet

That is not to activate or deactivate, only the public key of the delegated account is needed for that and you can already use a custom one in Nano to do so.

Private key is needed to lock and unlock accounts harvesting (start/stop), which is not the same than activating and deactivating a remote (making an account your remote / de-attributing the remote).

I could ask users to provide the delegated private key if they import an account manually with remote harvesting active, will see what devs thinks about it, but I think the best solution would be to completely switch for a new remote. In the end it’ll be better.

There is now a 5,000 XEM bounty for issues reported to QM’s Github.

Nanowallet is the best NEM client :slight_smile:

And t is just getting started. This will lay the foundation for a lot of good things to come. I wish the first wallet would have been built like this in the first place, but we are catching back up now.

Version 1.0.13

  • Fix message fees (lower)
  • Fix private apostilles
  • Fix audit of private apostilles
  • Minor design

when might be out nanowallet?

Not sure, I’m going through everything and working on getting app ready for translators right now. I hope to finish that before the end of the week, there is a bit to do.

To go on Mainnet we need a bit more testers and feedback.

Until we get more testers, it is hard to confidently put it on the mainnet. It is more or less ready, but we really need some more testers. For instance I have found a couple of small bugs that if people were really testing, they should have found, yet nobody reported them on github. NEM is worth a lot of money. Wallets should be tested I think.

1 Like

why not release source code of nano

it is written in JavaScript, which is interpreted language There is only source code.