Hyperliquid Governance Feedback

This letter is addressed to the Hyperliquid development team, hoping that the team can take the time to review this feedback regarding the governance of the Hyperliquid blockchain.

This letter is addressed to the Hyperliquid development team, hoping that the team can take the time to review this feedback regarding the governance of the Hyperliquid blockchain.

I started using Hyperliquid in December 2023 and it is an amazing crypto app. It is easy to use, has a great user experience, and offers some unique features like the vault and the famous HLP. Currently, HLP has over $350 million in assets under management, and anyone can participate in Hyperliquid in a passive way.

After seeing how great the platform is and knowing that Hyperliquid is running as its own L1 blockchain, I wanted Chorus One (Staking Solutions) to participate as an operator on the Hyperliquid chain. I am an employee of Chorus One, one of the largest node operators in the space. Chorus One has been active in the Proof of Stake industry since 2018.

Chorus One joined the Hyperliquid testnet after being whitelisted on October 17 last year. I wanted to share our overall experience on the testnet with the Hyperliquid engineering team, as we have not had the opportunity to interact with them even after joining the testnet for nearly 3 months.

During this time, we have witnessed one of the most successful token launches of 2024: the launch of the HYPE token. At the same time, we have also experienced an interesting and challenging testnet environment. I would like to mention some of the issues I observed, and I hope that these issues will be addressed in the coming days, weeks, or months.

**Testnet Experience**

The testnet experience has been extremely challenging so far. Operators have little knowledge of how to run a node, and the resources available are limited. In addition to this, we are basically exploring in the dark, and we have found multiple issues, including the following:

* Frequent jail time for unknown reasons

At first, we were jailed multiple times, but we didn’t understand why. Since the code was not open source, we couldn’t accurately assess the reasons. The only thing we could do was to communicate with other validators on Discord and guess the reasons together. After talking to multiple validators, we found that everyone was jailed frequently, and they didn’t fully understand why.

* Node location

We later discovered that the jailing issue was probably because we didn’t run a node in Tokyo. Moving the node to Tokyo might have helped. Unfortunately, the team never made this clear and we only discovered this after running into a lot of issues.

After moving the node to Tokyo, the situation improved. This is probably because many testnet nodes with a large amount of staked tokens are also located in Tokyo, so our node can miss fewer blocks and keep up with the pace. However, even after moving the node, we still continue to encounter jail time issues, and we still don’t know the exact reason. This problem is mainly due to the fact that the code is not open source.

* Depends on the automatic jailbreak script

We realized that maintaining good uptime on the Hyperliquid testnet depended on how quickly the script could automatically jailbreak nodes. The only way to improve uptime was to rely on scripts that could automatically jailbreak nodes quickly. Validators could not fully understand or fix the underlying issue and could only automatically jailbreak nodes without a deep understanding.

* Centralized Hyperliquid API as a single point of failure

On several occasions, our jailbreak attempts failed because the Hyperliquid API was down. If the API is down, validators cannot get out of jail on their own because they have to send a request to the Hyperliquid server to get out.

The team may be aware of this, but this design needs to be reconsidered because it makes the API a major single point of failure for the network. If the goal is to build a Byzantine fault-tolerant system, there should not be any nodes with special permissions, such as those that rely on a centralized API.

**Mainnet Validator Selection**

Hyperliquid recently selected about 16 validators in the process of decentralizing its validator set. Previously, Hyperliquid was managed by 4 validators from the core team, which attracted a lot of criticism. Recently, Hyperliquid took a major step and expanded the number of validators from 4 to 16.

Regarding the selection of validators, 4 validators were announced via the following post on Discord:

```

The four validators are Validao, Bharvest, Hypurrstake, and Prrposefulnode. They were selected based on uptime, and they have managed to maintain more than 90% uptime in the past 7 or 30 days.

This is a remarkable achievement for many reasons, primarily because validator performance is also impacted by external factors, such as glitches in the Hyperliquid API, jail issues, and persistent binary crashes, which all have a significant impact on performance.

```

In addition to these four validators selected