Entity name and location
Tessellated is a firm that runs validators and provides consulting based services to networks out of the USA.
Our infrastructure runs in US-East and US-West.
What kind of hardware do you run? Baremetal, cloud-based…? In what geographic regions?
We run all of our nodes on dedicated, bare metal machines provided by Latitude.sh. All of our signing infrastructure runs on physical machines which we own.
Technical make-up of team (elaborate on no. of dev ops engineers, experience, etc.)
Our primary engineering lead is Keefer Taylor. Outside of his work at Tessellated, Keefer has served as a Cofounder of several DeFi protocols (Kolibri, Moonwell), built and contributed to MEV solutions (Polygon Fastlane Contributor, Tezos Flashbake Contributor, Advisor/Contributor Skip).
We work with a variety of part time contributors to help cover on-call shits, biz-dev and governance on an as-needed basis and hope to expand the team in the near future.
Years of experience
We’ve run validator nodes since 2018, and have run our first CometBFT based validator on the CosmosHub starting in 2020. We now run over 16 nodes, 8 of which are CometBFT based.
What other networks are you running validators for?
We run nodes on Axelar, Avalanche, Cosmos Hub, Celo,Ethereum, Evmos, Gravity Bridge, Juno, Mars, Neutron, Oasis, Osmosis, Polygon, Sommelier, , Stride, Tezos
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?
WRT best practices: automation and monitoring are really important to get worked out on testnet. It’s gest to find edge cases in your automation in low stakes environments, and as you find them, we often find edge cases our monitoring doesn’t catch, so we add tests for that.
We love remote signers, and we use them for all of our infrastructure. It helps build confidence in our ability to use automation without risks of double signing, and when combined with HSMs (which we also use) gives us confidence in our security.
Regular backups / standbys of nodes are also important, because even with all the monitoring and infrastructure in the world, nodes will always find new and interesting ways to go down and you need to be able to recover quickly.
Do you have a validator voting framework and process?
We don’t publish a framework, but we always try to vote in the best interest of networks and our delegators and are always available to chat through things on Twitter.
We use a combination of Slack bots, authz, and Asana task tracking to make sure we track and participate in governance votes, since we believe this is part of our job as a validator.
Are you planning to play any additional roles in the dYdX ecosystem (e.g. market maker, trader, indexer, front-end, other)?
We hope to release some CometBFT specific tools soon which help validator run relayers and manage their keys in automated ways.
We’re also in the process of spinning up relayers, and will run them for any network we support, including dYdSX.
- Are there other products or services you want to highlight that could be relevant for dYdX?
- Any notable contributions in other ecosystems that you would like to highlight for the community?