Announcing Steem full RPC node

full rpc announcement.png

All about Steem full nodes

For those who are new to this, there are different types of Steem nodes that can perform different tasks and run different types of applications. These are the common ones:

  • Seed node
  • Witness node
  • Network broadcast node
  • Hivemind API node
  • Full RPC node

This post will be focused on full RPC nodes as this is what I will be announcing today. These nodes are important for the functionality of many Steem applications that require every data from the Steem blockchain (e.g. post data, curation data, account history etc). Without them, interfaces like, or wouldn't exist and you will probably not be reading this post.

Current state of full nodes

This is the main reason why I'm announcing another Steem full RPC node.

As of writing this post, there are only seven such nodes that are fully functional, as far as I know. In my opinion, having more working Steem full nodes is crucial for decentralization of the Steem blockchain as traffic can be spread out across more nodes which puts less stress on a particular node. Right now these are the seven fully-functioning RPC nodes:

With the recent developments of MIRA and Hivemind which have reduced the server requirements for running full nodes significantly (therefore cost), there is no reason not to have more of such nodes.


As a witness currently ranked at 180 (active ranking 118) and only getting one block every 2.8 days, don't expect any crazy setups out of this as I'm running this on a budget.

The full node is housed in the same server that I mentioned in my initial witness announcement post, with all steemd plugins enabled but follow and tags of course, which are now handled using Hivemind.

Model: QuantaMicro X10E-9N
CPU: Intel Xeon E3-1240 v6 (4 cores, 8 threads, 4.1 GHz)
RAM: 64GB DDR4-2400 ECC
Storage: 2x 512GB SSD (configured in RAID 0)
Network: 300Mbit Bandwidth

The Jussi reverse proxy is configured using the EXAMPLE_hivemind_upstream_config.json template found within the Jussi Github repo here.

Before you scroll down to smash that downvote button on this post due to running a block producing node alongside a full RPC endpoint on the same hardware, I understand that this is not a very good setup due to reliability issues for having both in one box. I will be working on a video tutorial that some of you have requested on setting up a consensus node, which will also act as my backup and seed node (see roadmap below). I'm not scheduled to produce blocks often so it should not be too much of an issue for now.

This is the RPC endpoint that you may use on pretty much any Steem applications (it's a full node so it should be able to). You may utilize it by changing the Steem API settings on applications or programming interfaces.

For example, on Steem JS:

steem.api.setOptions({ url: '' })

Only HTTPS will be available, which means HTTP connections will be redirected.

With regards to WebSockets, I was not able to get it to work on, so I opened a non-standard port for these requests.

For example, to connect to the WebSocket server on cli_wallet:

cli_wallet -s wss://


While I did some performance testing on this RPC endpoint against the other seven fully functioning nodes, don't expect it to perform as well as those listed above especially when there is high traffic.

I have picked 5 SteemJS API calls at random that routes to a steemd instance and another 5 that routes to a hivemind instance, and programmatically calculate the time taken for the callback function of the API call to be called.

steemd callshivemind calls

steemd API performance

Screenshot 20191227 at 10.06.41 AM.pngScreenshot 20191227 at 10.10.31 AM.png

From the charts above, our node outperformed every other RPC nodes available. The closest one is, which appears to be one of the least used RPC endpoints as I only see this option on their eSteem apps. Even if an application allows custom RPC endpoints, this is not a well known RPC endpoint as it is not reported in @fullnodeupdate posts. Perhaps the fact that no one else was using explains why it outperformed all of them.

For some reason, struggles with account history API calls, which puts it in the last place. I have benchmarked it multiple times on different servers on different geographical locations and got similar results.

hivemind API performance

Screenshot 20191227 at 10.28.41 AM.pngScreenshot 20191227 at 10.29.06 AM.png

With regards to Hivemind API methods, ours performed just behind, which puts it in the 5th place. Not surprising that is one of the top performers on the chart, but won the first place on this one. Perhaps these nodes are underutilized (correct me if I'm wrong), which results in a lower response time.

These tests are performed on my fiber internet connection here in Malaysia that I have been waiting for years. Results may vary depending on your location as some RPC nodes may be closer to you, which can result in quicker response.


Going into 2020, this is my todo list for now:

  • Backup witness node along with consensus node setup video tutorial
  • Detailed, up to date, weekly reports on server resource usage (to inform new witnesses). The previous reports are not considered as detailed reports as it is not very complete.
  • Work on Steem hardware wallet application on Ledger


Currently subsidising server expenses myself for the first year. If you like what I'm doing, please consider supporting by voting for us.