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.

Tutorial WAX

Creating a chains.json

Find all chainids in this repo

Creating a chains.json is probably the simplest task you will have to face when setting up your block producer infrastructure. However, when starting out it may be a bit time consuming finding all the information you need such as the chain-ids. This tutorial will help you find these missing parts and ultimately help you create your own chains.json.

Why a chains.json?

In other articles, we explain how to create a bp.json. Since a bp.json is needed for every chain (this includes a separate producerjson for Mainnet and Testnet), there is the need for listing all the producerjson associated with a block producer and chain. The chains.json simply lists and links the bp.json to a chain-id.

Creating the chains.json

Just start off by using this template. It contains already all chains that you will probably need and more. If you don’t want to use this repo, we can alternatively suggest using the Network Info from the Eos Nation Validator.
In the next step, delete all chains, that you don’t need from the template. Don’t forget to adjust the names of the chain’s producerjson that you have not deleted. These have to match the according .json and URL for that chain. The names provided in the repo are not binding, however, this is how we (would) name the producerjsons. In our bp.json tutorial, we have already covered how to correctly name your bp.json and URL.

Access Control Allow Origin Header

Note that you will have to set up the Access-Control-Allow-Origin Header properly. You can find more information about this header here.

If you are using Nginx, you can easily achieve this by adding the following line to your conf that handles the route for the chains.json.

add_header Access-Control-Allow-Origin *;
# Example config    
location ~ \.json {
        add_header Access-Control-Allow-Origin *;
        root /var/website/resources;
Tutorial WAX

Pushing the bp.json on-chain

If you have successfully created and hosted your bp.json, the next step would be to push that bp.json on-chain. If you do not have your bp.json yet, you can check out our tutorial on how to create one here.

Why push on-chain?

Bp.jsons that are published on-chain offer a couple of benefits over those that are hosted on a website:

  1. The bp.json will still be available even if the website is temporarily offline.
  2. Dapps can easily find all producerjsons in a single place.
  3. The signature from the block producer’s account offers verification of the bp.json and history with more insights about the changes in a producerjson is provided.

What you will need:

  • Your bp.json for WAX (Tutorial here)
  • Either
    • Cleos installed on your machine
    • Or you can use

Pushing via Cleos:

If you have Cleos installed on your machine and have added either your active or custom permission key (more on this later) to your wallet you can push the producerjson with a single command.


  • URL = (optionally) If you have problems connecting to a local node or don’t have hosted a node locally, use this option with one of the publicly available endpoints:
    e.g -u
  • OWNER = Account name of producer:
    e.g. blacklusionx
  • FILE = Filename of producerjson. You will have to:
    e.g. wax.json
  • KEY = The name of you want to use for authentication:
    e.g active or producerjson

cleos URL push action producerjson set '{"owner":"OWNER", "json": "'printf %q $(cat FILE | tr -d "\r")'"}' -p [email protected]

Just substitute the variables with your values. So in our case, we would push the producerjson with this command.

cleos -u push action producerjson set '{"owner":"blacklusionx", "json": "'printf %q $(cat wax.json | tr -d "\r")'"}' -p [email protected]

Pushing via

Especially when you are starting out, is a great option, since it offers a more user friendly way than a CLI-Command.


Click on this link to access the producerjson smartcontract.


Select “set” and fill in your information. As account name just use the account name you have registered producer with and for the json field just copy the actual content of your bp.json. Don’t use the URL to your hosted bp.json here. Finally click on “Submit Transaction” and choose your wallet of choice.

If you have done everything correctly will confirm your successful transaction. You can check out this transaction with this link

Creating a custom permission for just pushing your bp.json

For added security or if you often have to push the bp.json, we highly recommend using a dedicated key for pushing the bp.json. This prevents the key (or whatever script or person gets hold of it) to execute other actions.

You can find our full tutorial, covering how to create custom permissions here. The following pictures will show you which information you have to fill in, in order to set up the producerjson permission.

Tutorial WAX

Creating a bp.json for the wax chain


Find the current standard for the bp.json in the following repository. Please stick to this format and use the following article if you need clarification on some of the parts of the bp.json.

What is a bp.json?

The bp.json contains the most important pieces of information about the block producer and their nodes, such as API-Endpoints, geographical location, emergency contacts, and more. The standardized form of the bp.json makes it easy for companies and individuals to use the block producer’s nodes and information. Through this method sites such as ( can e.g. get the profile picture for your guild. If you want to get a rough overview of how a bp.json looks, feel free to take a glance at our bp.json for the WAX Chain:

Creating the bp.json

Writing the bp.json is pretty straight forward, since how the name already suggest, it is just a plain old json. Start by opening you favourite text editor such as Sublime Text or Atom.
Next copy the template bp.json ( into your Texteditor of choice.
Every information you have to fill out should be pretty straight forward, however we will cover the most important anyways. If you need further information, have a look at the GitHub repo above and read some bp.json from other guilds:

General Information:
  • producer_account_name:
    Self-explanatory. However, if you are not familiar with the naming scheme in the EOSIO ecosystem: It is important to note, that you have to use the name that you also have used (or are planning to use) for the action “regproducer”. That means that your official guild name may differ from the guild name you use on-chain. For example, our official name is “Blacklusion”, but our producer is registered under the account “blacklusionx”, since EOSIO requires that you have a name with 12 letters or bid on a name.
  • candidate_name:
    This is the field, where you can fill in the official name of your guild. Spaces are allowed.
  • github_user:
    Important: List atleast one GitHub Account from your team here. These accounts could potentially be used to give you access to private Repositories.
  • chain_resources:
    You can list one website here, containing links to your chain related resources, such as snapshot sites or backups. An array is not allowed here.
  • other_resources:
    Got any awesome tools or services you are providing? Great, you can list an array containing all the links to the services under this section.
  • Social accounts:
    I think we don’t have to explain how to fill in your social information here. However, it is important that someone of your guild actually regularly checks these accounts since this is how someone may contact you in case of an emergency.
nodes (Getting to the interesting part)
  • Node location:
    How to get the coordinates of the nodes? The simplest way is to use Google Maps ( Just click with the mouse on to the map where you want to have the location of the node. A small popup should appear, containing two numbers. The first number is the latitude and the latter the longitude.
  • Node type:
    Pick producer, if you are listing a producer node. Pick seed if you are listing a p2p-node. Pick query if you are listing an API node.
  • Features (only if node type query):
    Chances are, you are not only hosting a “normal” chain-Api, but you are also hosting a additional services such as a History. You can specify which services you are hosting with the feature section. Have a look here at the available features and list them accordingly. Your typical Setup with History v1 & Hyperion & Wallet Api enabled will have the following features: ["chain-api", "account-query", "history-api", "hyperion-v2"]
  • Endpoints: Self-explanatory. However keep in mind that you may want to produce on multiple chains, therefore choosing domains such as “” is not suitable. Instead, use a domain containing the chain’s name. Such as “”. To get an idea, what domains to use, have a look at the endpoints of other block producers (

Naming your bp.json not bp.json

Since many block producers are active on multiple chains (this is even the case when you are producing on both the Mainnet and Testnet of a chain), the bp.json is not actually named bp.json but after the chains name (different names for Testnet and Mainnet). So for the WAX Mainnet, this would be “wax.json” and for the Testnet “waxtest.json”.

Hosting your bp.json

Now, that we have written and named your bp.json. All that is left to do, is to host the JSON on your website. This has to be the same URL you have used (or are planning to use) for the “regproducer” action. So basically just your standard domain. Please don’t use something like “”, jut stick to e.g.“”.
Just host the bp.json at the root of that domain. So for example “”. We at blacklusion own both the “.io” and “.com” domain ending. In case you have multiple domains for your guild, you can optionally host the bp.json on all domains to make the lives of peoples easier. However, this is technically not mandatory.

Important: You have to change your chains.json to contain the bp.json’s name the according chain-Id.

Updating your bp.json

This should go without saying, however, this can be easily forgotten. When changing anything about your servers’/nodes’ configuration or other information, you have to keep your bp.json up-to-date.

Pushing your bp.json on-chain

I have written a separate article about this, to don’t force people to scroll through a complete article if there just want to learn how to push it on-chain.