You authorize us to share any/all of the above information publicly to assist people in making their delegation decisions.

I am interested in new technologies. I know several programming languages (python, golang).
Using a modern stack of technological solutions for montoring, load balancing, orchestration (Prometheus, Grafana, Custom exporters, Alertmanager, Ansible, Nginx, docker etc).
Writing useful utilities for various projects. Examples can be found in my github - https://github.com/c29r3
I support an infrastructure of more than 23 dedicated servers (Hetzner).

either horizontally scale sentires or fail2ban pending nature of attack

Cluster communicates over VPN only. OS (UFW) and a VPS based firewall. Node runs as non-root user with read-only filesystem. SSH only possible with private key and only after allowing in VPS firewall to single IP.

Honestly, had a lot of issues in setting up and the docs were not up to date. Lost a few rowan while setting up and lost a few more due to network issues. Would appreciate if you guys can come up with a most uptodate page with all the details.

Started on 2nd March, still running. had some issues inbetween but mostly reliable since March 7.

I admit I don't know how. Would you arrange for a session on how we can protect ourself from a DOS attack?

I really hope you provide us with more time to bring the node back up if it goes down, lost quite a few Rowan because of that.

My nodes-validator in Mainnets:

Solana: https://new.solana.surf/validator/J6hFEnGhsGxTyss6DNW9aNQskPZ98gD8P6Wo1F5MBsCK

Stafi: https://stafi.subscan.io/validator/35ifMgmfAspSpWjSJR6Boo5DbGPRKHBmDXP5UyQqNeqz21jS

Oasis: https://www.oasisscan.com/validators/detail/oasis1qrmexg6kh67xvnp7k42sx482nja5760stcrcdkhm

Akash: https://akash.bigdipper.live/validator/akashvaloper1nd8fjym90f6lqu25xkhqxp7h9f8fx0hq2we4vd

Certik: https://explorer.certik.foundation/validators/certikvaloper19q32eg8lu36xyqe3rfp85t6jwnymrjnsh7zu39?net=shentu-1

Avalanche: https://avascan.info/staking/validator/NodeID-6BB2rz6oSXshkaywH7BnKCE9FCqWVGq5J

Darwinia: https://darwinia.subscan.io/waiting/2oXKybsrYDVvphMxpfYRUcKjsJcUas9nA9r2Lm5ze5cjnrtM

Participation in testnets as a validator: Oasis, Avalanche, Nucypher, KEEP, Casper Labs, Pocket, Akash, Plasm network, Near, Solana, Darwinia, Joystream, Bluzelle, Matic, Celer, Elrond, Stegos, Certik, Stafi, Phala, Bifrost, Crust, Sifchain, CODA/MINA, Orai, Clover, Regen, Compound, Nym, Robonomics, Moonbeam

Oasis (40+ million tokens in stake, ~$8 million), Akash (570k+ tokens in stake, ~$3 million), Certik (160k+ tokens in stake, ~$400k). So, i have a lot experience in operating Tendermint-based validator nodes.

Been active since 2017 and we have a lot of experience running cosmos based chains on multiple networks.

We have our validator active since we discovered Sifchain.

We always have multiple (sentry) nodes and backups in place in case of emergency. The use of VMWare gives us the possibility to fail over to a new server in matter of seconds. In case of disaster we also have offside servers available and ready to take over.

Because we use VMWare on our own baremetal servers, we can user vmotion to move the server to another server without downtime. We already have enough resources and bandwidth to prevent a resource issue.

Because we have a lot experience running cosmos based nodes, we know that it's important to run sentries to protect the validator against DDOS attacks. Also our datacenter has DDOS protection and besides our firewall we take all best practices to protect our nodes.

All of our nodes are only accessible from certain sides (and jump boxes) using a secure VPN and nodes are protected by firewalls. To ensure that we applied the best practices to secure our nodes we make sure that we get a >90 score with Lynis.

We can keep the node running for as long as needed. We will stop our node if Sifchain stops developing which will probably never happen ;)

We have recently been audited by Celo.org and of all the selected validators, chainvibes was one of the four that received 100% score!
https://docs.google.com/spreadsheets/d/1Me56YkCHYmsN23gSMgDb1hZ_ezN0sTjNW4kyGbAO9vc/edit#gid=1110085808

rajjiv-vturbo - humble_staking (tag2113)

Mostly up all the time, once I was jailed for incorrect rights on my local docker group, solved that, another time I performed a graceful reboot of my node (no jailing just a planned restart), so I'm mostly up all the time.

Luckily I work from home, and live in a small-ish town, being able to access my host isn't an issue, important is to know I always have my laptop near me, and once slashing parameters hopefully get more realistic the time window will be sufficient to handle an issue.

I used some scripts to alert me for downtime of Unix processes, I make daily spot checks.

If slashing parameters remain mega short/unrealistic, and if the project itself collapses, otherwise I am generally happy to support aifchain as I believe in what you guys/gals are trying to achieve.

Mateip | bwarelabs.com#1629; Knox | bwarelabs.com #3623

Interacted with multiple projects based on Tendermint, running nodes for networks like Bluzelle, Terra, Cosmos and many others.

We began in Feb 20th still in testnet, and went live on BetaNet in the first week.

Firewall proper configuration with limited connections per source address.

If the network becomes too centralized with few nodes controlling almost the total voting power.

Related to information sharing, we just authorize publishing the validator name EarnX, instead of my name.

https://blockexplorer.sifchain.finance/validator/sifvaloper1zt0u3saj89v2wnxytaty727dyf8z7awzy094px

Both CertiK and Matic run Cosmos/Tendermint. We have also run betanets with Akash and Nym.

When running the one built from source, almost 100% as it runs from a DC. It was no longer running after the March 4 update, where we moved to Docker and for reasons we tried to fix but haven't found out yet why it syncs but is not signing blocks. Ali_the_Curious #2359 kindly helped us and would ping us if a fix has already been found.

Check error logs and health metrics to identify what is causing the problem. Once the cause is identified, then we can try to fix it. We also take note of these event and normally script them so that the same future events can be mitigated automatically.

The DCs we use have built-in DDoS mitigations. We also run our validators in dedicated servers. There are no other services running other than just what the node requires, so it's resources are not shared to other services that can be DoSed.

Yes. We use custom-made bash scripts that monitor the health of the server and the node every minute. These are also programmed to apply known solutions without human intervention.

With each incident email alerts are sent to us with descriptions of what occurred.

The node runs in its own dedicated server, without unnecessary services. We use UFW to open ports that are only needed by the node and SSH. We follow all security hardening best practices for servers. The servers automatically upgrade the OS and services every hour.

Our passion is security and automation. We are Linux systems administrators for decades and who recently got interested in the blockchain.

Participated in testnets of projects such as: Oasis, Akash, Regen, Sifchain, Bluzelle

Close all unused ports on the server. Connect the validator to the network via a sentry node.

I have more than one year experience of participating in testnets. Participated in testnets of projects such as: Oasis, Elrond, Bluzelle, Pocket, Ava, Akash, Keep, Crust, XX-network, Regen, Kira, Stacks, Solana, Mina, Sifchain, Plasm, Agoric, HydraDX

since cosmoshub-2 (you can find blockscape val in cosmoshub-3 genesis)

monitor mempool of all nodes, sentry node architecture, backup node in different location

Yes, prometheus with grafana monitoring, with custom go websocket monitoring( missed blocks, chain health, rewards, val - ranking, alerts)

Is it possible to refund our lost rowan token bacause of offline jailing? The first announcement for the update was to late

We run validators for 2 Tendermint based blockchains and are exploring a number of others.

Our team spans multiple continents/timezones. With our monitoring and alerts in place we can respond preemptively to avoid emergencies. In the event of an emergency we have automated backups in place that we can recover from, and can we readily deploy new infrastructure if required.

Our Kubernetes cluster sits behind a load balancer and our nodes are spread across multiple availability zones.

Alerts configured in Grafana immediately notify us about performance degradation or other issues. AWS CloudWatch alerts as a backup.

My Validator node is connected to only sentry nodes. (Validator node is hidden from DOS attack.

Only SSH login, password disabled, Fail2ban, root login disabled, firewall, sentry, etc

I've developed from the ground up a Cosmos SDK based blockchain/application (Peer-to-Peer, Reverse Auction, Invoice Discounting platform) using Launchpad and just completed the upgrades to Stargate and working on launching a testnet of the chain. So I have a full appreciation of the internals of Cosmos SDK both from a developer, operational and management standpoints.

99.9999999999999%. Missed only 8 blocks with 7 of those blocks happening due to me restarting the service to enable prometheus within the configuration file, which required the service to be restarted for it to take effect, which took less than a minute.

Our instances are located in separate zones as a redundancy, so if one goes down the other will take over fully giving us enough time to bring up another instance. Alerts are setup based on various metrics through Cloudwatch and if any issue arises an alert is sent via email. If it's a case where the validator is jailed we will do our necessary checks to figure out what the issue is before unjailing. To the extreme we might bright up a whole new cluster and test to make sure it's woring properly before trying to unjail to start signing blocks again.

We'll do the necessary health checks on our Instances to make sure everything is ok. If one or more instances are giving issues we will check if memory, cpu or its volume is an issue and make the necessary adjustments. If we see where an additional instance is needed we will bring up another and allow its volume to catch up to the latest block height before adding to the group of instances that our Load Balancer delegates to.

We utilize an Elastic Load Balancer through our AWS setup that distributes the traffic to our two backend EC2 instances to reduce the risk of overloading any one instance and in turn the application. This Load Balancer scales automatically which allows it to manage larger volumes when you have unanticipated extra traffic. If we still see that the stability is lacking we'll increase the number of load balancers.

We utilize an Elastic Load Balancer through our AWS setup that distributes the traffic to our two backend EC2 instances to reduce the risk of overloading any one instance and in turn the application. This Load Balancer scales automatically which allows it to manage larger volumes when you have unanticipated extra traffic.

We are currently utilizing Amazon CloudWatch with simple notification alerts but will be utilizing Prometheus with a Grafana dashboard to monitor our nodes soon.

If it's total unprofitable to do and there is no revenue to continue operating our servers.

Wasn't pleasant, I'd admit - the time to bring back the node is tight and there were almost no guidance to first time node validators.

I'm running node for the first time, just read about DOS attack. I do not know how to handle this, can you help provide training/documents for this?

I submitted a response earlier but provided my address wrongly so re-submitting the form with the right address. My Node is called B3SifNode.

To begin with, I will find out in the discord whether this is a mass error or only concerns my validator, if only mine - I will check the server status and its operation parameters. In case of identification of non-rights - I will solve all problems.

I decided to specialize in the nodes of the cosmos network: DESMOS, BLUZELLE, BITSONG, REGEN, AGORIC

It's very important to have the sentry nodes that I have to prevent this from happening.

Check my VMs health, rummage through logs and monitoring dashboards to make sure everything looks alright. Check netsec groups, firewalls for outgoing connections, resource usage of the VMs, check to see if HEAD is at the latest in the repo, reach out to community to see if someone else already faced and solved the recurrant issues. Manually monitor the VMs for some time.

I'm a Software Engineer by profession currently working in the IoT division of a renowned Equipment manufacturer. My team has a DevOps Engineer, Full stack Engineers based across 3 continents and we're all technology enthusiasts

I do like that Cosmos is a pretty consistent SDK, thus allowing me to more or less remember the details and use it in other projects as well.

Haven't thought about it yet, TBH,, but I have heard about The Sentry Node Architecture

If I will not be able to understand the reason why I'm got slashed for example. If it will require too much attention, which I will not be able to automate

We participated in several testnets, where the Blockchain was based on Cosmos (e.g. Akash, Cosmos itself, IRISnet).

I've participated in several Cosmos-SDK/Tendermint based Blockchain project testnets and I'm currently also running a Bluezelle mainnet node with 100% uptime.

I created my validator on the 22 Feb 2021, 12:44:07pm UTC

I case of an emergency, I'll be notified by my reporting and monitoring system. I'm following nodes best practice setup procedures, run a backup node for my validator - should a problem occur that is not easily solved I can switch my validator to my backup node.

Strict firewall settings and my validator node is isolated from other nodes in the network, and is only connected to their sentry nodes. These are based on different public clouds which are privately and solely connected to our validator node servers which are located in secured colocation data centers. This allows hides the IP address of the validator node and protects my validator node from DDoS attacks.

I have reporting and monitoring in place which notifies me via email and telegram. For monitoring I use PANIC by SimplyVC a well known and trusted Validator for many networks. https://github.com/SimplyVC/panic_cosmos

If I'm not in the active validator set over a longer period of time and running the node is not profitable for a few months, I might need to consider to stop running it.

Our validator journey started back in 2018, with the Game of Stakes (GoS) competition that tested the security of Cosmos' Byzantine-Fault-Tolerance (BFT) based Proof-of-Stake (PoS) consensus algorithm. Later on we have been running Kava node for a year.

Network security measures are already guaranteed by the datacenter provider where we are running the nodes. We use VPN clients to remotely access the servers and private key authentication.

We offer high quality operation services, highly skilled system administrators and more than 4 years experience in blockchain space.

I've developed from the ground up a Cosmos SDK based blockchain/application (Peer-to-Peer, Reverse Auction, Invoice Discounting platform) using Launchpad and just completed the upgrades to Stargate and working on launching a testnet of the chain. So I have a full appreciation of the internals of Cosmos SDK both from the developer, operational and management standpoints.

99.9999999999999%. Missed only 8 blocks with 7 of those blocks happening due to me restarting the service to enable prometheus within the configuration file, which required the service to be restarted for it to take effect, which took less than a minute.

Our validator node is running on the recommended AWS Elastic Kubernetes setup provided by the Sifchain team with worker nodes spread across two Availability Zones for redundancy, so if one goes down the other will take over fully giving us enough time to figure out the issue and bring up another instance to keep our redundant setup in play. Our alerts solutions also allows us to know when something is wrong which allows us to respond in a timely manner as we receive alerts every 5 minutes.

We'll do the necessary health checks on our Instances to make sure everything is ok. If one or more instances are giving issues we will check if memory, cpu or its volume is an issue and make the necessary adjustments. If we see where an additional instance is needed we will bring up another and allow its volume to catch up to the latest block height before adding to the group of instances that our Load Balancer delegates to.

We utilize an Elastic Load Balancer through our AWS setup that distributes the traffic to our two backend EC2 instances to reduce the risk of overloading any one instance and in turn the application. This Load Balancer scales automatically which allows it to manage large volume of network traffic. If we still see that the stability is lacking we'll increase the number of load balancers.

We utilize an Elastic Load Balancer through our AWS setup that distributes the traffic to our two backend EC2 instances to reduce the risk of overloading any one instance and in turn the application. This Load Balancer scales automatically which allows it to manage larger volumne of network traffic.

Within AWS we have setup CloudWatch to track certain metrics and use Simple Notification Service (SNS) to send us notifications of any issues. Looking to also implement Prometheus later on for additional metrics.

We also utilize a monitoring and alert solution called PANIC for Cosmos (https://github.com/SimplyVC/panic_cosmos) which is setup on a separate server on Digital Ocean which sends us notifications every 5 minutes via Telegram.

The email alert is not timely, we purchased the SMS package, and when there is an alarm, the alarm will be sent out via SMS, which can be seen as soon as possible

We are a professional node operator with rich experience in node operation, especially the cosmos series of nodes. I have also developed wallets for cosmos series nodes. We have rich community resources in China