Tutorial WAX

Creating Snapshots

Why bother with snapshots?

Although a snapshot service is currently not part of the Office of Inspector General Guidelines (anymore), there are still reasons why you might want to set up a snapshot solution.

If you are spinning up a node using Snapshots (e.g. a producer, generally not possible for e.g. history nodes), it is important to use an up-to-date snapshot in order to reduce set up time. When you operate your own snapshot service, you can ensure that you always have access to a recent snapshot.

The second advantage of operating your own snapshot service is security: If you are setting up e.g. a producer node, trust should be a real concern. Not saying, that anybody on the WAX Blockchain is manipulating their snapshots, just saying that technically it would be possible and that your own snapshot solution, will help to address these trust issues.

Step 1 – Setting up a node

We highly suggest having a dedicated node just for creating snapshots. Although your snapshot will be created within minutes (depending on the chain size), your node will have a very poor performance during that time. The node is basically useless while creating your snapshot. Just set up a node as you usually would.

Step 2 – Configuring your config.ini

In order to create your snapshots, you will need to have the producer_api_plugin enabled. This plugin has the producer_plugin as a dependency (and chain_plugin and http_plugin but you will probably have these enabled already). In order to enable these plugins, make sure to add the following lines to your config:

plugin = eosio::producer_plugin
plugin = eosio::producer_api_plugin

and of course

plugin = eosio::chain_plugin
plugin = eosio::http_plugin

Step 3 – Creating a snapshot manually

You can create a snapshot by executing the following command

curl -X POST

This assumes that the IP-Address of your node is (localhost). and the API Port is specified as 8888. Change these if needed. In case you are using Docker to host your nodes, you can check the IP-Address of the container with:

docker inspect CONTAINERNAME

This will yield you will all the necessary network information. (By the way if you don’t know this already: If you are running your Snapshot Service in a docker container as well, you don’t have to mess around with IP-Addresses. Just use the containername instead and make sure both containers are in the same network. Docker will resolve the according IP-Address automatically).

Step 4 – Specifying the snapshot directory

The snapshots will be saved in the data/snapshots directory by default. In order to specify a custom directory, you will need to set the “data-dir” option in your config. In case you are using docker, it would make more sense to not mess around with these settings, but instead to mount your volumes accordingly.

Step 5 – Set up your Snapshot service

This tutorial is not really about setting up an actual snapshot service. But now that you know how to create a single one, all that is left to do, is automating that task using a script. Regardless of your implementation, here are some things to consider:

  • Frequency: Creating one snapshot per day, should be enough. But feel free to experiment with other frequencies
  • Compressing your snapshots: When downloading your snapshots to other servers, size matters. For that reason, you should consider compressing your snapshot e.g. using the “.tar.gz” file format.
  • Deleting old snapshots: Snapshots can rack up quite some disk space pretty fast. Consider deleting older ones, while keeping at least one per major node version (1.8 and 2.0 etc.)

Helpful links:

If you are looking to set up a snapshot service fast, you can have a look at the open-source code from Charles from the folks at Sentnl:

Official Documentation:

Tutorial WAX

Claiming Rewards on WAX

Why claim rewards?

This should go without saying: For every block produced, a block producer receives a certain amount of rewards (in WAX). These rewards have real value and can be used to either buy items in WAX or can be exchanged for other currencies. These rewards are not automatically transferred to the block producer’s account, but instead, have to be claimed manually (or with a script). On WAX, GBM Rewards can be received on already claimed producer rewards. Unclaimed rewards mean missed GBM rewards and therefore missed money.

We highly recommend claiming your rewards frequently.

How to claim Rewards?

There are three options:

1. Automatically claiming rewards (recommended)

Claiming rewards is one of these things, you want to set up once and then just forget about it. Therefore, we highly recommend using some sort of tool or script for that. There are tools like e.g. Waxy, that automate that task for you. We have not tested these tools, instead, we like to set up our script on our own infrastructure. It gives us greater control and after all, it is pretty easy to setup. Just write a quick script yourself or have a look at our code, which can be deployed via docker.

2. Using (user friendly)

There is no real reason why you want to claim your rewards manually. But in case you really need to, offers the most user-friendly way of doing so. Just head over to the EOSIO account. Then under Contract -> Actions you will find an option for “claimrewards”. Select that option and fill in your account data.

3. Manually claiming with an API / Cleos

Manually performing an API request can be easily done with e.g. Cleos. You willl need to use the fillowing action for claiming rewards. Just exchange actor & owner with your own account name and replace permission with the name of your permission, you are signing with e.g. “active” or preferable a custom permission such as “claimrewards”.

            account: "eosio",
            name: "claimrewards",
            authorization: [
                actor: "blacklusionx",
                permission: "active",
            data: {
              owner: "blacklusionx",

A few words about Security:

Regardless of how you choose to claim your rewards: You should always use a custom permission only dedicated to claiming rewards. You can learn how to create custom permissions in this tutorial. Basically, the custom permission will only be able to sign the “claim rewards” action. This will ensure that no other transactions can be signed. This prevents any scripts or people from creating harm to your account, that get hold of your key.

How often should I claim rewards?

On some EOSIO based blockchains, you can technically claim your rewards how often you want. On WAX this seems to be limited to once per day. In our opinion, this is a useful limitation: Depending on your local tax laws, every claim has to be considered with the current exchange rate in your tax report. More claims mean more effort when creating your tax report. Only claiming once per day is a great mix between claiming frequently and having a small number of transactions (~30 per month) to keep track of. There is no real reason to claim more often anyway.

What about Testnet?

Claiming your rewards on Testnet is not that important, since Testnet rewards have no real value. That being said, we would still recommend claiming your rewards on the Testnet for two main reasons: 1. It allows you to test your Permission setup and Infrastructure/Script configuration 2. Although money is made on Mainnet, the Testnet is still an important key for the future development of WAX and products built on WAX. Testnet should be treated the same way as Mainnet is treated. Claiming your rewards on Testnet indicates a clean setup and that you are taking Testnet seriously. Additionally claiming your rewards on Testnet means next to no effort, anyways.


Announcing candidacy for the WAX Blockchain

This article was originally uploaded to medium.

What makes blacklusion an outstanding candidate for the WAX blockchain? All guilds bring excellent software development skills to the table. However, I believe that the current implementations of blockchain technology are mostly targeted to a niche market. Although we have come very far in the past years, they are not always very user-friendly, to begin with.

Relevant background qualifications

With years of experience in not only software development but also in content creation and digital marketing, my goal is to make blockchain more userfriendly and mainstream. When developing software products, only good functionality won’t cut it. My high expectations for the design and user experience result in easy to use products.

User-experience is especially important for an eCommerce blockchain such as WAX.


Leonard Scheidemantel, 20, CEO:

Background in content creation, digital marketing and software development. Currently studying Information Systems at the technical university of Munich.

Server Infrastructure

As of writing this article, I am operating two bare-metal servers. The servers are distributed across two data centers in Finland and Germany. One server is dedicated to hosting publicly available services such as APIs and websites. The other server is solely dedicated to the purpose of producing.


All services other than the producer nodes are deployed in docker-containers. This ensures a high degree of freedom when scaling the software side of blacklusion’s infrastructure. The current servers should be sufficient hardware-wise to host the first producer-nodes and other services such as APIs and histories. However, since tasks will probably become more and more demanding in the future, I am planning to expand the current server setup with additional bare-metal servers in different data centers.

Thoughts on governance

Although blockchain technology enables us to execute transactions without the need for a central governing institution, this does not mean that the topic governance should be avoided. The user should always feel safe when performing transactions on the blockchain. Therefore, block producers should actively participate in voting on governance in order to guarantee every user the best possible experience.

Thoughts on transparency and accountability

Transparency is deeply anchored in the values of blacklusion. I am happy to contribute to the EOSIO / WAX community: If not otherwise required, I am planning to make the software projects for the EOSIO ecosystem open source.

One of the benefits of being a small company is the ability to easily find the responsible employee. Since my company only consists of myself, it is easy to hold the right person accountable for the company’s actions. If something should ever be not working correctly, there is a 1/1 chance to hit up the right person on Telegram (my account details at the bottom).

Thoughts on security & infrastructure

When operating nodes, security should be the highest priority, besides performance. A possible breach has an impact on the complete network.

Because of that, my producer nodes are running on an isolated server. Additionally, I have taken a couple of steps to further increase the security of my servers. Besides the fundamentals of using SSH-Keys instead of passwords, I have made two-factor-authentication mandatory for all servers. I also tweaked system settings, such as blocking all not mandatory ports and securing the shared memory.

Community benefit project outline

Blacklusions projects always revolve around the effort to make blockchain more user friendly and ultimately more mainstream. This includes developing advanced guides and info material to make the start for new users easier.

Currently, I am investigating how the launch of an IOS /Android App could benefit the user with useful functions (not just displaying stats and graphs).

General information

  • Social MediaTwitterTelegram
  • Official WAX Guild candidate name: blacklusionx
  • Telos-Testnet node: blacklusionx
  • Location of company headquarters: Stuttgart, Germany