Origins and Founding of Hyperliquid
The Problem: DeFi's Speed and Trust Issues
Hyperliquid is a high-performance decentralized exchange (DEX) built on its own Layer-1 blockchain, created to combine the speed and experience of centralized trading with the transparency of DeFi. It was founded by Jeff Yan (CEO) and a team of engineers with backgrounds in elite academia and high-frequency trading. The team started as a successful crypto market-making firm on centralized exchanges, but by late 2022 they grew frustrated with the flaws in existing DeFi protocols (e.g. exploitable market structures and poor efficiency).
The FTX Catalyst and Vision
The collapse of FTX in 2022 further underscored the need for trustless trading venues, convincing them that the world was ready for true on-chain finance. In response, they decided to build a fully decentralized exchange that could match CEX performance and user experience – something not achievable on existing Layer-2s like Arbitrum due to throughput constraints.
Building a Custom Layer-1 Solution
To do this, the team built Hyperliquid's own Layer-1 with a fully on-chain order book, aiming for sub-second trade finality and high throughput while keeping users in control of their funds. This approach merges the best of both worlds: Hyperliquid offers a seamless, fast trading experience comparable to a centralized exchange, yet all trades and funds remain on-chain and user-controlled.
The "No VC" Philosophy
Notably, the founders also chose not to take VC funding, aligning with a "user-first" ethos – they prioritized building a product that users love, without the typical short-term pressures of token sales or investor demands. After extensive R&D through 2021–2022, Hyperliquid launched its mainnet (along with its HYPE token) around late 2022, and quickly gained traction among traders for its low latency and transparency.
HyperCore and HyperEVM: Dual Architecture and Integration
Hyperliquid's dual architecture combines a high-performance trading engine (HyperCore) with an EVM smart contract layer (HyperEVM) under one chain. The Hyperliquid blockchain is essentially two tightly-coupled parts: HyperCore (the core exchange engine) and HyperEVM (the general smart contract platform). Importantly, these are not separate networks – both run on the same HyperBFT consensus and share a unified state, so there's no need for cross-chain bridges between the exchange layer and the EVM layer.
HyperCore: The High-Performance Trading Engine
HyperCore (Core Layer): This is Hyperliquid's custom Layer-1 optimized for on-chain trading. HyperCore manages all order book state for spot and perpetual markets, plus related functions like margining, clearing, and oracles. Every order, trade, cancel, and liquidation is processed on-chain through HyperBFT consensus, meaning there's a single canonical sequence of transactions (no off-chain matching engines).
Performance Metrics
HyperCore achieves remarkable performance: blocks have one-block finality with sub-second latency (median ~0.2s for an order to be final) and the network currently supports about 200,000 orders per second throughput on mainnet. This high throughput comes from a highly optimized execution engine and consensus; in fact, the bottleneck is the execution logic and not the consensus, which could scale to millions of TPS as needed.
Consensus and User Experience
Consensus is achieved via HyperBFT, a Proof-of-Stake BFT protocol (derived from HotStuff) where validators propose blocks in proportion to stake. For users and traders, HyperCore's performance means on-chain trades settle almost instantly (often under a second) and orderbooks can handle high-frequency updates similar to a centralized exchange. In short, HyperCore is the specialized trading engine L1 that provides Hyperliquid's signature speed and throughput, all while maintaining on-chain transparency and self-custody.
HyperEVM: The Smart Contract Layer
HyperEVM (EVM Layer): This is an Ethereum-compatible execution environment integrated into the Hyperliquid L1. HyperEVM allows developers to deploy and run smart contracts (Solidity, Vyper, etc.) just like on Ethereum, but with direct access to HyperCore's functionality. Because it runs on the same chain/consensus, HyperEVM smart contracts can interact with HyperCore synchronously and trustlessly (no bridging or oracles needed for core data).
Dual-Block Architecture
In practice, HyperEVM inherits the fast block times and finality of HyperCore, but it introduces a novel dual-block architecture to balance speed and contract complexity. Specifically, Hyperliquid splits EVM throughput into "small/fast" blocks and "large/slow" blocks interleaved in sequence. Fast blocks occur every 1 second (initially ~2 million gas each) to give low time-to-confirmation, while slow blocks occur every 60 seconds (initially ~30 million gas) to accommodate bigger or more complex transactions.
This dual-block design decouples latency from block size – users get lightning-fast confirmations on simple transactions, while developers can still execute large contract deployments or loops in the slower blocks. (For example, a dApp can flip a flag to use a big block when deploying a large contract, then switch back to small blocks for regular quick interactions.)
EVM Compatibility
Aside from the block structure and using HYPE (Hyperliquid's native token) for gas, HyperEVM behaves like a standard EVM chain. It supports the usual JSON-RPC methods (you can add Hyperliquid to MetaMask via chain ID 999), and it's compatible with Ethereum tooling (Hardhat, Foundry, ethers.js, etc.) for contract development and deployment. The key difference is that HyperEVM provides built-in hooks to interact with HyperCore, giving developers first-class access to the exchange's primitives.
Integration Between HyperCore and HyperEVM
The most powerful aspect of Hyperliquid is how these two layers interoperate in one state. Hyperliquid provides special system contracts and precompiles that make it easy for EVM contracts to read from and write to the HyperCore exchange.
Reading HyperCore Data (Precompiles)
HyperEVM includes a set of precompiled contracts at reserved addresses (0x…800, 0x…801, etc.) that expose read-only data from HyperCore. Smart contracts can call these precompiles via staticcall to fetch the latest core state within the same transaction. For example, at address 0x...0807 there is a precompile that returns the current oracle price of any perpetual contract.
Hyperliquid's docs provide an L1Read.sol interface contract that maps human-readable functions to these precompiles (e.g. oraclePx(uint32 index) will static-call 0x...807 under the hood). Other precompiles allow querying a user's perp position, spot balance, vault equity, funding rates, asset info, etc., all directly from HyperCore's state.
The return values are deterministic and correspond to the exact state at the time of the EVM block, since the EVM block is built after processing Core actions up to that point. In essence, a Solidity contract on HyperEVM can get real-time on-chain price feeds, order book data, and account info without relying on oracles or off-chain APIs.
For instance, a lending protocol could call a precompile to fetch the live price of an asset on HyperCore and use it to calculate collateral ratios within one transaction. From a developer perspective, using these precompiles is as simple as calling a library function, but under the hood it's tapping into HyperCore's live order books – a very powerful capability.
Writing to HyperCore (CoreWriter Actions)
In addition to reading data, Hyperliquid enables smart contracts (and EVM users) to invoke HyperCore's functionality via a special system contract often referred to as the CoreWriter.
This system contract lives on HyperEVM at:
0x3333333333333333333333333333333333333333
When an EVM transaction calls this address with a properly encoded payload, the contract will emit a log (event) that the HyperCore layer interprets as a HyperCore action. In other words, the EVM contract "writes" to HyperCore by asking the core engine to perform an action like placing an order, transferring funds, etc. The log is picked up and executed as part of the L1 block processing.
For example, a smart contract could call CoreWriter with an action to place a limit order on a perp market, or to trigger a liquidation on HyperCore – all from within Solidity code. Under the hood, using CoreWriter burns a small amount of gas (~25k for overhead, ~47k total for a basic action call) and then hands off execution to the core engine.
This design maintains a clean separation: HyperEVM contracts can request core operations, but the actual matching/clearing logic runs in HyperCore's native code (ensuring speed and security). It's worth noting that as of mid-2025, write capabilities on mainnet were still being rolled out carefully (HyperEVM was in alpha, with full write permissioning in testing).
A major upgrade on July 5, 2025 enabled the CoreWriter on mainnet, unlocking direct programmatic trading and other advanced use cases for dApps. This means that now contracts can not only read prices but also execute trades or other actions atomically, opening the door to things like on-chain arbitrage bots, automated liquidation mechanisms, and complex DeFi protocols built entirely on one chain.
Transfers and Asset Linking
Because HyperCore and HyperEVM form one chain, moving assets between the two "layers" does not involve a traditional cross-chain bridge – instead, it's more like transferring within different subsystems of one network. HyperCore handles native assets (called "Core spot" tokens) which can be linked to ERC-20 representations on HyperEVM ("EVM spot" tokens).
Every spot asset in HyperCore is identified by a system address (a special address starting with 0x20… that encodes the asset ID) which acts as that asset's account on both Core and EVM. To enable an asset to be used on HyperEVM (for smart contracts) and on HyperCore (for trading), the asset must be linked via a governance-free process by its deployer.
The Linking Process
In practice, linking means ensuring the total supply is consistent across Core and EVM and telling HyperCore the address of the ERC-20 contract. For example, if you create a new token on Hyperliquid, you could deploy an ERC-20 on HyperEVM and then call a HyperCore action to register ("link") that contract to a new Core asset ID. Conversely, if a token already exists on HyperCore, you deploy a matching ERC-20 and then link it.
The linking process involves two steps: (1) the token deployer sends a requestEvmContract action on HyperCore with the ERC-20's address and decimal info, and (2) a finalizeEvmContract action to confirm linking (the confirmation must come from the same EOA that deployed the contract, or via a preset storage slot if deployed by a contract).
Seamless Asset Movement
Once linked, assets can freely move between Core and EVM. A user can convert a Core asset into its ERC-20 form by doing a Core spotSend to the asset's system address, which triggers a system transaction on HyperEVM that calls transfer() on the ERC-20 contract to mint tokens to the user's EVM address.
Conversely, when a user sends an ERC-20 token to the system address on HyperEVM, it burns/deducts those tokens and credits the equivalent amount to the user's balance on HyperCore (detected via the ERC-20's Transfer event to the system address). All this happens within the same block – for instance, an EVM-to-Core transfer is applied in the very next Core block after the EVM transfer.
The result is a seamless experience: users can deposit assets into Hyperliquid's exchange and withdraw to the EVM side (and vice versa) almost instantly, without external bridges. It's worth emphasizing that HYPE (the native token) doesn't even use an ERC-20 contract on HyperEVM – it's treated as a native currency on the EVM side, so transferring HYPE from EVM back to Core is as simple as sending a transaction with that HYPE to the 0x222...2222 address (the system address for HYPE).
This design eliminates classic bridge risks because HyperCore and HyperEVM share the same security and consensus – value moving between them never leaves the chain. From a development perspective, linking assets requires careful handling of decimals and total supply (HyperCore uses fixed-point with 6-8 decimals for prices, etc., whereas EVM tokens typically use 18 decimals).
Hyperliquid documentation notes that no automatic check enforces correct supply or ERC-20 compliance during linking, so developers must ensure the ERC-20's implementation and initial mint are correct. (For instance, the mainnet PURR token was deployed with its entire 600 million supply pre-minted to HyperCore's system address [0x20...0001] so that Core held all tokens from the start.) Once linked, though, using the token in smart contracts is no different than a normal ERC-20, and the token's liquidity on HyperCore's order book becomes available as a building block for any dApp.
The Power of Unified Architecture
HyperCore and HyperEVM work in tandem: HyperCore provides the high-speed financial primitives (trading, clearing, margin, etc.), and HyperEVM provides the general programmability to compose those primitives into new applications. This tight coupling enables novel DeFi use cases that would be cumbersome elsewhere.
For example, a lending protocol on Hyperliquid can directly read real-time market prices from the on-chain order book to decide when to liquidate a loan, and even execute the liquidation trade on-chain via HyperCore, all within one atomic transaction. Similarly, projects can launch new tokens permissionlessly on HyperCore (via an auction or listing) and immediately utilize those tokens in smart contracts (since the token can be an ERC-20 on HyperEVM with the same unified liquidity).
This unified state design – where the exchange layer and contract layer are one – differentiates Hyperliquid from typical dual-layer setups. There's no need for price oracles, no fragmented liquidity between L1 and L2, and no delay in moving assets around to use in different protocols. However, it's still early: HyperEVM is in alpha with some advanced features (like higher throughput settings and certain system calls) still being refined. But even at this stage, Hyperliquid's HyperCore+HyperEVM architecture has proven to be a game-changer for on-chain trading and DeFi by offering the speed of a centralized platform and the composability of Ethereum on a single network.
Building on Hyperliquid: Developer Experience and Feasibility
From a developer's standpoint, building a decentralized app on Hyperliquid will feel familiar in many ways, since HyperEVM is EVM-compatible and supports standard Solidity and TypeScript workflows. That said, there are some unique aspects and early-stage considerations.
EVM Compatibility: Familiar Development
If you're already experienced with Solidity (for smart contracts) and TypeScript/JavaScript (for web3 integration), getting started on Hyperliquid is straightforward. You can use existing Ethereum dev tools like Hardhat, Truffle, Foundry or others to compile and deploy contracts, just by pointing them to Hyperliquid's RPC endpoint and chain ID (HyperEVM uses chain ID 999 for mainnet).
Wallets like MetaMask can connect to HyperEVM easily – the network can be added via Chainlist or manually by inputting the RPC URL and chain ID. Gas fees are paid in HYPE (similar to paying ETH on Ethereum), and contract deployment/use follows the same process as on any EVM chain. In short, Solidity "just works" on HyperEVM.
Developers can write contracts in Solidity or Vyper, test locally (there are Hyperliquid testnets available), and deploy to HyperEVM using the same scripts they would use for Ethereum or Polygon. The learning curve for basic deployment is minimal.
Unique Tooling & Standards
Because Hyperliquid is a newer ecosystem (with HyperEVM launched in 2024–2025), some tooling is less mature or slightly different from Ethereum's. For example, block explorers exist for Hyperliquid (the official explorer is at explorer.hyperliquid.xyz for HyperCore and a separate one for HyperEVM) but they may not be as feature-rich as Etherscan. When developing, you might rely more on logs and Hyperliquid's own APIs for debugging.
Additionally, Hyperliquid introduced custom token standards: HIP-1 and HIP-2 for native assets and liquidity provisioning. These HIP tokens serve similar purposes to ERC-20 but are tailored to HyperCore's environment (e.g. HIP-1 is a native token interface that can integrate with the trading engine). If you deploy a standard ERC-20 on HyperEVM, it will work, but to fully utilize HyperCore's features (like getting fee rebates or using the token as collateral), you may need to implement or interact with the HIP standards.
This means a developer should spend some time reading Hyperliquid's documentation on HIPs and native asset deployment. The good news is that the core team provides guides – for instance, how to deploy a token that conforms to HIP-1 (native) and then link it as an ERC-20 (if needed). Auditors reviewing Hyperliquid contracts will need to be aware of these standards and the semantics of HyperCore actions.
Overall, while the fundamental programming model is EVM, you'll encounter additional libraries (such as the L1Read.sol and CoreWriter.sol provided by Hyperliquid) and new concepts (like "spot indices" or asset IDs) that require careful implementation. Since the platform is evolving, certain features (e.g. full big-block throughput, some precompiles, etc.) might be marked experimental or alpha – so reading up-to-date docs is crucial.
DeFi Superpowers: Liquidity on Tap
Hyperliquid is especially well-suited for DeFi applications, and experienced DeFi developers will find it opens up exciting possibilities. Because your smart contracts can directly query live prices and trade on the built-in order book, you can build things like:
Lending/Borrowing with Instant Liquidations
Write a lending contract that uses HyperCore prices to check collateral in real time and, if needed, calls the CoreWriter to sell collateral on the order book the moment a loan is undercollateralized. This removes reliance on keeper bots or off-chain liquidators – the protocol itself can be the liquidator, leading to more efficient and transparent risk management.
On-Chain Trading Strategies
Build arbitrage or algo-trading bots entirely on-chain. For example, a contract could monitor two markets' price via oraclePx() and execute a cross-market arbitrage by placing orders on HyperCore, all within one transaction. The high throughput and fast finality mean such strategies could feasibly keep up with market conditions (whereas on slower chains, on-chain arb is nearly impossible in real-time).
Composable Financial Products
Design new derivatives or structured products that settle against HyperCore's markets. Since HyperCore offers robust perp markets, a contract could use those as components – e.g. an index fund token that periodically rebalances by trading on HyperCore, or an options protocol that hedges using perp orders, etc. The key is that Hyperliquid provides deep liquidity and reliable pricing inside the same sandbox.
This drastically lowers the complexity of launching a new DeFi project because you don't need to bootstrap liquidity from scratch – you can tap into Hyperliquid's existing order books.
Unified UX
From a user's perspective, a dApp on Hyperliquid can offer a seamless experience: users trade or lend or swap all on one chain, with one wallet. For example, a user could trade on the Hyperliquid exchange and then directly put the obtained assets into a HyperEVM vault or farm without waiting for bridges or confirmations across chains. As a developer, this means you can build "CEX-like" DeFi apps where, say, a yield strategy contract can trade in and out of positions on the order book instantly to optimize yield.
All these are much harder to achieve on other platforms due to fragmented liquidity and latency issues. Thus, for DeFi developers, Hyperliquid can be a playground to build novel apps that leverage instantaneous, on-chain liquidity. The main constraint will be ensuring your contract handles the HyperCore interactions correctly (e.g. accounting for the fixed-point formats of prices, handling potential reverts from Core actions if an order doesn't fill, etc.). Testing on Hyperliquid's testnet with realistic scenarios is highly recommended to get these details right.
Non-DeFi and General DApps
HyperEVM is a general smart contract platform, so you are not limited to financial applications. It's possible to deploy NFT projects, games, social dApps, or any usual Ethereum dApp on Hyperliquid. These will benefit from the chain's fast confirmation times and low fees. For instance, an NFT marketplace on Hyperliquid could offer near-instant trade settlement, and a blockchain game could use Hyperliquid to ensure quick state updates.
However, one should consider the audience and ecosystem: currently Hyperliquid's user base is heavily oriented towards traders and DeFi enthusiasts. There may be less native demand for, say, NFTs on Hyperliquid compared to networks that specialize in them. Additionally, certain amenities we take for granted on Ethereum (like widely used oracle networks, NFT indexers, etc.) are not yet present or are in very early stages on Hyperliquid.
If your dApp needs price feeds from outside Hyperliquid's own markets (for example, an NFT game needing an ETH/USD price), you might need to integrate a cross-chain oracle or feed data in manually, since Chainlink and others are not live on Hyperliquid at this time. On the flip side, Hyperliquid is integrating with cross-chain infrastructure (e.g. LayerZero) to make it easier to bring assets and data from other chains. As of 2025, bridging stablecoins and other major tokens from Ethereum is possible via third-party bridges, so non-DeFi projects can still access liquidity in a roundabout way.
General feasibility: any Solidity contract that doesn't specifically need an Ethereum-specific feature should run on HyperEVM with little to no changes. But developers should be mindful of using the correct RPC endpoints, and perhaps the lack of some developer conveniences (for example, there might be fewer analytics tools or subgraph/indexing services for Hyperliquid at present).
You can build non-financial dApps on Hyperliquid, but the platform's strengths (and community support) currently lie mostly in DeFi. Teams venturing outside of DeFi on Hyperliquid might be pioneers in their domain, which is both an opportunity (to stand out, leverage a growing chain) and a challenge (to attract users in a finance-centric ecosystem).
Development Experience & Learning Curve
For someone well-versed in Solidity and TypeScript, the difficulty of building on Hyperliquid is moderate. The fundamental smart contract development is the same as Ethereum, so you won't struggle with the basics. Where you'll spend extra time is learning Hyperliquid's extensions and best practices.
For example, understanding how to format and sign a HyperCore action (if you ever need to send actions from an off-chain service or a contract) is a new skill – Hyperliquid provides an API and even an official Python SDK for composing and signing L1 actions if needed. If you stick purely to on-chain Solidity, you'll need to learn the usage of the L1Read precompile interface and handling the data it returns (e.g. converting the fixed-point price to a human-readable value by applying the correct decimals, as shown in the PriceOracleReader example).
From an auditing perspective, there are new considerations too: you must review that a dApp correctly trusts HyperCore data (which is generally safe since it's on-chain, but you want to ensure the contract doesn't mis-handle edge cases like missing data or unexpected values). You'd also check that any CoreWriter calls are done safely – e.g. if your contract places an order, did you ensure it won't fail mid-transaction and how do you handle partial fills or no fills? These are logical issues an auditor would think about given the integration with an external trading engine.
Security-wise, the Hyperliquid team has had their bridge and core components audited by firms like Zellic, but as a dApp developer you should still exercise caution when dealing with things like linked assets (double-checking that an ERC-20's code is standard before treating it as a stablecoin, for instance, to avoid malicious token contracts).
Ecosystem and Support
One encouraging factor is that Hyperliquid's ecosystem is growing rapidly, which means resources and community support are increasingly available. As of mid-2025, Hyperliquid's HyperEVM had nearly $2B TVL and over 175 teams building on the chain, including a range of DeFi protocols (DEXs, lending platforms like Hyperlend and Felix, liquid staking like Kinetiq, etc.). This growth indicates that if you encounter issues, there's likely a community of developers who might have solved similar problems.
Hyperliquid's documentation (on GitBook) is quite comprehensive, covering everything from running nodes to using precompiles, and the team appears active in updating it (features like token linking were documented with examples as soon as they rolled out). Additionally, community-built resources are emerging: for instance, HypurrCo and Hyperliquid.wiki provide directories of tools and how-tos, and there are tutorials (QuickNode published a guide on reading HyperCore prices in a smart contract, etc.). Hyperliquid's Discord/X (Twitter) also serves as a place to ask questions. All of this reduces the difficulty for a new developer coming in.
It's also worth noting that Hyperliquid's "no insiders" philosophy means there wasn't a long private beta – developers got access to HyperEVM at the same time as everyone else. So while that meant fewer pre-built integrations at launch, it also means everyone has a fair shot now to build the "killer app" on Hyperliquid, with the core team welcoming to community contributions (and a bug bounty program in place for security issues).
Bottom Line: Feasibility Assessment
Bottom line: If you know Solidity and TypeScript, you can absolutely build on Hyperliquid. The challenge is less about coding difficulty and more about understanding Hyperliquid's paradigm: it's a bleeding-edge chain that blurs the line between exchange and smart contracts. Once you grasp the concepts (order books, precompiles, dual-blocks, etc.), implementing a dApp is quite feasible.
Many developers report that the experience is like a mix of building on Ethereum and on a high-performance order book API simultaneously – a combination that can be very powerful. Given the early-mover advantage and the platform's focus on DeFi, a capable Solidity/TS developer could build an interesting and impactful dApp on Hyperliquid with relative ease. Just be prepared to do some reading and testing to get acquainted with Hyperliquid-specific features, and to iterate as the platform evolves.
The result, however, could be uniquely rewarding: you'd be deploying on a network that offers CEX-level speed in a DeFi setting, enabling user experiences and financial products that were previously out of reach for on-chain applications.
Sources: The information above was gathered from Hyperliquid's official documentation, developer guides, and interviews with the founders and community. Key references include Hyperliquid's GitBook (technical docs on HyperCore/HyperEVM), an interview with CEO Jeff Yan explaining the project's vision and genesis, and third-party analyses of Hyperliquid's architecture. These sources provide further detail on Hyperliquid's design and are cited throughout for verification.