Validator Introduction - Chainflow

Hello everyone, we’re Chainflow and were founded in 2017 by decentralization activist Chris Remus to accelerate the development of a more inclusive, equitable, and fair economy. We’ve since grown into one of the most active teams working in Web3’s staking economy, operating secure, high-performance validators on many of the leading Cosmos networks.

Entity name and location
Chainflow. Global.

Infrastructure location
Europe with the ability to deploy as needed in Asia and an interest in deploying in underserved regions like South America and Africa

What kind of hardware do you run? Baremetal, cloud-based…? In what geographic regions?
Hybrid, bare metal for validators, bare metal, and cloud for sentries.

Technical make-up of team (elaborate on no. of dev ops engineers, experience, etc.)
We have experience running on Cosmos chains since joining the Cosmos Validator Working Group in October 2017. We currently have 3 DevOps engineers. Before that, our team did data center, telecom, and IT infrastructure work for a government defense organization and transnational financial/credit card processing services.

Years of experience
25+ years of telecom, data center, and IT infrastructure experience. 5+ years crypto infrastructure experience.

What other networks are you running validators for?
Agoric, Akash, Canto, Cosmos Hub, Flow, Juno, Neutron, Osmosis, Oasis, Polygon, Quicksilver, Regen, SKALE, Solana, Stargaze, Stride, Sui, and The Graph

Based on your participation in any previous testnets, mainnets, are there any best practices to be aware of? What are some things that made previous testnets, mainnet launches successful and/or things to avoid that have gone poorly?
Do not rush and take a phased approach to the testnet. Plan for breaks in between phases to apply lessons learned from previous phases. Focus on clear consistent communication. A single source of truth for validator communication is helpful. Give appropriate notification and lead time when asked to do things. Clearly communicate expectations generally & specifically if required. Make sure that there is an alignment between what the team is providing and expectations from validators. ex: if docs are not detailed, thorough, or incomplete be aware of that when responding to validator questions. Essential characteristics of a successful testnet are aligned expectations, consistent/concise communication, and considerate timing.

Do you have a validator voting framework and process?

  • We have a bot that alerts of proposals
  • Once the proposals are voted on we log the reasoning and decision on our website
  • We also keep track of our participation rate on proposals

Are you planning to play any additional roles in the dYdX ecosystem (e.g. market maker, trader, indexer, front-end, other)?

  • Contribute to the improvement of governance on dYdX
  • Advocate for a diverse and decentralized validator set
  • Support smaller and independent activist validators

Are there other products or services you want to highlight that could be relevant for dYdX?

*Cosmos mission control is partially compatible with dYdX and we can update it to be compatible with any cosmos based chain.

Any notable contributions in other ecosystems that you would like to highlight for the community?

  • We’ve helped charter the Validator Commons
  • We’ve held a few AMAs for the Agoric’s community
  • We held a validator workshop at Nebular and sponsored the summit both times
  • We created the Cosmos Validator Mission Control
  • 2017 Working group to launch Cosmos Hub
  • Helped multiple chains plan/launch their incentivized testnet such as Regen and Akash
  • Providing active feedback to Observatory Zone
  • Chartered the Staking Defense League
  • Regen redelagting 30% of earnings to support smaller validators
  • to track the NC for several Cosmos networks such as Agoric, Osmosis, and Regen
  • Active in ICS testnets
  • Provided feedback to Atom 2.0