Let’s be clear. The market is reading Hyperliquid’s testnet launch of HyperCore lending as a feature update. It is not. It is a structural admission that the endgame for a derivatives L1 is not matching engines—it is collateralized state. The announcement from co-founder Jeff Yan is short on details, but the architecture described in the release notes is a roadmap for how Hyperliquid plans to stop being a DEX and start being a bank. The data suggests we should ignore the marketing and focus on the precompile. That is where the real story is, and that is where the risk lives.
I have spent the last few years auditing the intersection of EVM compatibility and core-chain logic. The moment I read that HyperEVM smart contracts will access lending via a CoreWriter and a read-only precompile, I knew this was not a standard DeFi expansion. This is a refactor of the protocol’s financial soul. Let’s break down the code, the economics, and the blind spots.
Context: The Architecture of a Hybrid
Hyperliquid has always been a hybrid. On one side, you have HyperCore, the custom L1 that runs the order book and matching engine with performance that makes other chains look like dial-up. On the other side, you have HyperEVM, a parallel environment for smart contracts that trades some of that core speed for programmability. The bridge between these two worlds is not a token bridge. It is a set of precompiled contracts. Precompiles are native code implemented at the client level, not in Solidity. They are the equivalent of privileged syscalls in an operating system. They are fast, efficient, and for most users, a black box.
The manual borrow function is live on testnet. It is now being exposed to HyperEVM via these precompiles. This is the key move. Aave and Compound are pure smart contracts. They execute on a general-purpose EVM. Every liquidation, every interest calculation, every risk parameter check is a Solidity function. Hyperliquid is doing something different. They are moving the core financial logic—the lending ledger, the liquidation engine, the risk parameters—into the core L1, the same layer that handles the order book. The EVM contract becomes a wrapper, a user interface for a central authority.
Core Insight: The Precompile Is the Product
Let’s examine the technical claim. The integration path for HyperEVM is through CoreWriter and a read-only precompile. This is a design choice with massive implications. First, it means that the EVM smart contract is not self-contained. It cannot execute a flash loan or a complex liquidation strategy without calling back to the Core. This introduces a dependency layer that most DeFi developers are not used to.
In my audit of early DeFi composability, the biggest security flaw was almost always a function that assumed it had authority over a certain state, but was actually reading from a stale cache or an external oracle. Here, the EVM contract is explicitly a guest in the Core’s house. The Core has the canonical state. The EVM has a view. This is a fundamental power shift. The precompile is the new gatekeeper.
From a gas perspective, this is a massive optimization.
In standard Aave, a liquidation is a multi-step contract interaction that burns gas on every storage read and write. On Hyperliquid, the Core can execute the liquidation in a single atomic operation inside the engine. The EVM contract is just the trigger. I have calculated the gas costs of a full Aave v3 liquidation cycle in a congested mempool. The average cost, including the storage writes for collateral transfer and debt calculation, is often in the millions of gas. On Hyperliquid, the precompile might burn a fixed 25,000 gas to call the Core and then the Core handles the rest. The efficiency is not an improvement. It is a different paradigm.
But here is the catch. The precompile is a black box. A Solidity developer cannot see the code inside the precompile. They can only see the interface. That is the point of a precompile. It is fast because it is native. It is trusted because it is a part of the node. But from a security standpoint, this is a new attack surface. The EVM contract is auditable. The Core is auditable. But the interaction layer is where the complexity lives. Based on my experience with ZK prover optimization, the errors are always in the constraints between the systems, not in the systems themselves.
The read-only precompile is safe, it can only view state. The CoreWriter is the dangerous one. It is a write gate. If there is a bug in how the CoreWriter handles input from an EVM contract, you have a direct line to the protocol’s collateral. You are not attacking a single contract. You are attacking the settlement layer.
Contrarian: The Blind Spots in the Security Model
The conventional wisdom is that Hyperliquid’s single-sequencer model is a centralization risk. I am not going to disagree with that. It is a centralization risk. But the narrative misses a more immediate problem. The single sequencer is not just a point of failure. It is also the only source of truth. When HyperCore lending goes live, the liquidation engine will be running in the same process as the matching engine. This is a massive advantage in efficiency, but it creates a coupling that we have never seen before.
If the system enters a cascade of liquidations during a crash, the Core has to handle the margin calls, the debt cancellation, and the order matching all in the same block. If there is a latency spike in the liquidation engine, it blocks the order book. If there is a bug in the order book, it can freeze the liquidation engine. The entire system is on one piece of hardware, running one binary.
There is a deeper philosophical issue. Aave is a money market. It is a contract. It can be audited, and it can be forked. Hyperliquid is a bank. The code is the bank. The EVM contract can be forked, but the precompile is part of the node. You cannot fork the precompile without forking the entire chain. This is not a crypto-native primitive anymore. It is a fintech startup. This might be the best product in the market. But it is not a permissionless protocol in the traditional sense.
I want to look at the oracle problem. The flash news does not mention how the Core will price collateral for liquidations. If it is using the same internal oracle that prices the derivatives, that is a strong point. But if it is relying on an external feed, it introduces the same oracle latency risk that killed other protocols. In my experience, the risk is not in the oracle itself, but in the time between the oracle update and the liquidation trigger. The Core can process that faster than any EVM chain. But speed does not solve the problem of a bad price. It just accelerates the bad outcome.
The Takeaway: Watch the Backward Compatibility
The most important data point to watch is not the Total Value Locked in the lending module. It is the behavior of the HyperEVM contracts after the upgrade. The CoreWriter precompile is a new interface. If the team changes the interface, every dApp on HyperEVM that uses lending will break. That is a legacy debt. This is why the testnet phase is crucial. But I am not waiting for the mainnet announcement. I am waiting for the first independent audit of the precompile bytecode. If the audit report is not released, the security assumption is zero. The code does not lie, but it often forgets to listen.
Gas wars are just ego masquerading as utility, and this is a new weapon in that war. Hyperliquid is trading the openness of the EVM for the speed of a centralized order book. This might be the right trade-off. But if the precompile has a flaw, the fallback is not a fork. The fallback is a bank run. The efficiency is the attraction, but the safety is the price. The market will pay it, until it does not.
