Execution order and timing

HyperCore and the HyperEVM are two engines in one L1 block, and they run in a fixed order. Before your contract acts on a read, know what the read reflects, when the action runs and what can happen in between.

Four steps in one L1 block

Per the docs, on an L1 block that produces a HyperEVM block:

1. The L1 block is built.
2. The EVM block is built; every precompile read in it sees HyperCore as of this moment.
3. EVM to HyperCore transfers are processed.
4. CoreWriter actions are processed.

Say one transaction reads a balance and sends an order. The read reflects HyperCore at step 2; the order runs at step 4, landing 0.35 to 0.51 s after the EVM block on mainnet. If HyperCore refuses it, your transaction has already succeeded.

A CoreWriter sender must exist on HyperCore before step 2; a same-block transfer that would create it still leaves the action rejected.

Only vault transfers carry a multi-second delay. Everything else measured lands within about half a second of the block that sent it.

Most actions land within half a second

Each delay is the HyperCore ledger time minus the timestamp of the EVM block holding the RawAction log. Orders leave no ledger update, so fills were matched on the cloid in each action 1 payload. The mainnet sample covered blocks 46,080,800 to 46,154,714; testnet action 17 was polled from before submission, so a known-old sample brackets the transition.

Action	Network	n	Delay after the EVM block	In the docs’ delayed set
2 vault transfer	mainnet	6	4.052 to 4.104 s	yes
1 limit order, cloid-matched fills	mainnet	52	0.347 to 0.514 s; mean 0.412, sd 0.039	yes
6 spot send	mainnet	6	0.006 to 0.441 s	no
7 USD class transfer	mainnet	6	0.346 to 0.458 s	no
13 send asset	mainnet	6	0.009 to 0.419 s	no
17 split and merge	testnet	6	same block, 0.01 to 0.68 s	no
1 resting limit order	testnet	3	same block, 0.75 to 0.82 s	yes

The 52 fills span 15 accounts and 14 markets, including spot pairs and builder-deployed perps. A fill 0.41 s after its block proves acceptance within 0.41 s, which a 4-second enqueue would make impossible.

The official docs differ

The docs say orders and vault transfers sent from CoreWriter are delayed a few seconds, to remove any latency advantage from bypassing the L1 mempool. On mainnet only vault transfers were, by about 4.05 s (n=6); orders landed 0.35 to 0.51 s after the EVM block (n=52), like actions the docs never called delayed. On the evidence, the delayed set is at most vault transfers.

The numbers

Parameter	Value
Order within an L1 block	L1 block, EVM block, EVM to HyperCore transfers, CoreWriter actions
HyperCore to HyperEVM transfer	queued until the next HyperEVM block
HyperEVM to HyperCore transfer	same L1 block, right after the EVM block
Vault transfer delay	4.05 to 4.10 s (mainnet, n=6)
Order delay	0.35 to 0.51 s, mean 0.412 s (mainnet, n=52)
Actions 6, 7, 13	under 0.46 s (mainnet, n=6 each)
Action 17	same block (testnet, n=6)
Mainnet sample	5,455 actions, 73,914 blocks, about 20.5 hours
Testnet block interval	0.95 to 1.00 s

Two legs are two actions

Two legs sent through CoreWriter (an order and a hedge, a split and a quote) are two HyperCore actions. They land close together, but either can be refused while the other goes through.

Nothing here is atomic

Pair	Why
The EVM transaction and the action	The transaction has finished before step 4 and succeeds either way
Two actions in one transaction	Each is processed alone; a failed second does not roll back the first
A credit and a spend	Spending a same-block EVM to HyperCore credit was not measured. One production mainnet deposit supplied its funds 3 blocks after bridging, and the vault contracts behind this site assume an earlier block
A read and an action	Reads are as of step 2 and the action runs after step 3, so any ratio computed (a share price, a collateral value) is stale when the action lands

Same-block deposits share one snapshot, since neither action has run when the block is built. A vault that settled each by comparing a fresh read to its own snapshot minted shares for both when only one was funded. The fix is a cumulative figure every settlement must clear, plus one deposit in flight at a time (patterns).

Allow for lateness: one hardened vault design on testnet waits 5 blocks (FAIL_DELAY) before marking a deposit failed, and stops settling a pending deposit after 1,200 blocks (SETTLE_WINDOW).

Limits of the measurement

Caveat	Detail
Action 17 on mainnet is inferred, not measured	None fell in the 73,914-block window, and only 4 in a 3,000,001-block scan. No testnet action showed any delay, so testnet cannot separate “action 17 is not delayed” from “testnet does not delay”
Two outlier fills were excluded	+8.348 s and +16.982 s: resting limit orders that filled later. They bound fill time, not acceptance time
The clock has coarse ticks	EVM block timestamps are whole seconds and ledger times milliseconds; the 4-second vault gap is far larger than that rounding
One testnet trial read N-1	Causally impossible: skew between the eth_blockNumber and eth_call round trips. Block counts carry about one block of noise; the timestamp column is tighter
The first action 17 measurement was retracted	Sampled once, 3.67 s after submission, it could not tell same-block from any shorter delay; the table above is the re-run
Delayed actions in the explorer	Shown twice, per the docs: first the enqueuing, then the execution

For the delayed set and other contradictions, see where the chain and the docs disagree.