CRO Validator evaluation

Most of people and teams teams that operate a validator on CRO Mainnet try to get more "stacking" to get more commissions, to stay on the TOP100. Common arguments are :

  • PROMO: 0% commission until ...
  • 0% commission forever
  • 100% uptime (sometimes with even waranty)
  • Self delegation of XXX CRO
  • 24/7/365 support
  • Decentralization
  • ...

So ... based on that, and all the rest that operator's validator doesn't share, what make a "good validator" ? What does the "best" validator ? Here are some insights that might help you to choose your(s) validator(s).


At, we think knowledge and experience is the most valuable asset and ... maybe one of the most difficult to evaluate, especialy if you don't have specific knowledge yourself. We, at, often compare IT infrastructure to a patient and the IT team who manage it with his doctor.

When the patient is new for the doctor, when the doctor doesn't know the history of the patient, it will be more complex for him to diagnose any problem. If you are a young doctor, you are missing experience from other patients and you might need more time to do the good diagnostic.

IT Infrastructure is the same, when you already faced DDOS attacks, when you see a "flat line" on a graph, when you have some "feeling" that something is working bad, you will be faster to react, find the root cause and tune your infrastructure/validator to assure the best service regarding the circumstances. validator is operated by peoples from IT Team that manage online european bank. Not every speciality is in the team but globally we have ... some knowledge ... some experience ... some IT certifications 😉, especially in AWS where we are hosting our infrastructure.

Validator Hardware

Some operators annonce they are hosting the validator on high-end CPU, 12 cores, 128 GB or RAM. Nice for them, and to be frank, we think they are wasting their money... 

Size matter for boys, but in IT, size of RAM and CPU is not the most important, if you have a Formula1 that can deliver terrabit of data but you are hosting yourself at home ona poor DSL line, you might have the biggest but you are not able to deliver the full power...

At we prefer to adapt our infrastructure than over-provisionning it from the beginning, so that we can keep our € for later, like facing attack or something like that.

In fact we have even already downsized our sentries  ( as the traffic was not as high than expected, we will scale-up again, later, when needed. We will probably downsize also the validator as we are at 10% CPU in peak, nearly no RAM used and very few IOPS on disk... 

In fact ... real hardware like those announced by many validators might be THE most problematic. Real hardware is, for us, a single point of failure. At Kryptor.Network we think that hosting our infrastructore on VM (Virtual Machine) give us more flexibility in case of problem. In case of planned maintenance with the underlying hardware, we just have to stop and restart the instance. We trust AWS for that, ou VM's are ultra fast to restart compared to some HW we know and still operate in real world...

Network connectivity

Network connectivity is important. Any home-hosted validator should be excluded by default, that's what we think at least. Network must be highly reliable, redundant, scalable with a LOT of bandwidth, just in case of, we are on internet, it's still a jungle...

None of the internet home offer can offer that, even if it's fiber, sorry to say that!

Some of the bandwidth provided by DC also offer DDOS protection, that's nice to have, not mandatory for now and we hope still for long time😊.

Kryptor validator is hosted in AWS datacenter, in Ireland for now. By hosting our services at AWS premises, we just have the same internet line than ... Isn't that fun ? 😉


For us, mandatory ! Sentries permit to not expose the validator on internet so that ... nobody can attack it directly. The validator is kind of "hidden" from Internet. Sentries will do majority of the work for him and just present him what's needed. Our sentries talk to our Validator via private IP's. That another layer of security.


Monitoring is just a must have. Monitoring should be done at ... all possible levels and NEVER from the host himself! By order of importance, for us : 

  • Missed_blocks_counter
  • CPU / RAM / DISK / Network ( Sentries + Validator)
  • Basic System / OS availability
  • Number of peers connected
  • ...

And ... monitoring is nice but has no value if you don't put alerting on it ;-) At, all our monitoring is done via Alarms we have on Clouwawtch. Data from Cloudwatch are comming from common AWS metrics, custom Instance metrics or  from scripts running 24/4/365 every minute.

We are fully transparent on tha subject and publish our monitoring data on our Status page :