Blog powered by Dysnix: Custom blockchain infrastructure that solves 120% of tasks powered by Dysnix: Custom blockchain infrastructure that solves 120% of tasks

Alex Vorona
January 10, 2023

Specific tasks demand specific solutions. That’s what typically blockchain projects are looking for when they contact us. This case is a brilliant example of the evolution of a client’s request during the research phase and the teams’ cooperation in facing complex challenges. 

Within this article, you’ll find out how Dysnix works over the client’s tasks from the agreement to the support stages and what expected and additional benefits we generate for our customers.


About is a blockchain analytics platform that helps traders and blockchain projects by highlighting and informing them of the essential changes and trends happening in the blockchain (especially in crypto). They handle processing the petabytes of trading data circulating in their systems daily to provide the most valuable insights to their customers 24/7.

The inner infrastructure of (Source)

The requirements of Nansen while searching for solution providers were extremely high because of the tech-savviness of the company itself. They selected Dysnix because of the expertise that can significantly complement their internal team, ease of knowledge sharing, and inventive approach to technical problem-solving.

The mood at the beginning of the project

As a sign of a promising project, Nansen contacted us with a primary objective that sounded more like, “We think that we need this and that. What do you think about it?” After a brief talk over the topic, both sides understood that Dysnix could dive even deeper into the problem and solve it in the most optimized way.

So everyone got excited about the future communication and technical miracles to be manifested. 


Negotiations stage

It took only two calls to establish all the connections between companies and agree upon the key points of cooperation. The COVID pandemic showed us how any topics and challenges could be discussed and successfully solved, no matter how far your colleagues are. So we didn’t waste too much time before the development.

From Dysnix’s side, we hand-picked two engineers, Cloud Architect and Senior DevOps Engineer, with blockchain experience. From Nansen’s side, they prepared the full scope of requirements and only a few assigned specialists to communicate with our team. Our client delegated 100% of the work to us and relied on us completely. 

Dysnix was ready to dive in.

Business task analysis and its’ metamorphosis

In the latest statement, hired Dysnix to develop, implement, and support a reliable, autonomic, and secure infrastructure for the specific needs of the blockchain analytics platform.  A high level of security was an essential point of the request.

Nansen needed a fail-safe and highly secure deployment for the Ronin blockchain validator node with secure private key storage.

Ronin Network Introduces $RON (Source)
Ronin is an EVM blockchain crafted for developers that build games with player-owned economies and are suited well for cryptocurrencies. This blockchain claims to be an energy-efficient sidechain from Ethereum. It supports EVM-compatible smart contracts and protocols. 
Currently, Ronin is a Byzantine Fault Tolerant proof of authority (POA) network operated by validators. Also, Ronin released Testnet's new consensus engine (Consortium v2), which follows the Proof of Staked Authority strategy. Proof of Staked Authority combines Delegated Proof of Stake (DPoS) and Proof of Authority (PoA). At the bootstrap of the network, carefully selected, trusted validators were predefined to secure the network. Now, validators can be added or removed if the decision is approved by the majority of currently active validators.

The Ronin validator node Nansen planned to get couldn’t match their needs. It was a typical validator node that was tightly connected to the whole network and didn’t have all characteristics needed. The task of Dysnix was to implement such a blockchain environment that would add new features to the Ronin validator without any changes to the functionality of the node itself. 

Why is it so important to stay functional as a validator node? Because it’s essential for both blockchain’s transaction verification and reliability in the eyes of other validators. If the validator is off, it doesn’t perform its direct functions—validating blockchain’s transactions—it’ll lose its part of a reward. Even if you think the task is too controversial and impossible, our engineers think another way. 

The Dysnix team planned a solution that will look like this:

The schema for a solution for Nansen. Source: Nansen project’s documentation

Before we get into a closer review of the solution Dysnix engineers offered, let’s look at the top level of settled requirements. 

The solution meets the following expectations and requirements of the client:

  • The whole environment is fail-proof.
  • The validator node with a secure private key storage can’t be accessed from the Internet or anyhow except by Nansen.
  • The validator node still works as a part of a blockchain.

But we offered to go even further and add other improvements from the start:

  • The created nodes will be 99,99% uptime.
  • The developed solution must be cost-effective.
  • The solution can be easily transformed, edited, remastered, and explained to any new engineer in the client’s team.
  • All the parts of the development process are documented and detailed.
  • The solution should have monitoring, alerting, and analytics parts that demonstrate the efficiency and results of the implementation. 

Our offer is based on the high standards of work of Dysnix engineers and their dedication to the projects. As you can imagine, Nansen could hardly disagree with the offer we prepared for them.

Setting up a scope of work (SoW) and a roadmap

After agreement upon the first part of the cooperation, Dysnix created a high-level SoW with a helicopter view of goals and future cooperation achievements. During the R&D phase and after 2-3 clarification sessions, where Nansen revealed more facts about the team Dysnix will work with and other details, our engineers made the final decision according to the architecture and in-depth detailed SoW. 

With this version of SoW, Dysnix described low-level tasks in their tracking system and prioritized them into the roadmap. Engineers estimated the whole development process for 100-120 working hours. It perfectly fit the needs of Nansen. 

A sneak peek at the projects’ roadmap

Also, we had discussed that the SoW could be changed in the development process, and as we have foreseen, it happened indeed during the stages of development. Nevertheless, it didn’t affect the final result badly. On the contrary, we got even better results to be proud of.

As there left no points to discuss further, we got prepared for the actual invasion and hard work on the project. The workflow with the internal team of Nansen was naturally settled: if one side needed an answer, they asked direct questions and got all the explanations right away. 

In-house team connection

Engineers participating in the project were closely involved in the work of the in-house team. Also, they made every effort to make their activity transparent and understandable for every involved stakeholder. The Dysnix team is famous for making the working atmosphere easy-going thanks to three main points:

  • Expectability and following the plans
  • Efficient and regular demos
  • Applicable and worth-reading documentation

Throughout the active development phase, the Senior DevOps Engineer held demos, and the Cloud Architect conducted internal R&D and PoC deployment for better understanding and SoW adjustments.

Our engineers started to develop the documentation for the internal Nansen team from the preparation stage till everything was cleaned up on production. Thanks to the cooperative approach of in-house colleagues, we could set up our work fast, seeing the boundaries of responsibilities of each side.


Implementation within Dysnix’s dev environment and production stage

We set up our dev environment to map the solution we planned to implement. We created Helm charts for this purpose and prepared all needed to test the connectivity with the validator. 

Also, our engineers controlled all the setup settings and preparations of the infrastructure thanks to the IaC (Infrastructure as a Code) approach. This is one of the most important processes (or methodologies, if you like) we apply to keep our infrastructure easy-editable and make all changes or new features possible to implement in hours, not weeks. 

Our engineers prepared everything for the backups and snapshots creation to keep all the information securely saved and protected. It’s essential to set these things up from the beginning and keep them at hand, as the Ronin blockchain won’t provide you with any snapshots. So we better keep our clients safe than sorry. 

We concentrated on the main task of the project: to make the Ronin validator node isolated yet working. To reach that goal, we decided to implement the layer of so-called sentry nodes that would play two different roles in our infrastructure:

  1. They should become a reverse proxy for blockchain being connected to the internet and our validator node.
  2. These sentry nodes should have RPC functionality for requests.

Thus, with this layer of sentry nodes, we implemented the one-way schema where the Ronin validator node can get information about what’s going on in the blockchain via a p2p connection to the sentry nodes. Still, nothing can connect a validator node directly from the internet.

This solution is fast enough and cost-efficient. It works fine with the existing blockchain infrastructure without delays or longer responses. We offer to proceed to the next level of implementation: to prepare the environment for the validator and connect it with sentry nodes.

After a few consultations and during the live sessions with our engineers, Nansen set up the validator nodes’ environment on their side. Our team supported and controlled the deployment of two validator nodes (the second served as the backup node) in the Google Kubernetes Engine and applied the best secure deployment practices. We advised duplicating the validators node to ensure the functionality from A to Z under any circumstances. 

The first one, the active one, is responsible for holding up a private key, and the second node is typically on standby. If the main validator isn’t available, the stand-by node turns on, and Nansen’s engineers provide access to the private key thanks to the manual switch, and the validator continues its work.  

It seemed the mission was completed! The validator nodes were isolated, sentry nodes ran like clockwork, and the system was checked. It was only one step to the production left. Still, Dysnix engineers continued working over the IaC and Deployment as a code implementation to ensure:

  • Ease of changes in the infrastructure and deployment.
  • Project’s scalability, simplicity of management, as well as fully configurable and controllable changes.
  • Simplicity of scaling any solutions on the projects. 

Armored with these code bases, we could migrate to the production environment seamlessly and for a minimal time. And everything went as planned. 

But while we were dealing with deploying the primary solution on production, Nansen prepared another exciting task for us that we couldn’t refuse to take…

Side quest from Nansen

Nansen management was so satisfied with the intermediary results that decided to strike the iron while it was hot. We got another request for deployment that wasn’t connected with the primary task directly. 

Ronin archive nodes got into our list. As Nansen is a blockchain analytics company, they need fast and wholesome access to all blockchain data that can’t be stored elsewhere than in archive blockchain nodes. 

We know that a typical Ronin archive node has some unpleasant limitations, e.g., typically, it needs around six hours to parse the analytics data from the blockchain for one day. That’s way too slow for Nansen. It’s obvious that we need some kind of “steroids” to make them function faster and still, with a high level of reliability and security, as the client wants. So Dysnix team had to “brush up” archive nodes slightly.  

So to complete this task for an A+ grade, we’ve decided to play with it a little bit differently, still without any magic:

  1. We’ve built up a whole system of archive nodes with manually tuned characteristics.
  2. To keep an eye on them, we’ve added additional monitoring and troubleshooting, as we want to collect as much information as possible about how they act under the typical and nontypical load patterns.
  3. Then we hand-picked the most promising nodes that showed the best performance and cloned them; all the rest were eliminated. 
  4. But even if some improvement has been achieved, we didn’t stop on this. The next step included the work with requests’ flow. We commanded each heavy-weighted request to decompose into a few smaller pieces that could be easily processed by all arrays of nodes instead of clogging and blocking node by node.
  5. We’ve iterated through 2-4 steps for some time to see if any other ways of improvement appeared.
  6. When we decided to demonstrate the renewed archive nodes to the client, they showed the following results: the one-day volume of information parsed in 15 minutes max. 

We’ve managed to decrease the time of the Ronin archive node daily update from six hours to 15 minutes. Nansen's team was pretty impressed with these results, and it helped them to boost their whole service, not only the infrastructure we’ve built for them. 

The main development stage was completed, and we proceeded to the project’s enclosing actions. 

Troubleshooting & maintenance

It took around two weeks for all brushing up activities, clearing up everything on production, and improving the troubleshooting documentation for the internal Nansen team. We picked up the working docs we prepared at the beginning of our cooperation and checked if everything worked as expected. 

Also, we had a series of live troubleshooting sessions where we showed how to deal with different issues with the load or environment settings to reach maximum productivity. In parallel, we edited our documentation to make it accurate according to the latest updates.

To sum up:

After this stage was done, we shook hands with Nansen and proceeded to the “passive” cooperation stage—the support. 


After almost a year of work, the Dysnix team still supports the project.

We maintain the settled level of quality for Nansen, checking the most important indicators of the environment’s health. Also, we continue working on minor improvements that become available on the go.

To support our client efficiently, we build up monitoring, health checking, alerting, and upgrading systems that miss nothing out of sight. 


The most pleasant and beloved platform Dysnix’s engineers use for monitoring is Grafana. First, the main indicators are selected for tracking goals and KPIs of environment functionality. Then we blend all the tracked information into the data pool and pull over the needed indicators on the controller’s screen. 

We review the request volumes, the established connections, reloads, memory and CPU usage, and other indicators. 

The example of a monitoring dashboard used by Dysnix

This and the following dashboards are also available for our client, but they are rarely checked. One Dysnix engineer can control and maintain this system without wasting too much time. 

Request handling performance analysis created for Nansen

We also include these data in monthly reports for Nansen. It’s crucial to have stored data about the system's state, as if the problem occurs, our engineers can track the situation back to the normal state and restore everything as if nothing happens. 

Another view of request handling performance analysis created for Nansen

Regular check-ups

As security stays the most important demand of Nansen, we pay special attention to this matter. Thanks to the regular check-ups we conduct on the system, we ensure that it’s as safe as on the first day we’ve completed it. 


Rolling timely updates is a semi-automated process we conduct for every supported client. We must ensure that everything works quickly and keep the system updated. Thus, the client appreciates that the system we created long ago stays efficient and improves with time. 

This is the true goal of Dysnix support, isn’t it?


Values Dysnix has generated, both expected and unexpected

Solutions implemented by Dysnix have empowered the key competitive advantages of Nansen. As the main field of the client’s business is connected with blockchain analytics, we managed to influence the speed and secureness of inner processes. Improved infrastructure always causes visible benefits for the end customer’s experience and even decreases costs

The main benefits we bring to the table can be summarized into the following categories:

  • Expected and planned values
  • Unexpected benefits and side effects

Expected and planned values are the direct results of the SoW completed in full scale. Such as:

  • Fastest time-to-value: The first results of our work Nansen got in only four weeks. 
  • Fail-proof secured infrastructure: The access to the nodes is completely controllable and can’t be changed from the internet. Still, they are 100% seamlessly functioning.  
  • Reliable base for future improvements: Easy changes, support, and project recovery with Infrastructure as Code and Deployment as code made by our team. Getting these things done means one-for-all positive change for the whole infrastructure. 
  • Continuous support: Dysnix provides worries-free infrastructure maintenance with an accessible team and transparent reporting.  

Regarding unexpected benefits and side effects, we can say that their value cannot be ignored. These points weren’t a part of the main quest for our team, but we’re used to doing everything we can to maximize the benefits for our clients.

  • Vast knowledge sharing: We provided continuous mentoring and consultancy of the in-house Nansen team. We adapted quickly to the pace and style of the client’s teamwork to maximize the experience exchange, deepen the knowledge, and master the skills of responsible engineers.
  • Performance optimization of archive nodes: We decreased the processing time of 1-day Ronin blockchain info from 6 hours to 15 minutes for created archive nodes. Now, nothing can stop this train!

What we have learned from this project

From the technical standpoint, the Nansen tasks weren’t overcomplicated. Most of our processes were run in different variations at other projects. But anyway, we had to stay extremely cautious to keep everything 99.99% uptime and reliably secure. Thanks to our habit of situation modeling, planning, and “what-if” predictive thinking, we can prevent problems and catastrophes before they appear. Things that are established well—work well, as they say.

The second issue that kept our eyes open all the time was the change of plans of our client. That’s an absolutely normal situation when the plans switch their direction for 180 degrees at the end of the day, after a few rounds of interviewing, dozen working hours together with the in-house team, and making one or two experiments. The flexibility of our team causes the adaptability and deep customization of the solutions we provide. That’s why we’re not afraid of new ideas from our clients, ready to try them out with our tools and skills. 

How to get the same level of service from Dysnix

The short guide on how to get our help lies here:

  1. Contact our team.
  2. Schedule a short introduction call.
  3. Let us dive into the details of what you need to be done.
  4. Get an offer of how we plan to solve your task.
  5. Decide if it fits you. Start or bye for now.

We’re open to new opportunities, challenging projects, and extreme investigations. Our engineers will happily dig into the most problematic infrastructures and bring them to functional perfection. We know how to handle our job in the most challenging circumstances, so our clients have no reason to doubt our results. And we’re proud of it.

Things should work efficiently and bring profit.

And if you’re looking for a team like ours, take the first step by meeting us. You’ll get an answer even faster than you expect:
Contact us
Alex Vorona
DevOps Lead
Sharing the in-house secrets of DevOps mastery originated from Dysnix.
Related articles
Subscribe to the blog
The best source of information for customer service, sales tips, guides, and industry best practices. Join us.
Thanks for subscribing to the Dysnix blog
Now you’ll be the first to know when we publish a new post
Got it
Oops! Something went wrong while submitting the form.
Copied to Clipboard
Paste it wherever you like