Hyperliquid Clarifies the Top Ten Accusations Point by Point: Unveiling the Truth about Solvency, Oracle Machine Mechanisms, and Governance Design

[Block Rhythm] Recently, a well-known project Hyperliquid made a detailed public response to a series of external doubts. These accusations involve sensitive issues such as system solvency, transaction transparency, and governance mechanisms. The project party's clarifications one by one provide important informational references for the entire ecosystem.

In terms of solvency, there are external doubts about the system's $362 million under-collateralization issue. Hyperliquid denied this claim, pointing out that critics overlooked a crucial detail—the USDC reserves bridged through Arbitrum on HyperEVM. According to project party data, the current total amount of USDC is $4.351 billion, sufficient to cover all debts. The discrepancy in this figure suggests that simple on-chain data queries can easily overlook the complete picture of cross-chain assets.

In the allegations of trading volume manipulation, outsiders accused the project of using the TestnetSetYesterdayUserVlm function for fake transactions. The project responded that this is just a functional code of the testnet and cannot be called in the mainnet environment at all. Such security features are common in the testing phase but are misunderstood as vulnerabilities in the production environment.

Regarding user privileges, the project party emphasizes that all fees, balances, and transaction records are visible on-chain, and there are no hidden exemption mechanisms or ways to manipulate airdrop distributions. The transparency of the entire system makes it impossible for any abnormal behavior to go unnoticed.

In the design of smart contract permissions, there are concerns that the CoreWriter module possesses a “God mode,” allowing it to mint coins and transfer funds at will. In reality, this component is merely an execution tool for communication between HyperEVM and HyperCore, and does not have so-called absolute authority.

Regarding the chain freeze mechanism, the project party clarifies that this is similar to a traditional Block hard fork upgrade. In the POPCAT event in November this year, the project did not freeze the first layer network, but automatically enabled security lock measures on the Arbitrum bridge, which is a standard risk prevention operation.

In terms of oracle pricing, a common technical misconception is that a single private key can instantly manipulate prices. In actual design, the HIP-3 oracle is flexibly configured by the deployer, supporting multi-signature schemes such as MPC. The perpetual contract price uses a weighted median algorithm, jointly determined by multiple validators, eliminating single point risk.

Regarding concerns about centralized transaction submission, the project party stated that the 8 addresses only represent the current transaction sending node configuration, and some transactions have been directly processed by validators. In the future, MEV protection and anti-censorship upgrades will also be added.

In terms of the clearing mechanism, the project denies the existence of an unfair clearing cartel. Only HLP (liquidity providers) can act as backup clearers, and participation has no threshold. The vast majority of clearing is conducted through a public order book, ensuring transparent competition.

In response to the accusations regarding the hidden lending agreement, the project party pointed out that the portfolio margin, lending features, and HLP model are all part of the publicly released pre-alpha version, with complete documentation on file. These innovative features are evolving under community scrutiny.

Finally, regarding the concerns that the ModifyNonCirculatingSupply function may change the token supply, the project party clarifies that HIP-1 specifies that the total supply is completely fixed, and this function is only used for display calculations, having no impact on the actual circulating supply.