Hyper liquid - Layer 1 Trading With HyperCore and HyperEVM
last updated
Hyper liquid is a Layer 1 blockchain combining native trading through HyperCore with HyperEVM, an environment for running smart contracts. HyperCore handles spot and perpetual order books, while HyperEVM supports programmable applications. Their shared blockchain connects trading with application development, although balances and execution requirements differ between environments. Choosing an operation means identifying the asset it uses, where that asset is available and what financial exposure the operation creates.
Bottom line: HyperCore trading and HyperEVM applications share a blockchain, while each operation requires usable balances in the environment executing it.
Balances Before an Order or Contract Call
A native trade requires usable funds on HyperCore; a contract call requires the relevant assets and gas on HyperEVM. A balance transferred into the other environment needs a supported return transfer before its original use can resume. The same wallet address does not make every balance available everywhere.
Funding the Intended Environment
External deposits and transfers between HyperCore and HyperEVM serve different purposes. External deposits bring assets onto the blockchain through a supported route. Internal transfers move supported assets between its execution environments. Asset compatibility matters in both cases. Each transferable spot asset has its own transfer mechanism, so a transfer address for one asset cannot safely substitute for another.
Hypothetical Contract Deposit
Suppose a reader holds a transferable token on HyperCore and is considering either a native spot trade or a compatible HyperEVM contract deposit. The balance, application compatibility and intended deposit are hypothetical. Both options require spendable assets where execution occurs. Because the intended action is a contract deposit, the reader chooses HyperEVM.
The reader first confirms the token has a supported transfer into HyperEVM and the application accepts that representation. The transfer requires HYPE for fees in the HyperCore spot balance, while the later contract call requires HYPE on HyperEVM. HYPE funding is required in both environments; the fee amount depends on the operation and network conditions. The reader uses the transaction estimate rather than a remembered fee.
After transferring the required assets, the reader compares the destination balances with the transfer record. A HyperCore-to-HyperEVM transfer queues until the next HyperEVM block, so an immediate unchanged balance can reflect pending processing. Once the token balance and gas balance appear, the reader has confirmed funding on HyperEVM. Any token allowance the application requires must also be in place before the deposit call. The transfer itself has not deposited anything into the application.
How Do Spot and Perpetual Trades Differ?
Spot trading exchanges token balances, while a perpetual trade creates a derivative position backed by collateral. The distinction determines what the account holds after execution and which obligations continue afterward.
Spot Balances and Order Fills
HyperCore executes spot and perpetual trading through onchain order books. A spot purchase changes the relevant token balances when an order fills. An accepted order can remain open without exchanging its full requested amount. Fill records distinguish completed trades from outstanding orders.
A limit order sets an acceptable price or better, but available liquidity determines whether it fills. Market orders seek immediate execution against available orders. Thin liquidity can produce a worse average execution price than the displayed best quote. Choosing between these order types changes price control and execution certainty.
Perpetual Positions and Collateral
A perpetual position provides exposure to price changes without delivering the underlying asset. Its collateral supports losses, and maintenance margin determines when liquidation becomes possible. Funding rates also produce payments between position holders. Those payments can change the cost of keeping a position open, separately from trading fees.
Which Balances Can Back a Perpetual Position?
The account mode and market collateral determine which balances can support a perpetual position. Standard mode separates spot balances and individual perpetual exchange balances. Unified accounts combine spot and cross margin use of the same collateral asset. Portfolio margin instead evaluates eligible assets within a shared portfolio and can automatically borrow when an order exceeds the available settlement balance. Borrowing accrues interest and exposes the portfolio to liquidation. Access depends on account eligibility, and asset supply and borrow caps limit its use. When caps prevent further borrowing, the trader must supply the settlement asset.
Cross margin shares collateral across the positions its account mode groups together. Losses in one position can therefore reduce support for others. Isolated margin confines collateral to an individual position. Some markets enforce stricter isolated rules, including restrictions on removing margin. A displayed total account value does not necessarily equal the amount available for a new position or withdrawal.
Maximum leverage and margin requirements vary by market. Builder-deployed markets can also specify different collateral and operating conditions. The relevant account balance, existing obligations and market requirements determine whether another order fits within available margin.
HyperEVM Applications and HyperCore Execution
HyperEVM runs applications using the Ethereum Virtual Machine, the execution environment familiar to Solidity developers. Its contracts share HyperBFT consensus with HyperCore. This shared foundation supports applications involving lending, trading and vault accounting without placing those applications on a separate blockchain.
HYPE is the native gas token on HyperEVM. A contract interaction therefore needs gas funding even when the application handles another asset. Token approvals create a separate permission: they authorize a contract to spend tokens within an allowance. The approval amount and recipient contract determine the scope of that permission.
CoreWriter lets contracts submit supported actions to HyperCore. Execution has its own ordering and prerequisites. The acting account must already exist on HyperCore before the relevant EVM block begins. Initializing it through a transfer in that same block does not satisfy this requirement. Some actions also enter a queue before HyperCore processes them, so application completion can require checking the resulting Core state.
How Are Trading and Application Costs Calculated?
Trading costs depend on the market, maker or taker execution and the account’s applicable fee tier. Trading volume determines the volume tier, eligible staking discounts reduce the applicable rates and builder-deployed markets can add deployer charges. HyperEVM calls consume gas according to computation and network fee conditions. Funding payments add a separate ongoing cost or receipt for perpetual positions. Slippage changes execution value without appearing as a protocol fee. These inputs explain why one displayed percentage cannot describe every operation’s total cost.
Token Listings and Builder-Deployed Markets
HIP-1 defines native fungible tokens and their spot trading infrastructure. Deploying an ERC-20 contract on HyperEVM does not automatically create its HyperCore market. A corresponding native token deployment and an established link connect the representations. Deployment auctions also introduce a changing cost for builders.
HIP-3 supports builder-deployed perpetual markets using HyperCore’s trading infrastructure. Deployers define contract specifications and operate their price oracles, leverage limits and settlement controls. Those responsibilities matter to traders: shared execution infrastructure does not make every market’s price feed or settlement conditions identical.
HIP-4 defines fully collateralized outcome contracts with bounded settlement values. These differ from leveraged perpetual positions because the contract structure does not require leverage or liquidation. Market availability and supported outcome structures follow a staged rollout. The individual contract’s settlement terms determine its payoff, rather than an assumption drawn from spot or perpetual trading.
Staking and Vault Participation
Staking and vault deposits put assets to different uses. Staking supports validator participation, while vault deposits expose capital to the vault’s operations.
Validator Delegation
Native HYPE staking takes place on HyperCore through delegation to validators. Validator commissions affect rewards, and a validator’s failure to participate can interrupt reward production. Delegated balances have lockup conditions. Undelegation returns HYPE to the staking balance. A separate staking-to-spot transfer starts the unstaking queue; the funds become spendable in spot after that transfer completes.
Vault Strategies and Withdrawals
Hyperliquidity Provider, or HLP, runs protocol strategies including market making, liquidations and supplying USDC in Earn. Depositors share the vault’s profit and loss. Its withdrawal lockup runs from the most recent deposit, which matters when adding funds to an existing holding.
HyperEVM also supports vaults with programmable accounting and supported HyperCore operations. Legacy HyperCore vaults have a narrower feature set and do not support spot or HIP-3 trading. Each vault’s strategy, permissions and withdrawal conditions determine the exposure a deposit creates. Capital committed to staking or a vault may therefore be unavailable for an immediate trade.
Details worth knowing about Hyper liquid
Can an Exchange Receive HYPE Sent From Either HyperCore or HyperEVM?
An exchange must support the specific environment sending the deposit. Support for HYPE through HyperCore does not automatically include HyperEVM deposits. The receiving service’s selected deposit network must match the sending environment. A matching asset symbol or wallet address alone does not establish that compatibility.
Why Does an API Wallet Query Show an Empty Trading Account?
An API wallet signs authorized actions, while account queries need the address of the master account or relevant sub-account. Querying the agent address can therefore return an empty result even when the trading account holds funds. Signing identity and account ownership identify different things in this API.
Does a stop-loss Order Guarantee Its Trigger Price?
A stop-loss trigger does not guarantee the eventual execution price. A triggered market order attempts to fill against available liquidity within its slippage tolerance. A rapid price move can worsen the execution price or leave some or all of the order unfilled. A stop-limit order adds a price constraint, but that constraint can leave the order unfilled when available orders fall outside its limit.
Is a Matching Token Name Enough to Identify a HyperCore Asset?
A token name alone does not uniquely identify a HyperCore asset. HIP-1 permits names without uniqueness constraints and assigns each deployment a unique identifier. For a linked HyperEVM token, the corresponding contract address also matters. Matching text labels do not prove two token representations belong to the same deployment.
How Can Automation Avoid Nonce Conflicts Between sub-accounts?
Separate API signing wallets can keep independent trading processes from sharing the same nonce tracker. HyperCore tracks nonces by signer, so one API wallet signing for several sub-accounts shares nonce state across them. Each process must still generate valid, unused nonces; separate account balances alone do not provide separate signing state.