Simply Staking - Validator Profile

Start Here Validator Profiles
1

About Simply Staking

Simply Staking is a team of security and computer engineers operating blockchain infrastructure on multiple PoS blockchain networks, both in test and live environments.

The group operates infrastructure out of its own Tier 3 datacentre, with various backup sites across the globe, and a policy against the use of cloud providers. Our PoS infrastructure includes multiple layers of sentries per network, hosted locally and at colocated servers of ours. Some of these are private and locked down, serving also as backup validator nodes, and others are public to provide the rest of our infrastructure with better global peer connectivity.

Why Private Infrastructure?

We believe that new, decentralised public infrastructure requires a set of independent, geographically distributed validators operating their own private infrastructure. The fact that many validators rely on cloud infrastructure puts this vision of a decentralised future in jeopardy, by inadvertently centralising networks on a handful of cloud networks that are owned by large corporations.

How long have we been active

We are one of the original validators that formed part of the genesis of the Cosmos Hub back in 2019 and have expanded our ecosystem validators and contributions ever since.

What Networks we support

We offer validation services for many tendermint-based chains including;

  • Cosmos Hub, Osmosis, Juno, Secret Network, Regen Network, Akash, Sommelier, Agoric, Lum Network, Stargaze, Quicksilver, Tgrade, Gravity Bridge, Bitsong, Desmos, KI Chain, Persistence, Crescent, E-Money, IXO and Omniflix.

We are also active contributors on multiple ongoing Testnets, both pre-live and alongside mainnets, to ensure the security and stability of the chain.

Apart from tendermint-based chains we also validate on ETH2, Oasis Network, CELO, Pocket Network and Substrate based chains such as Polkadot, Kusama, Moonbeam and Moonriver. We also are an Oracle and Node operator for Chainlink.

Validator Infrastructure products and contributions in the ecosystem

Monitoring

We use a combination of Prometheus Alertmanager, Grafana and PANIC to monitor everything from block signing, syncing, hardware metrics, network statistics, Ethereum transaction monitoring and much more. Escalation policies are set per network that enable alerts to be routed between the relevant team members through Opsgenie. We also use Zabbix that performs automated tasks for issue fixing.

We provide swift and immediate incidence response via our engineering team who are on call 24/7.

Governance

We have a newly formed dedicated team who monitors and manages governance proposals. The team will discuss and share their thoughts with a select few more individuals who give their input and have meaningful discussions.

Simply Staking recently integrated Authz thanks to the efforts by the new team in order to increase participation across the growing number of networks that are handled.

Community Participation

We maintain an active Twitter account @SimplyStaking. We also have multiple of our team members who are active in the space who engage in discussions and threads with the rest of the ecosystem.

Our Socials & How to connect with us!

3 Likes
2

Hey, I have a question for you about your sentry setup and btw, super great intro!

“multiple layers of sentries”

so, like this:

1 validator → 3 sentries → 3 sentries for each of the validator’s 3 sentries?

or something else?

thanks!

3

Hey Jacob!

We have the usual public sentries (between 2-5 depending on the network), however on some networks we also have private sentries which are connected to known peers and our own. I guess “multiple layers” sounds like there’s a deeper tree of sentries.

In reality these are mostly useful in case there’s a p2p ddos exploit and in scenarios where the primary validator node has issues. In the past, we tried a validator → private sentry → public sentry setup, but that turned out to be overkill. As the number of validators grow on some networks, even the public sentry layer starts to inhibit optimal performance.

This will most likely not be relevant once we implement a distributed signer like horcrux, as there’ll be no primary node.

1 Like
4

Thanks a lot!

Love hearing about how others do it.

Our setup varies from chain to chain but default mode is without sentries.

gives us a big old global network of nodes, and when we think we need to use sentries, our validators connect to nodes that are used to serve rpc endpoints by cosmosia