MIHEY

Hyperliquid is built on a foundation of onchain transparency. A recent article made several claims that are factually incorrect: + Solvency: Every dollar is accounted for; the author failed to count native HyperEVM USDC. + Integrity: Testnet functions are exactly that - testnet only for testing. They cannot be executed on mainnet. + Transparency: Hyperliquid is more transparent and decentralized than all other major venues for perps trading. The entire state is independently maintained by a permissionless validator set and verified through BFT proof-of-stake consensus by each node. Every order, trade, and liquidation is available in real time during execution. Anyone can run a node and index the chain’s state and transitions. No major perps platform comes close to this guarantee for users. See our response to the writer’s individual points below. Claim: The system is undercollateralized by $362M False: The Hyperliquid blockchain state is fully and verifiably solvent. The author excluded the HyperEVM USDC (a publicly announced and much anticipated integration), which exists in parallel to the Arbitrum bridge. Every USDC in circulation on HyperCore is accounted for transparently, by summing up the balances of arbiscan.io/address/0x2df1… and hyperevmscan.io/address/0x6b9e…. At the time of writing, this amounts to 3.989B + 362M = 4.351B USDC on HyperCore. USDC on the HyperEVM can be computed by subtracting 362M from the 421M on the HyperEVM USDC contract (hyperevmscan.io/token/0xb88339…), totaling another 59M USDC on HyperEVM. The sum of the Arbitrum bridge and native USDC balances can be compared against the sum of user balances on HyperCore. As highlighted in the introduction, this exercise of verifying complete system solvency against user balances is uniquely possible on Hyperliquid compared to competitors. The current Arbitrum bridge was an important stepping stone in bootstrapping the Hyperliquid network and will be deprecated as the migration to native USDC is complete, bringing Hyperliquid to parity with other major L1s. Claim: There is retroactive volume manipulation via TestnetSetYesterdayUserVlm False: This is a testnet-only function to allow for comprehensive testing. The author states that “the function’s presence is the problem…capability alone violates the trust model.” Testnet-only features that enable more rigorous testing of edge cases do not undermine the chain’s integrity. The fee schedule on Hyperliquid interacts in a complex way with inputs: user volume, aligned quote token status, maker vs taker, HIP-3, etc. It’s important to test these interactions on testnet, and therefore the testnet chain has a set of admin testing functions that do not exist on mainnet. The related TestnetAddMainnetUser action is to mark a testnet user as having corresponding mainnet state, to avoid DDOS and other attacks that are “free” on testnet. None of these functions are callable on the mainnet state. While the execution source is not available, anyone can verify every trade onchain by running a node, and sum up the values to confirm that volume numbers are reflected accurately in onchain state. Similar to onchain solvency verification against the sum of all user account values, this is possible on Hyperliquid but not on most competitive platforms. Given that this code path is entirely unreachable on mainnet, future development work will entirely compile out this testnet-only logic on mainnet nodes to avoid any possible misunderstanding or misinterpretation. Claim: Some users have special privileges such as fee exemptions or retroactive volume manipulation used to influence the airdrop False: Like system solvency, user balances, and individual trades, the fees paid by any address is available onchain. Each trade along with its fees paid or rebates received are transparently indexed by nodes, API servers, and third party analytics providers. There are no such mechanisms to distort fees, and no such mechanisms could have influenced the HYPE airdrop. Furthermore, the genesis distribution of HYPE is fully available onchain, and users can verify the historical behavior of every such address. Claim: “CoreWriter” godmode can mint tokens, move user funds without signatures, crash random validators and basically do whatever it wants False: The CoreWriter spec is fully documented here hyperliquid.gitbook.io/hyperliquid-do… and replicable in the open source HyperEVM execution. CoreWriter is a way for smart contracts on HyperEVM to send HyperCore actions as part of HyperEVM block execution. It supports various actions that are normally sent by EOAs such as staking and placing orders, but has no such features to “mint tokens, move user funds without signatures, crash random validators and basically do whatever it wants.” This is a fundamental misunderstanding of how HyperCore interacts with the HyperEVM. Claim: Chain can freeze via governance, and no undo function exists Misinterpreted: The chain freezes during network upgrades. There is no undo function because the validators adopt a new binary at that height. This is analogous to how other networks perform hard forks at future heights determined by social consensus. Suspicious activity on POPCAT in Nov 2025 did not cause the L1 to freeze, nor were any user funds frozen. The L1 was entirely operational, and any observer can see the blocks that were produced during this time. The Arbitrum bridge was automatically locked after the incident due to abnormal variation in account balances. As explained above, the Arbitrum bridge is not as secure as natively minted USDC, and therefore requires several conservative automated locking mechanisms as safeguards. The Arbitrum bridge’s locking mechanism is audited and open sourced, and the bridge is being deprecated with the transition to native USDC. Claim: A single private key can set any oracle price instantly: no timelock, no limits Misinterpreted: The author is likely mistaking the HIP-3 oracle updater logic with the validator-operated perps. HIP-3 oracle updates are indeed set by a single address, but this is up to the deployer to configure. The updater address need not be an EOA. For example, current HIP-3 deployers use a combination of MPC and CoreWriter architecture. For validator-operated perps, multiple validators can submit oracle price updates. The final prices are a robust weighted median across major centralized exchanges. There is no timelock and no limits explicitly because these limits make the system less, not more, safe. The events of 10/10 show the danger to solvency if ADL is not accurately triggered in a timely manner during high volatility. Hyperliquid was one of the only venues without performance degradation or a network outage during this time. If Mango Markets or a similar protocol with oracle rate limits were active during 10/10, they would have likely accrued bad debt. Further decentralization will involve other validators actively running independent and open-sourced oracle update binaries. Claim: 8 undisclosed addresses control all transaction submission False: Some transactions are already sent directly from the validators. Some such as orders are not, in order to minimize MEV, but a future upgrade will incorporate this logic for all transactions in a mechanism that is both MEV- and censorship-resistant. The careful consideration of MEV is in response to trader and researcher feedback based on predatory behavior observed on other chains. There is almost unanimous agreement that toxic transaction ordering degrades the end user experience. Ultimately, the validator set is permissionless, and there is no guarantee that validators in the mainnet set are always fully aligned with the ecosystem. A major milestone in decentralization will be solving this problem, including a multiple-proposer block building setup. Claim: There is a liquidation cartel with unfair advantages Misinterpreted: Only HLP may backstop liquidate users, and HLP subvaults are the only addresses in this set. However, depositing into HLP is permissionless, so HLP is a community-owned liquidity vault supporting the protocol. The fact that HLP has privileges is no different from other protocol liquidity vaults. Relatedly, all liquidations are first attempted against the order book, which handles the vast majority of liquidated positions without backstop liquidation. This allows users to keep any remaining collateral, and allows all other users to compete in providing the best price to the liquidation flow, benefitting the liquidated user. Claim: There is a hidden lending protocol with $1M+ supplied and no documentation False: Portfolio margin, borrow lend, and the HLP supplied value were all publicly announced and are currently in pre-alpha rollout. The current documentation can be found at hyperliquid.gitbook.io/hyperliquid-do… and has been progressively fleshed out over the past several weeks. Claim: ModifyNonCirculatingSupply allows changes to token supply False: The full supply of HIP-1 tokens on HyperCore is fixed at deployment. The non-circulating supply is a purely informational number that can optionally mark addresses as “non-circulating” for display purposes. Whether an address is marked as “non-circulating” does not affect execution. This is an example of onchain information that might make more sense offchain, but is not a vulnerability. Thank you to the author for spending the time to verify the execution of Hyperliquid. The fact that this investigation could be done at all proves the transparency and decentralization that Hyperliquid has already achieved. Concretely, Hyperliquid is the only major perps venue where the entire state and every input diff is transparently available to anyone running a node. A similar analysis on any of the other top perp DEXs is impossible. For example, Lighter uses a single centralized sequencer whose execution logic and ZK circuits are unavailable. Aster uses centralized matching and even offers dark pool trading, which is only possible with a single centralized sequencer without verifiable execution. Other protocols with some open source contracts do not have a verifiable sequencer. On Binance, Lighter, Aster, or similar exchanges, it is impossible for anyone other than the sequencer to see a full snapshot of onchain state including order books, positions, and other user information. The centralized sequencer can also upgrade its software without any constraints. On Hyperliquid, the entire state is onchain, which means there are 24 validators executing the same state machine under BFT consensus rules. There is plenty left to do on the journey towards greater decentralization, but it’s important to highlight just how far Hyperliquid and its ecosystem have come compared to competitors. Decentralization is progressive, and Hyperliquid will ultimately be fully open sourced. Hyperliquid is the most transparent of all major venues, even though this leaks advantages to competitors (all of whom are closed source), who can copy Hyperliquid’s innovations more easily. We think this is the correct tradeoff to balance value accrual to the community, speed of innovation, and upholding the values of defi. The HyperEVM execution is open source, and Sprites, an independent community member, maintains a full archival node that powers many important integrations. HyperCore will follow the same path as soon as it reaches feature completion.