Entity name and location
We are registered in the Netherlands since 2014.
What kind of hardware do you run? Infrastructure location?
Our network services run entirely on bare-metal at three different datacenters: Los Angeles, Philadelphia and Amsterdam. For the sake of infrastructure diversity, which increases the resilience of the network, we do not use any cloud providers or rent capacity at the usual providers (OVH, Hetzner, DigitalOcean etc).
Technical make-up of team (elaborate on no. of dev ops engineers, experience, etc.)
Eddie: infrastructure & DevOps.
Antonio: software development and DevOps.
Years of experience
Our team has been developing and operating high availability PCI-DSS and HIPAA-compliant systems since 2002. We got involved in blockchain in 2013 and started running masternodes in 2016. In 2018, we launched our first validator.
What other networks are you running validators for?
dYdX, Celestia (genesis), Cosmoshub, Osmosis, Sommelier, Regen (genesis), Stargaze (genesis), Secret (genesis), Juno (genesis), Neutron (genesis), Stride (genesis), Quicksilver (genesis), Ethereum, Near (genesis), Polygon, Skale (genesis), Mina (genesis), Terra (genesis), Terra Classic.
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?
We have participated in more than two dozen genesis preparations and ceremonies. By far, the most successful launches consistently show the following components.
- Clear, up-to-date documentation.
- An active Discord’s validator channel, which should be restricted to prospective genesis enabled operators to decrease noise.
- Network team members designate one person to be constantly present in this channel, answering questions or consulting with the team for questions he/she can’t answer.
- The point of contact for validators in this channel ideally is the one coordinating additions and updates to the documentation and helping foster a sense of collective ownership and responsibility.
- Discord tagging/alerting is used effectively: validators can sign up to receive only communication relevant to validators, not alerts about quizzes/meme contests/AMAs/etc (though they can also optionally request a role to also be notified of those other types of announcements)
Do you have a validator voting framework and process?
Our governance decisions are based on three criteria, in order of importance. Our goal is to maximize:
- The benefit to the network’s health and longevity.
- The benefit to all delegators.
- The benefit to the validators.
We have alerts set to enable us to stay on top of governance for each network we operate on. For contentious proposals, we engage in discussion on the chain’s forum or on Twitter. Our delegators are encouraged to reach out to us on Discord, Twitter or email.
Are you planning to play any additional roles in the dYdX ecosystem (e.g. market maker, trader, indexer, front-end, other)?
We will run a public RPC and relayers for dYdX.
Are there other products or services you want to highlight that could be relevant for dYdX?
We have some repositories on our GitHub with tooling for Cosmos SDK chains. One of the tools we created and maintain is featured as a recommended tool by the Chain Registry: GitHub - gaia/chain-registry-query: CLI tool to query the Cosmos Chain Registry.
Any notable contributions in other ecosystems that you would like to highlight for the community?
With a robust monitoring and alerting system, we are quick to respond to on chain and off chain events, both in maintaining our infrastructure and in responding to concerns of fellow validators and delegators.
We are members of the Validator Commons and the Staking Defense League.