(automated delegated harvesting, export of transactions and more!)

Fantastic. Thanks! I’ll check this out on the weekend

UPDATE (04.08.2017)

the tools are now available under a new URL:

What’s new?

  • integration of
  • displaying mosaics in transactions
  • complete transaction-history can now be displayed and exported to csv

What’s next?
Currently my main focus is to provide a service that will give you following possibilities:

  • listing nodes with free slots to harvest
  • register remote accounts to:
    • a) get mail-notifications when node goes down
    • b) provide automatic restarting of delegated harvesting
      -> for this functionality you would have to provide the private key of your remote account
      -> I think everybody should decide on his/her own whether he/she wants to do that

Really great features. Thanks for that!

UDPATE (15.08.2017)

Whats new?

  • a service that provides automated restarts of delegated harvesting
  • supernodes-tab shows amount of free harvesting-slots are free on each node

I am really happy to be able to serve this service and hope you like it :slight_smile:

If you run into any problems or have questions -> feel free to contact me directly or here in this thread.

A detailed blog-post about how that service works will follow.


Very great!

Update (22.08.2017)

Improvement for automated restarts of delegated harvesting

  • blog-entry with detailed infromation about the service
  • private keys of the delegated accounts are stored encrypted
    • a strong encryption-mechanism which ensures that a separate secret is neccesary to decrypt the private key (this secret is currently stored as environment-variable)
    • I cannot 100% ensure that the private keys of the remote accounts cannot be compromised. but I did my best to make it extrem hard to reveal them
  • possibility to unsubscribe from automated delegated harvesting
    • if you unsubscribe from the service, every data you provided will be deleted!

First of all I want to thank all people that trust my service that provides automated restarts for delegated harvesting. Currently 37 people are using it.

Well in the last couple of weeks I had often trouble with following use cases:

  • vested balance of registered addresses fell below 10.000 XEM
  • people registered to the service and provided a private key of a non-remote address (which fortunately didn’t have any XEM on their balance)

It is a bit sad that there is no clear documentation of the REST-API which status-codes the response can contain dependending on the reason why activation failed. Anyway I now managed to catch specific responses and handle them.

If activation for addresses fails for these reasons now the suscription is getting deleted instantly and the subscriber receives a reasonable e-mail.

Before this improvement my service tried to activate harvesting for these addresses on each node that had free slots. The result was that some other addresses could not be activated because it seemed that there were no more free slots available.

The service should now work without any problems :slight_smile:

Hi There,
today I activated the automated service, but in my wallet service/manage delegated harvesting the ‘harvesting status’ is still on ‘inactive’ does it take a few hours to became ‘active’?

if so… it would be a good thing to update the article

kind regards,

Did it work now?

When delegated harvesting was (re)started you should receive an e-mail containing the Node which you are using. You then have to put the ip/hostname of this node into NanoWallet to see the “active status” there.

NanoWallet doesn’t know on which Node my service restarted delegated harvesting for you. Therefore you have to do this step manually.

This step is only necessary if you want to check whether you are really harvesting or not.

Sometimes the scheduler in my service doesn’t run for a while. Unfortunately I couldn’t solve this problem until now. On you can see how many minutes ago the supernodes were updated. If there is shown > 300 minutes then my scheduler didn’t run for a while.

No it did not work…

i’m using Version: BETA 1.4.13,

I paid for registration but get this email:

your address is ineligible for harvesting
Delegated address

your subscription has been deleted!

feel free to register again!
please make sure that the data you provide is correct and that you have a minimum of 10.000 XEM vested!

where can I find how much I have vested? I just put my password in the left panel and hit send… why is it possible to send the fee if I don’t have enough Xem vested?

@Nico You need over 10000 XEM vested balance to start harvesting …

ah okay, I have 41.136402 XEM vested, sorry, so that would be enough, now what went wrong with my registration?

uhu, sorry, i’m missing a 959.000 Xem to start harvesting?

You need 10000 (10 thousand) XEM vested balance to start harvesting. Remote status can be activated always but this doesn’t change you need 10 thousand to start.

like @CryptoBeliever stated you need a minimum of 10000 XEM vested in your account. you can calculate the estimated time to reach that goal here:

small update regarding nem-tools:

  1. source-code on github is now up-to-date

  2. transactions now also include transfers from multisig-accounts

  3. cryptoTony mentioned the service for automated restarts of delegated harvesting in his new video

  4. I made a change on the registration for auto-restarts of delegated harvesting. I also updated my blog-entry so that it is up-to-date. following attributes are now needed to submit:

    • e-mail
    • public key (delegated)
    • private key (delegated)

automated restarts are currently used by 95 people in total


I justed moved my blod-entry from medium to steem. if you like nem-tools please upvote my post, thanks! :slight_smile:


Hi Marco

I saw that the page transmitting the keys is not using ssl (or any other encryption), at least according to my browser (chrome Version 63.0.3239.108 (Official Build)). I wonder why? if you go through all the hassle of encrypting the keys securely on your storage, might it not make sense to ensure an encrypted transmission to you? Or am I missing something?



indeed this is a drawback that shouldn’t exist. but good question! the main-reason is that the frontend was initially hosted through github and therefore API calls to different nodes were not possible due to the fact that almost every node runs on http instead of https. github transformed each call to a node automatically into https and so the API calls to the nodes couldn’t be executed. this was a really ugly circumstand.

I might take a look at this topic again


Hi, I’m trying to integrate this service in nanowallet importanceTransfer controller,
I’m doing test from a testnet wallet, so is there a test url to call for