Validator Introduction -

Entity name and location
Coinhall, Singapore

Infrastructure location
US Central / US East / Europe

What kind of hardware do you run? Baremetal, cloud-based…? In what geographic regions?
We run cloud-based in the US region and baremetal in the Europe region.

Technical make-up of team (elaborate on no. of dev ops engineers, experience, etc.)
Purely on DevOps end, we have 4 DevOps engineers with a combined 17 years of experience. As a company, we have other functions such as front-end and back-end engineers that support other products and services.

Years of experience
2 years running validators and full nodes for various Cosmos-based chains.

What other networks are you running validators for?
Terra, Terra Classic, Juno, Persistence, Osmosis, Cosmos Hub, Stride, Neutron, Archway, Migaloo

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?

Best Practices:

  • Test extensively. When an upgrade of the binary version is required, ensure sufficient testing has been done on testnet. Also, follow a fixed process flow for governance and upgrades. If changes need to be made to the flow, ensure proper communication with the affected parties.

  • Provide clear and precise documentation for validators and users of the chain. Documentation should include how to set up, how to use the chain, and troubleshooting.

  • Multiple checks of the correct go version within the go.mod file will ensure all binaries were built with the correct version. We have seen app hash errors due to this. Ideally, mention which major go version to use.

  • Post-mortem from the foundation after the problem has been resolved is useful to ensure mistakes are not repeated and show a strong commitment to the chain’s health and future.

  • Always maintain archival snapshots. It does not have to be publicly available but available upon request.

  • Multiple channels of communication to the validators (e.g. Discord announcement channel, Telegram, Emails)

Things to avoid:

  • Stray from the process flow that worked on testnet. We have seen upgrades work smoothly on testnet but still cause a chain-halting event because the proper process flow was not followed on mainnet.

  • Run incentivised testnet without a good understanding of the outcome of the tasks requested.

Do you have a validator voting framework and process?
We monitor all proposals with our internal tooling and dashboards. Depending on the complexity of the proposal, the decision framework and process will differ. Ultimately, as validators, we believe that it’s our duty to act in the interest of our delegators and the chain.

The governance coordinator will review each proposal and discuss it with the internal committee for diverse perspectives. External opinions from the community through forums and social media are also gathered and taken into consideration. Some questions to point us toward a vote:

  1. For parameter change/upgrades/deployments: Is this proposed change safe for the chain/protocol/users?

  2. For community spend: How will the proposal impact the community and chain in the short, mid, and long term in relation to the value created through the proposed funds?

Are you planning to play any additional roles in the dYdX ecosystem (e.g. market maker, trader, indexer, front-end, other)?
Planning on contributing as an indexer operator and potentially as an alternative frontend for trading via dYdX. Coinhall currently aggregates >10 dexes and our aggregator protocol has facilitated close to $2B in tx volume.

We are also happy open-source contributors who typically share our solutions once we’ve tackled them. We are currently maintaining an open-source Cosmos repo and frontend tool library (check out CosmES below)

Are there other products or services you want to highlight that could be relevant for dYdX?
Seer (by Coinhall) will be most relevant for dYdX - a real-time data indexing infrastructure for the Cosmos ecosystem.

Genie (by Coinhall) is a Web3 campaign platform for players within the dYdX ecosystem to utilise to target their ideal audience. By aligning the incentive mechanisms, Genie can help players to boost their onchain metrics and create productive loops in the ecosystem.

We also develop open-sourced tools such as CosmES, a tree-shakeable, framework agnostic, pure ESM alternative of CosmJS, and Cosmos Kit for dYdX alternate frontends to utilize.

Any notable contributions in other ecosystems that you would like to highlight for the community?
The Coinhall team strongly believes in building the best end-user applications in Web3. Coinhall (, the unified data and trading hub for Cosmos. We currently support Neutron, Injective, Terra Classic, Terra, Osmosis, Juno, Kujira, and Near. Users can access real-time price charts and liquidity pool analytics, giving them information to perform aggregated swaps across AMM DEXes.

1 Like