# Canonical: https://www.uddalak.xyz/hyperliquid-academy/article/82-hypercore-orders-from-hyperevm-smart-contracts
# Author: Uddalak Das
# Last source: https://www.uddalak.xyz/hyperliquid-academy/article/82-hypercore-orders-from-hyperevm-smart-contracts

---
title: "Placing HyperCore Orders From HyperEVM Smart Contracts"
description: "HyperEVM contracts can submit supported HyperCore order actions through CoreWriter, but the path is deliberately slower than the native order route and should be used for composable application logic rather than latency-sensitive trading."
pillar: "Architecture & Build"
track: "Architecture & Build"
cluster: "Architecture & Build"
level: "Advanced"
primary_icp: ["builder", "smart contract developer"]
secondary_icp: ["trader"]
content_type: "guide"
reading_time: "3 min"
last_reviewed: "2026-09-07"
last_verified: "2026-09-07"
volatile: true
prerequisites: ["81-corewriter-actions-complete-reference", "17-order-types"]
related: ["68-market-making-on-hyperliquid", "94-production-grade-hyperliquid-trading-bot"]
---

# Placing HyperCore Orders From HyperEVM Smart Contracts

CoreWriter makes it possible for contract-controlled strategies to interact with HyperCore order books. The contract encodes the supported order action and calls the CoreWriter system contract. HyperCore processes the action after the EVM block under the documented timing rules. Order actions are intentionally delayed by a few seconds to prevent contracts from bypassing the native trading mempool for a latency edge.

## Why contract-originated orders matter

A vault can hedge exposure, a lending protocol can manage risk, or an automated onchain product can express a trade without delegating the decision to a centralized server. The contract's logic becomes part of the control plane.

## The transaction path

The user or keeper submits an EVM transaction to the application. The application validates state and constructs the CoreWriter payload. CoreWriter emits the protocol event. HyperCore later validates and processes the native order against the account associated with the contract.

Every step can fail for a different reason: EVM gas, contract checks, action encoding, HyperCore account state, margin, price constraints, or market status.

## Latency is intentionally not the selling point

Native API trading remains the appropriate route for market making and other latency-sensitive execution. The delay protects fairness between the EVM and native order path.

Contract-originated orders are most compelling when composability or onchain authorization matters more than sub-second quote management.

## Risk controls

A contract should bound asset IDs, size, price, direction, slippage logic, and maximum aggregate exposure. It should also define who can trigger actions and under what state conditions.

If the contract depends on a precompile price, confirm that the value and the eventual order execution are not assumed to occur at one atomic timestamp.

## How this connects

Start with [CoreWriter Actions: Complete Reference](/hyperliquid-academy/article/81-corewriter-actions-complete-reference), [Hyperliquid Order Types Explained](/hyperliquid-academy/article/17-order-types) if the underlying concept is unfamiliar. Related reading: [Market Making on Hyperliquid](/hyperliquid-academy/article/68-market-making-on-hyperliquid), [How to Build a Production-Grade Hyperliquid Trading Bot](/hyperliquid-academy/article/94-production-grade-hyperliquid-trading-bot).

## Sources

- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm/interacting-with-hypercore
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm/interaction-timings