HyperEVM vs HyperCore: What Bot Devs Need to Know

Every order you place on Hyperliquid settles on HyperCore, not on HyperEVM. That one fact clears up most of the confusion I see when a team ports a strategy over from another chain and starts asking why their Solidity contract can't just call placeOrder. Hyperliquid runs two execution environments on the same validator set: HyperCore, a purpose-built matching engine with a native perps and spot order book, and HyperEVM, a general-purpose EVM chain. They share consensus (HyperBFT) and they can read and write across the boundary, but they are not the same machine. Your strategy has to live on the correct one, and picking wrong costs you either latency or composability.

Here's the split in one paragraph, then the parts that actually bite.

HyperCore is the exchange. HyperEVM is the app layer.

HyperCore is where the central limit order book lives. Placing, canceling, and modifying orders, funding payments, liquidations, mark-price computation, the HLP vault — all of that is HyperCore. There is no Solidity here, no msg.sender, no EVM mempool. You interact with it through signed actions sent to the API, the same channel described in our Python and Rust API trading bot guide. Block times are sub-second and the matching logic is deterministic and native. If your edge is order placement — market making, a directional perps bot, funding capture — it belongs on HyperCore, no debate.

HyperEVM is a standard EVM environment where you deploy contracts: AMMs, lending markets, vaults, anything that needs composability. It has two block types. Fast "small" blocks land in about a second with a modest gas limit; slower "big" blocks land roughly once a minute with a much larger gas limit, and you opt into them by flipping a per-address flag. Miss that detail and a contract deployment that exceeds the small-block gas limit will silently never get included. I've watched people debug that for an hour.

The mental model that keeps you out of trouble: HyperCore is the venue, HyperEVM is the tenant. A tenant can look at the venue's data and can ask the venue to do things, but the venue's own book runs on its own clock.

The bridge: precompiles one way, CoreWriter the other

The two layers talk through two distinct mechanisms, and mixing them up is the classic beginner error.

Reading Core state from the EVM: precompiles. HyperCore exposes read-only precompiled contracts at fixed addresses in the 0x0000...0800 range. From Solidity you staticcall one of them with an ABI-encoded query and get back live Core data — a user's perp position, an oracle price, the L1 block number, spot balances, vault equity. It's synchronous and it reflects state as of the current EVM block. So an on-chain vault contract can read a trader's actual Hyperliquid position and size a hedge against it without any off-chain oracle.

// Read a perp position for `user` on asset index `perp` via precompile
address constant POSITION = 0x0000000000000000000000000000000000000800;

function positionSize(address user, uint16 perp) internal view returns (int64 szi) {
    (bool ok, bytes memory ret) = POSITION.staticcall(abi.encode(user, perp));
    require(ok, "core read failed");
    // decode per the precompile's return layout (szi is signed size)
    (szi) = abi.decode(ret, (int64));
}

Writing to Core from the EVM: CoreWriter. The reverse direction goes through a single system contract at 0x3333...3333. Your contract calls sendRawAction with an encoded action, and that action gets queued and applied on HyperCore. This is how a smart contract places an order, transfers between spot and perp, or moves funds into a vault. The critical gotcha: CoreWriter actions are asynchronous. The call returns immediately, the action executes on Core a beat later, and there is no return value telling you it filled. You do not get a synchronous "order placed at price X" the way a Core API bot would. You emit the intent and reconcile after the fact by reading state back through the precompiles. Treat it like fire-and-confirm, never fire-and-assume.

That asynchrony is the whole reason latency-sensitive strategies stay off the EVM. A market maker requoting hundreds of times a second cannot afford an extra block of round-trip plus a reconciliation read. If tight quoting is your business, build directly against Core, which is exactly how we structure a Hyperliquid market-making engine — the quoting loop never touches Solidity.

Which layer does your strategy belong on?

Run it through three questions.

• Does the strategy's edge decay in under a second? If yes, HyperCore, direct API. Market making and most perps directional bots are here. The EVM round-trip alone can erase the edge.
• Does it need to compose with on-chain contracts — pull collateral from a lending pool, react to an AMM price, settle into an ERC-20 vault? Then HyperEVM, using precompiles to read Core and CoreWriter to act on it.
• Is it periodic and account-level rather than tick-level? Funding-rate capture, rebalancing, liquidation backstops. These tolerate a block of latency, so either layer works, and the EVM buys you programmable, trustless execution.

Funding arbitrage is the interesting middle case. Pure funding-rate arbitrage against a CEX usually runs off-chain against the Core API because you're straddling two venues and want the fastest possible leg-in. But a fully on-chain funding-arb vault that accepts deposits and hedges programmatically lives on HyperEVM, reading the funding rate through a precompile and adjusting via CoreWriter. Same trade, different home, driven entirely by whether you need external composability.

Liquidation bots split the same way. If you're racing to hit underwater positions the instant they cross maintenance margin, you want to be on Core watching the book, the pattern behind a fast liquidation bot. If you're building a keeper that other contracts call, the EVM is your home.

Gotchas worth pinning to the wall

A few things that aren't in the obvious places in the docs:

• Asset indices differ between Core and EVM references. Perps, spot pairs, and tokens are addressed by numeric index in Core actions. Hardcode the wrong index and you'll trade the wrong market with no error. Fetch and cache the metadata at startup.
• Precompile reads are "current EVM block" consistent, not Core-tick consistent. Fine for sizing decisions, dangerous if you assume it's the same instant Core matched an order.
• CoreWriter has no revert-on-reject you can catch. A malformed or under-margined action just doesn't do anything on Core. Always read back to confirm.
• Big-block gas is opt-in per address. Deploy heavy contracts only after switching that address to big blocks.
• The HLP vault is Core-native. If you're modeling it, see how the HLP vault strategy actually works before assuming EVM-side hooks exist — they don't.

The short version: keep the hot path on Core, put composability and trustless settlement on the EVM, and use precompiles to read and CoreWriter to write across the seam. Get that division right and everything else is ordinary engineering.

If you're deciding where a specific strategy should sit before you write a line of it, our team designs the full trading stack and dashboard around exactly that Core-versus-EVM call.