Concepts
HyperEVM & HyperCore
Hyperliquid is two halves of one chain. HyperCore is the L1 that runs the order book, the perps, and liquidations; HyperEVM is the EVM where Optionbolt's contracts live. A contract on HyperEVM is itself a HyperCore account, which is what lets an option be backed by a real perp and settled against a native price.
Two halves of one chain
- HyperCore is the L1: the order book, the perpetual engine, and the clearinghouse. It margins and liquidates every position natively. One account holds exactly one net position per perp.
- HyperEVM is the general-purpose EVM, secured by the same consensus. Optionbolt's contracts, the clearing core and each writer's
Trader.sol, run here. A contract on HyperEVM is also a HyperCore account, with its own address, position, and margin.
The two are bridged one way in each direction: contracts read HyperCore through precompiles, and write to it through CoreWriter. The reads are synchronous; the writes are not.
Reading HyperCore: precompiles
Contracts read live HyperCore state synchronously through precompiles, and the values match the latest HyperCore state at the moment the EVM block is built. There is no relayer and no external price feed. These are the reads Optionbolt relies on:
| Precompile | Read | Used for |
|---|---|---|
0x807 | oraclePx | The price for moneyness and cash settlement. |
0x806 | markPx | The price HyperCore margins the perp against. |
0x800 | position | The writer's perp cover: signed size, leverage, margin mode. |
0x80a | perpAssetInfo | Size decimals, max leverage, and the isolated-only flag. |
0x80f | accountMarginSummary | Account value and notional, for the rope check. |
This is why Optionbolt runs no oracle of its own: the settlement price is a native read, the very price that already margins and liquidates the perp.
Writing to HyperCore: CoreWriter
Writes go through one system contract, CoreWriter at 0x3333…3333, via a single sendRawAction(bytes) entrypoint: a version byte, a three-byte action id, then the ABI-encoded arguments. Optionbolt uses two actions, a limit order to open or close the perp cover, and a USD class transfer to move margin.
Order actions are delayed a few seconds on-chain (deliberately, so the EVM cannot be used as a low-latency backdoor to the L1), and a failed action does not revert the EVM transaction that sent it. So "mint the option and open the perp" can never be one atomic step.
The rule for every perp-touching path is fire, then verify: send the action, then in a later block read the precompiles and reconcile against what you expected. Minting is two calls, open the cover (transaction one), confirm it landed on HyperCore, then mint against the confirmed cover (transaction two). Nothing assumes an instant fill.
How Optionbolt uses it
The perp cover lives on HyperCore, and HyperCore margins and liquidates it natively. Optionbolt never runs a liquidation engine for the cover; it reacts to what HyperCore already did, which is what the recollateralization auction is for.
Because one account holds one net position per perp, keeping each writer's cover isolated means giving each writer their own account. The factory deploys a separate Trader.sol per writer, a distinct contract address and therefore its own HyperCore account, so a liquidation hits only that writer's position and never another's. EachTrader.sol must be initialized on HyperCore before it can send an action, and that one-time activation is a call the writer makes and funds themselves, covering the HyperCore activation fee, rather than a per-account cost the protocol pays.
Deploying on HyperEVM
HyperEVM produces two interleaved block types: fast blocks (about one second, a small gas limit) for ordinary calls, and big blocks (about one minute, a large gas limit) for heavy transactions. The clearing core is a large contract, so it deploys in a big block; the per-writer Trader.sol proxies are small and deploy in fast blocks.