Cross-layer Trace
Follow a HyperEVM transaction into HyperCore: receipt, decoded CoreWriter actions, the expected Core effect and the observed Core state — each link labelled observed, inferred or unknown.
See the receipt, every CoreWriter action it emitted, what HyperCore should have done, and what it actually did — with each link marked observed, inferred or unknown.
0x4b65…d949 → RawAction(limit order) → order 558821730696 filledWhy CoreWriter actions fail silently
Order of operations in an L1 block that produces a HyperEVM block.
- 1L1 block built
HyperCore state for this block, including actions sent directly to the API.
- 2EVM block built
Your transaction runs; CoreWriter only emits a RawAction log. Read precompiles see Core state from before this block.
- 3EVM → Core transfers
Tokens sent to system addresses are credited on HyperCore.
- 4CoreWriter actions
Each RawAction is processed. The sender must already exist on HyperCore. Orders and vault transfers are enqueued and executed a few seconds later.
- Sender must already exist on HyperCore
The contract (or EOA) calling CoreWriter must be a HyperCore user before the EVM block is built. An EVM → Core transfer that would create the account in the same block is processed first but still too late: the action is rejected.
- Order within an L1 block
L1 block → EVM block → EVM→Core transfers → CoreWriter actions. Funds bridged from EVM in the same block are available to the action; Core→EVM transfers are only visible in the next EVM block.
- Orders and vault transfers are delayed
To remove any latency edge over the L1 mempool, limit orders and vault transfers from CoreWriter are enqueued and executed a few seconds later. They appear twice in the L1 explorer (enqueue, then execution). Market state can move in between.
- HyperCore validation happens after the EVM transaction succeeds
The EVM transaction only emits a log. Insufficient margin, bad tick size, unknown asset or a non-zero unused field are rejected on HyperCore; the EVM receipt still says success.