(Supporting) Will the code of the monitor ever be open source?

Hello, team.

I’m asking because I’m really interested in knowing how to get all the data it shows, specially the epochs to next event and the history of earnings each node has (not just the total amount of accumulated rewards).
I could even host my own monitor, so I don’t need to rely 100% on yours for my nodes hosting project.

Maybe it’s not open source because it has no documentation? That wouldn’t be a problem, I could figure out what the code does.

Or maybe someone could tell me how to get the information I want? That would be less ideal, but still better than nothing.


Hello @J053,

You can find the Node Monitor Repo here:


Thank you, but that’s the front-end. Do you have the back-end?

1 Like

I think it uses the beacon nodes or boot node at the backend. Since each node is connected to one of the beacon nodes and all of the beacon nodes currently belongs to the team, they can access those information you mentioned. On the other hand, if someone can get IPs of all nodes in a network (Bitcoin, Ethereum, Incognito etc.), this raises issues for miner privacy/safety and network security. Of course, a well-organized entities (states, firms) etc. probably may extract the node IPs via some other methods. I ignore this :slight_smile:

1 Like

We will review and publish the source code within the next couple of days.


Good news @J053! :raised_hands:

We have an API endpoint that you can call to see all the data that the node monitor displays and then some, please use the following:

curl -s ‘https://monitor.incognito.org/pubkeystat/stat’ -H ‘accept: application/json’ -H ‘content-type: application/json’ --data '{“mpk”:“XXX”}`

Replace XXX with the validator public key. If you have any questions please let me know. I’ve made a bash script using this output to automatically restart stalled nodes, find the post here: [Node Guide] Prevent BEACON STALL Containers


Thank you. I know about it and I use it. It’s just that I don’t want to rely on that endpoint 100%. I wouldn’t call this ticket resolved. Can I reopen it and wait until you release the source code of the monitor’s backend?

1 Like

No worries, I’ve reopened it. I’ll reach out again to the team who handles the Node Monitor.


Is there any way we can calculate epochs until committee without using the node monitor? Like with the data we can extract from a full node and validator node API call?

1 Like

And the vote stat, please

I think you can pickup the current committee vote-info by reading “MissingSignature” of the getbeaconbeststatedetail call and record the stats yourself. Unless there is an even better method available that I do not know of.


By calling getbeaconbeststatedetail
Look at the key ShardPendingValidator you will notice that its an array for each shard:

Let say my vNode has “IncPubKey”: “…P6Qa” each epoch passed, its index in the array decreased (move up in this list) until it become Committee. This behavior is the same for ShardCommittee list.

About SyncingValidator list, a validator must sync Beacon/Shard to latest, then it will send “Finish Sync” message to Beacon, Beacon approved and then this validator moved to ShardPendingValidator.

So, assume 4 validators is removed from Committee for each epoch, 4 new validators (from ShardPendingValidator) will be replaced. We can estimate how long (how many epoch) until a node be listed in Committee.


Thank you so much! This information is very valuable.

I have another question. How to get the earnings history of a node?

you need to call this one (or 2 times) for each epoch and cache the value. Subtract the amount (latest) vs amount (previous) to get the earning per epoch.

curl --location 'https://your-incognito-fullnode.com' \
--header 'Content-Type: application/json' \
--data '{
    "id": 1,
    "jsonrpc": "1.0",
    "method": "getrewardamount",
    "params": ["<reward-receiver-address>"]


Is that what you use for the monitor? Because I’ve seen that when you get the monitor unstuck the earnings history loads all, and with this method you cannot go back in time to check previous epochs.

I am not involved in coding the monitor, so i’m not sure. I used this RPC to test blockchain functionality for every new release.

cannot go back in time to check previous epochs.

But a quick thought, yeah, that make sense why these values not recovered after resync the node monitor.


OMG, the array is sorted already!? How did I miss this, that is awesome. :crazy_face:

Is the number of epochs each node is in committee still random? So the best anyone can do is a statistical average and approximate “epochs until committee”? You mention 4 which sounds like a good starting point given that 22 nodes are still not rotated, correct?

My mistake, committee size for each shard is 48, fixed node 16, and 6 validator is replaced for each epoch. The reason that you saw a validator (in group index 16 - 47) stay a bit longer in committee is that sometime a validator in the committee get slashed.


How can I get the reward receiver address if I have the validator (aka mining key), validator public and the IncPubKey?

call RPC getbeaconbeststate, search public-key (as the key) you will find reward receiver address in the value.