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

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.
    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 full if you are listing an API node. If you are hosting additional services such as a Hyperion history, there is no need to further specify nodes or URLs. The Hyperion history will be automatically be suspected behind the full node’s URL. All that is left to do, is to set up your server’s internal routes, to actually direct the history traffic to Hyperion.
    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.