Sources
Written up in November 2026 from the lab’s March 2026 research on connecting HyperCore and HyperEVM, the work behind Prime. CoreWriter’s behaviour is as Hyperliquid documented it at the time of writing.
Hyperliquid runs two environments on one chain. HyperCore is the exchange: spot and perpetual order books, vaults and staking. HyperEVM runs smart contracts. A trader who wants yield on an idle balance, or an order type the exchange does not offer, needs both, and for a long time had to move between them by hand.
CoreWriter closes part of that gap. It is a system contract on HyperEVM, at the address 0x3333…3333, through which a contract can send actions to HyperCore: place and cancel orders, transfer to vaults, stake and delegate, send assets, approve API wallets and builder fees. This note covers what we learned designing Prime, an account built on it.
CoreWriter does not answer back
A CoreWriter call burns about 25,000 gas and emits a log. HyperCore processes that log as an action afterwards. The outcome does not exist yet when the call returns, so the calling contract cannot tell within the same transaction whether an order was accepted or a transfer went through.
Orders and vault transfers are also held for a few seconds before they execute. Hyperliquid’s documentation gives the reason: a contract must not reach the order book faster than a trader using the ordinary route.
In the other direction, read precompiles show HyperCore state to contracts: perpetual positions, spot balances, vault equity, staking delegations and oracle prices. The values are those of the latest HyperCore state when the EVM block was built.
A workflow that spans both sides is therefore a chain of separate steps, and each can fail alone. Take a simple one: withdraw HYPE from a lending market, move it to HyperCore, place a limit order. The withdrawal is an ordinary EVM call and either succeeds or reverts. The transfer is requested in one block and visible in a later one. The order is requested, then held, then accepted or rejected by the order book. Software driving this has to record which step it is on, confirm each step by reading state in a later block, and know what to do if the order is rejected after the funds have moved. Prime’s HyperCore connector sends at most one CoreWriter action per block.
HyperCore’s own permissions are coarse
| Arrangement | What it allows |
|---|---|
| Standard account | One signer, with access to every action |
| API wallet | Trading only, with no limit on what it trades. No transfers, bridging or staking |
| Linked staking account | Full control over the owner’s account |
| Multisig | Every signer has the same access to every action |
None of these can say: this bot may place spot orders in one market, up to this size, and may never withdraw.
Four controls on every action
Prime is a smart-contract account on HyperEVM. Authority runs in a chain. The owner controls the account. The account holds connectors, one per protocol. Each connector exposes a fixed list of actions, and each action has its own rules about who may call it. The account cannot make arbitrary calls: a protocol is reachable only through a connector written for it.
- Agents
- An agent is an address the owner has approved for named actions. A trading agent can be allowed to place orders and nothing else.
- Allowances
- Each connector has a spending limit per token, for example 1,000 USDC for the HyperCore connector. If an agent or a protocol is compromised, the loss stops at the allowance.
- Guardians
- A guardian is a contract that runs before and after an agent’s action and can revert it. Typical checks: the trade price is within 2% of the oracle, the account’s health factor stays above 1.4, total position size stays under a set figure.
- Session keys
- For actions the owner treats as low-risk, a temporary key can sign in the owner’s place. Each action sets how long such a key is valid, up to 60 days, and the owner can revoke it at any time.
The owner can always act directly, and can remove any agent, guardian or session key.
A worked example: scheduled buying from a balance that earns yield
The first product built on the account buys a spot asset at intervals and keeps the unspent balance in a lending market until each purchase.
- The owner signs once to set the lending and HyperCore allowances and to approve the agent.
- At each interval the agent withdraws one instalment from the lending market on HyperEVM.
- It moves the instalment to HyperCore.
- It places a spot limit order at or below the owner’s price limit.
Creating an order is signed with a session key of medium life. Cancelling one uses a longer-lived key, since a cancel is the safer action to leave open. The agent holds no permission to send funds anywhere else.
What the owner still has to trust
- Connector code. It defines what can be called, so it should be immutable and reviewed.
- Agents, within their allowances. An allowance caps a loss. It cannot make an agent’s decisions good ones.
- Guardians. A faulty guardian can block actions that should go through.
- Admin delegation. The owner can hand the right to configure one action to another contract, which some protocol integrations need. The owner cannot take that right back; only the new admin can give it up. It should be used rarely.