Full disclosure: Let's publish validator operations & infrastructure info 📖

Full disclosure on Figment Networks’ Cosmos validator infrastructure and operations: https://twitter.com/FigmentNetworks/status/1136000871463104512

Let’s get :speaking_head: about how to make staking on Cosmos as secure as possible, and let’s be open :open_book: for delegators to make informed decisions.

Spread the word: more transparency and a stronger, more secure Cosmos network :muscle:

Medium article here

Thanks Gavin, we will be publishing something soon for Neptune Stake and I think this is a great initiative.

Something I would also like to see added to the block explorers, is some way to indicate which validators are using an HSM versus software keys, as I think its an important consideration for delegators.

Im not aware of any way to do this automatically, but even a community verification for HSM and correctly setup infrastructure would be very beneficial for the community.

This would both inform delegators which validators have properly setup infrastucture, and also encourage validators that dont to improve their setup.

1 Like

Thanks Guy, it would be nice to have a badge or something to indicate HSM-based validators. But verifying that would open a whole can of worms that we’re not prepared to handle at the moment. We’d be open to chatting with anyone else who is interested in implementing this sort of thing :+1:

1 Like

HSM based validation is not the only secure solution. We use a custom remote signing sever, which is similarly secure. If you want to prove that your setup is really secure, get audited from a 3rd party and publish the results. Feel free to get in touch with us https://www.ethermat.com

If you want to go a step further get certified… ISO27001 etc.

We strongly believe that the ecosystem might profit from non-HSM validators. If all deployments were the same, potential attacks would have a critical impact. Mixed validators with different deployment styles and (custom) software strongly add value to the ecosystem.


Here’s Chainflow’s -

In describing the architecture, I again am trying to strike a beneficial balance. This balance is between providing transparency, while not compromising operational security.

1 Like

we did publish some along the way


We will be disclosing ours soon in a medium post and also our learnings along the way. Will update here!

1 Like

Great idea!

We’re already providing documentation about our infrastructure through our website: https://validator.network.


  • Using YubiHSM inside redundant isolated hosts
  • Redundant validators hosts

Redundant, dedicated bandwidth to AWS Frankfurt where we operate multiple public sentry nodes in different availability zones.

We’re doing 24x7 monitoring via Pagerduty on logs and Prometheus data and have developed in-house tooling for improving observability.

20+ years of experience operating secure and highly available IT infrastructure.


You can find a description of our validator architecture and some operations info here:

We also tweet when we’re performing maintenance, noting if there was downtime/missed blocks, and also have published a postmortem for our first outage:

This would be interesting, especially if HSM-backed validators could publish cryptographically signed attestations of how they are storing keys as a sort of (trusted hardware-based) “proof” of how their consensus keys are generated/stored.

Unfortunately I just checked if the YubiHSM2’s attestation features were capable of attesting Ed25519 keys and it appears that’s not supported (it only appears to support attestation for RSA and ECDSA keys).

1 Like

We have just published our setup and some learnings here: http://bit.ly/SetupAndLearnings

We will continue to publish articles on some tools we use and more learnings along the way. Happy to discuss infrastructure related issues!