CoreWriter Actions: Complete Reference
CoreWriter is Hyperliquid's system contract for sending supported HyperEVM-originated actions into HyperCore, using versioned action IDs and ABI-encoded payloads.
CoreWriter is the write-side counterpart to Hyperliquid's read precompiles. A HyperEVM contract calls the system contract at 0x3333333333333333333333333333333333333333 with an encoded action. HyperCore later processes supported action types such as orders, transfers, staking operations, API-wallet operations, builder-fee approvals, account changes, and borrow/lend actions. It is a constrained protocol interface, not arbitrary write access to HyperCore.
Encoding model
The payload begins with an encoding version, followed by a three-byte big-endian action ID, followed by raw ABI-encoded action-specific data. Current documentation supports encoding version 1.
Versioning matters because contracts that hard-code byte layouts without checking the protocol's current interface can become incompatible when new actions or versions appear.
Execution and gas
The system contract burns gas before emitting the log that HyperCore processes. Official documentation describes roughly 25,000 gas burned by the system step and approximately 47,000 gas for a basic call in practice, before application-specific overhead.
An EVM transaction succeeding means the contract call was accepted at the EVM layer. Builders should still reason about whether the resulting HyperCore action is valid and when it becomes effective.
Timing and delayed actions
Order actions and vault transfers sent through CoreWriter are intentionally delayed onchain for a few seconds so a HyperEVM route cannot create a latency advantage over the native L1 mempool.
Within an EVM-producing L1 block, the documented processing sequence is L1 block, EVM block, EVM-to-Core transfers, then CoreWriter actions. A contract trying to initialize a HyperCore account with a transfer and use CoreWriter in that same EVM block can therefore be rejected because the account needed to exist before the EVM block was built.
Action families
The live documentation should be treated as the definitive action registry. Current surfaces include trading-related actions, vault transfers, staking, token or asset movement, account and API-wallet management, builder-fee approvals, and Portfolio Margin borrow/lend operations.
Do not infer an action exists because an equivalent REST Exchange action exists. CoreWriter supports an explicit subset with explicit encodings.
Security design
A contract using CoreWriter is effectively gaining the ability to initiate native financial actions from its own HyperCore identity. Authorization, amount bounds, recipient validation, reentrancy assumptions, and emergency stops should be reviewed at the application layer.
Keep the raw action encoder small and well tested. Integration tests should cover invalid inputs and timing, not only happy-path execution.