Compiled by GaryMa (Wu Blockchain Blockchain)
This article summarizes and reviews two recent cases of FUD (Fear, Uncertainty, and Uncertainty) related to Hyperliquid and their official public responses.
I. FUD Incident 1: Suspected team member's address sold short, but it turned out to be a former employee.
Background of the event
Initially, Hype community members discovered an address through on-chain analysis.
0x7ae4c156e542ff63bcb5e34f7808ebc376c41028
The address was continuously selling and short HYPE. Tracing the address's early funding sources, testnet history, and past transaction records revealed a strong on-chain connection to the Hyperliquid development team, Hyperliquid Labs. Subsequently, rumors circulated in the community that "the official team was leading the dumping" or "insiders were profiting from short using undisclosed information/mechanisms," damaging market confidence.
Official response
Subsequently, members of the Hyperliquid team posted on Discord that all personnel associated with Hyperliquid Labs (including employees and contractors) must adhere to a strict code of conduct when dealing with HYPE tokens, including a ban on derivatives trading and a zero-tolerance policy for insider trading.
Regarding the short short address starting with 0x7ae4 mentioned in the community, the team stated that the address belongs to a former employee who left the company in the first quarter of 2024 and currently has no connection with Hyperliquid Labs. Their actions do not represent the team's position.
II. FUD Incident 2: Technical Questions Regarding Centralized Control and Trust Assumptions (Solvency is a Misconception)
Origin of the incident
The incident originated from an article. This article was a technical audit-style analysis based on reverse engineering. By decompiling the Hyperliquid mainnet validator binary files and combining on-chain state and contract behavior, the author attempted to prove that Hyperliquid, under the narrative of "on-chain perpetual contracts," still has significant centralized control and trust assumptions.
The author's core argument is not that "Hyperliquid is necessarily doing evil," but rather that the current design of the system allows for malicious behavior or abuse under extreme circumstances, which poses a risk in the DeFi context.
In response, Hyperliquid published a lengthy article refuting these viewpoints point by point. The following is a compilation and translation by Wu Blockchain.
Hyperliquid's official response (full text)
Hyperliquid is built on the foundation of on-chain transparency. A recent article has raised several allegations that are inconsistent with the facts:
Solvency : Each dollar has a clear counterpart; the author omitted the native HyperEVM USDC.
System Integrity : Testnet functions, as the name suggests, are for testing purposes only and cannot be executed on the mainnet.
Transparency : In the perpetual contract trading space, Hyperliquid is more transparent and decentralized than all other major platforms. The entire system state is independently maintained by a permissionless set of validators and verified by each node through BFT proof-of-stake consensus. Every order, transaction, and settlement is visible in real time during execution. Anyone can run a node and index the chain's state and state changes. No other mainstream perpetual contract platform can provide users with a level of security that comes close to this.
The following are our responses to each of the author's points.
Allegations: The system has $362 million in under-collateralization.
mistake:
The Hyperliquid blockchain state is fully and verifiably repaid on-chain. The authors exclude HyperEVM USDC (an integration that has been publicly announced and highly anticipated), which exists in parallel with the Arbitrum cross-chain bridge.
Every USDC circulating on HyperCore can be transparently accounted for by summing the balances of the following addresses:
https://arbiscan.io/address/0x2df1c51e09aecf9cacb7bc98cb1742757f163df7
as well as
https://hyperevmscan.io/address/0x6b9e773128f453f5c2c60935ee2de2cbc5390a24
At the time of writing, the amount is 3.989 billion + 362 million = 4.351 billion USDC (located in HyperCore).
USDC on HyperEVM can be obtained from HyperEVM USDC contracts:
https://hyperevmscan.io/token/0xb88339cb7199b77e23db6e890353e22632ba630f
The calculation shows that approximately 59 million USDC is located in HyperEVM after deducting 362 million USDC from the 421 million USDC.
Verification can be completed by comparing the sum of the Arbitrum cross-chain bridge balance and the native USDC balance with the total user balance on HyperCore. As emphasized in the introduction, only on Hyperliquid can the overall solvency of the system be independently verified in this way, compared to competitors.
The current Arbitrum cross-chain bridge played a crucial role in the early launch of the Hyperliquid network. As the migration to native USDC is complete, this bridge will be gradually phased out, bringing Hyperliquid's architecture in line with other mainstream L1 blockchains.
Allegation: Manipulation of transaction volume after the fact via TestnetSetYesterdayUserVlm
mistake:
This is a function that exists only on the testnet and is intended to support comprehensive testing. The author claims that "the very existence of the function is problematic...this capability itself undermines the trust model."
Testnet-specific features designed for more rigorous testing of edge cases do not compromise the integrity of the chain. Hyperliquid's fee structure interacts intricately with multiple inputs, including user trading volume, whether the quote token is aligned, market maker/taker identity, HIP-3, etc. These interactions must be validated on the testnet; therefore, the testnet includes a set of administrator functions for testing purposes only, which do not exist on the mainnet.
The related `TestnetAddMainnetUser` operation is used to mark a testnet user as having corresponding mainnet status, in order to prevent DDoS and other attacks launched "at zero cost" on the testnet. These functions cannot be called while in mainnet status.
Although the execution source code is not publicly available, anyone can run a node to verify every transaction on-chain and aggregate transaction volume data to confirm the accuracy of the on-chain state. Similar to verifying the system's solvency and comparing it to the total value of all user accounts, this process is feasible on Hyperliquid, but not on most competing platforms.
Given that this code path is completely unreachable on the mainnet, future development will completely remove this testnet-only logic from the mainnet nodes to avoid any potential misunderstandings or misinterpretations.
Allegation: Some users possess special privileges, such as fee waivers or post-transaction volume manipulation, which they use to influence airdrops.
mistake:
Like system solvency, user balances, and individual transactions, transaction fees paid by any address are also traceable on the blockchain. Every transaction, along with its paid fees or earned rebates, is transparently indexed by nodes, API services, and third-party analytics tools.
There are no mechanisms that distort transaction fees, nor are there any mechanisms that could affect the HYPE airdrop. Furthermore, HYPE's genesis distribution data is completely public on-chain, and users can verify the historical behavior of each relevant address themselves.
The accusation is that "CoreWriter's" God Mode can mint coins, transfer user funds without signatures, and randomly crash validators, allowing it to do almost anything.
mistake:
The CoreWriter specification is fully documented here:
https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm/interacting-with-hypercore
It can also be reproduced in the open-source HyperEVM execution environment.
CoreWriter is a mechanism that allows smart contracts on HyperEVM to send operation instructions to HyperCore during block execution. It supports various operations typically initiated by external accounts (EOAs), such as staking and placing orders, but it does not have the ability to "mint tokens, transfer user funds without signature, randomly crash validators, or do whatever it wants."
This claim stems from a fundamental misunderstanding of how HyperCore and HyperEVM interact.
Allegation: The blockchain can be frozen through governance, and there is no revocation mechanism.
Misinterpretation:
The chain will briefly stop producing blocks during network upgrades. There is no reversal mechanism because validators have adopted the new binary version at that height. This is entirely consistent with how other networks execute hard forks at future heights through social consensus.
The suspicious activity on POPCAT in November 2025 did not result in an L1 freeze, nor were any user funds frozen. L1 functioned perfectly normally during that period, and any observer could see the blocks generated at that time.
Following the incident, the Arbitrum cross-chain bridge automatically locked accounts due to abnormal fluctuations in account balances. As mentioned earlier, the Arbitrum cross-chain bridge is less secure than natively minted USDC, thus requiring multiple conservative automatic locking mechanisms for protection. This locking mechanism has been audited and open-sourced, and the cross-chain bridge will be gradually phased out as the transition to native USDC begins.
Allegation: A single private key can instantly set arbitrary oracle prices, without time locks or restrictions.
Misinterpretation:
The author likely confused the HIP-3 oracle update logic with the perpetual contracts run by validators. While HIP-3 oracle updates are indeed set by a single address, this is dependent on the deployer's configuration and the update address is not necessarily the EOA. For example, current HIP-3 deployers use a combination of MPC and CoreWriter architectures.
For perpetual contracts run by validators, multiple validators can submit oracle price updates, and the final price is derived from the weighted median of multiple major centralized exchanges.
The system does not have explicit time locks or restrictions because such restrictions would actually reduce rather than improve system security. The events of October 10th demonstrate that during periods of high volatility, failure to trigger ADLs in a timely and accurate manner can threaten the system's solvency.
During this period, Hyperliquid was one of the few platforms that did not experience performance degradation or network outages. If Mango Markets or similar protocols with oracle rate limits were operating during the 10/10 period, bad debts would likely have occurred. Further decentralization will involve other validators proactively running independent and open-source oracle updaters.
Allegations: Eight undisclosed addresses controlled all transaction submissions.
mistake:
Currently, some transactions are submitted directly by validators. Others (such as order placement) are not yet handled this way in order to minimize MEV, but future upgrades will extend this logic to all transactions through a mechanism that is both MEV-resistant and censorship-resistant.
The cautious consideration of MEV stems from feedback from traders and researchers based on other on-chain predatory behaviors. There is a near-unanimous consensus that toxic transaction ordering significantly harms the end-user experience.
Ultimately, the validator set is permissionless, and there is no guarantee that validators on the mainnet will always be perfectly aligned with the ecosystem. Solving this problem (including multi-proposer block building mechanisms) will be a significant milestone in the decentralization process.
Allegation: The existence of a liquidation group with an unfair advantage.
Misinterpretation:
Only HLP can act as a guarantor for liquidation of users, and HLP's sub-vault is the only address within this set. However, depositing funds into HLP is permissionless, thus HLP is a community-owned liquidity vault used to support the operation of the protocol.
Furthermore, all liquidations are initially attempted to be completed through the order book, and the vast majority of liquidated positions are processed at this stage without requiring a margin call. This allows users to retain remaining collateral while also allowing other users to competitively offer the best price for the liquidation flow, thus benefiting the liquidated user.
Allegation: A hidden loan agreement existed, with over $1 million deposited, yet no documentation was available.
mistake:
The portfolio margin, lending features, and HLP deposit value have all been publicly announced and are currently in pre-alpha phase. Related documentation can be found at the following address and has been continuously improved over the past few weeks:
https://hyperliquid.gitbook.io/hyperliquid-docs/trading/portfolio-margin
Allegation: ModifyNonCirculatingSupply allows modification of token supply.
mistake:
The total supply of HIP-1 tokens on HyperCore is fixed at deployment time. The so-called "non-circulating supply" is merely an informative field that can selectively mark certain addresses as "non-circulating" for display purposes only.
Whether an address is marked as "non-circulating" has no impact on any execution logic. This is an example of information that might be more suitable for off-chain storage, but it does not constitute a vulnerability.
Thank you to the author for taking the time to investigate Hyperliquid's execution logic. It is precisely because of this investigation that the transparency and decentralization achieved by Hyperliquid are proven.
Specifically, Hyperliquid is the only major perpetual contract platform whose complete state and every input variation are transparently accessible to anyone running a node.
Similar analysis is impossible for any other leading perpetual contract DEX. For example, Lighter uses a single centralized orderer whose execution logic and ZK circuitry are not publicly disclosed; Aster employs centralized matching and even offers dark pool trading, which is only possible with a single centralized orderer and unverifiable execution. Other protocols, while partially open-source, also lack verifiable orderers.
On exchanges like Binance, Lighter, Aster, or similar exchanges, no one except the sorter itself can see a complete on-chain state snapshot, including order books, positions, and other user information. Centralized sorters can also upgrade their software without any constraints.
On Hyperliquid, the entire system state is on-chain, meaning that 24 validators execute the same state machine under the BFT consensus rules. There is still much work to be done on the road to greater decentralization, but it's worth emphasizing how far ahead Hyperliquid and its ecosystem are compared to its competitors.
Decentralization is a gradual process, and Hyperliquid will eventually be completely open source. While this will expose some advantages to competitors (who are all closed source) and make it easier for them to replicate Hyperliquid's innovations, Hyperliquid believes this is the right trade-off between balancing community value accumulation, the speed of innovation, and adhering to DeFi values.
HyperEVM's execution layer is open source, and independent community member Sprites maintains a complete historical archive node, supporting several important integrations. HyperCore will also follow the same path once it is fully functional.
Related Links
Employee's blockchain address before leaving the company:
https://dev.hypurrscan.io/address/0x7ae4c156e542ff63bcb5e34f7808ebc376c41028
Official response to team members selling short:
https://discord.com/channels/1029781241702129716/1030197017655394447/1452511033758580828
Analysis of technical audit-style articles based on reverse engineering:
https://blog.can.ac/2025/12/20/reverse-engineering-hyperliquid/
Official response to misunderstandings about solvency, centralized control, and trust assumptions:
