Full disclosure on Figment Networks’ Cosmos validator infrastructure and operations: https://twitter.com/FigmentNetworks/status/1136000871463104512
Let’s get 
about how to make staking on Cosmos as secure as possible, and let’s be open 
for delegators to make informed decisions.
Spread the word: more transparency and a stronger, more secure Cosmos network 
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.
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 
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.
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!
Great idea!
We’re already providing documentation about our infrastructure through our website: https://validator.network.
Datacenter:
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).
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!
We just published our infrastructure to our website: https://freshatoms.com/
We do not have automatic failover yet, for fear of slashing, but we can get the spare node and signer running nearly seamlessly in case of maintenance (missing 0 to 3 blocks max), or on alert (in case of failure) within minutes of receiving the alert (which is monitored 24/7).
KIRA Staking, architecture overview and disclosure -> https://medium.com/kira-core/kira-cosmos-hub-validator-db1828264506
Does the broader Cosmos Hub community have the right to explicitly know, and distinguish, whether or not certain Validators are the same entity, direct partners, etc?
(Instead of opening a new conversation, saw this thread captured the general sentiment of the question above)
How is a user to know if certain COI’s exist within the Validator set when choosing to delegate?
At this point, who is to say if Validator X is, or is not, Validator Y, or Validator Z? In the spirit of securing true decentralization, is publishing validator operations & infrastructure info “enough?”
Curious to hear others thoughts.
Fascinating to see validators blatantly ignore these questions, which would serve as a net benefit for all small/new validators, delegators, and users, to be made fully aware.