Hyperfoundation
Hyperfoundation HyperEVM runs smart contracts with gas paid in native HYPE
Hyperfoundation HyperEVM runs EVM-compatible smart contracts on Hyperliquid, with native HYPE paying transaction gas. The Ethereum Virtual Machine (EVM) executes application code, while HyperCore handles native trading features. Both belong to the same Layer 1 blockchain and share HyperBFT consensus. Onchain contract transactions require an available HyperEVM HYPE balance; a HyperCore spot holding does not cover that fee.
A transaction’s token amount, network fee, and application charge describe different costs. The operation determines which balances or permissions change, while its execution and demand for blockspace determine the gas charge.
Submit a contract call with the mainnet gas balance
Chain ID 999 identifies HyperEVM mainnet, where a contract transaction needs native HYPE in the sending address. Connect to that network before reviewing the target contract and requested operation. The balance must cover the transaction’s maximum gas charge and any native HYPE value that the call sends.
| Operation | Execution method | Asset or contract scope |
|---|---|---|
| Native HYPE transfer | Transaction carrying native value | HyperEVM native HYPE balances |
| ERC-20 transfer | Call to the token contract | Balances within that token contract |
| ERC-20 approval | Allowance update in the token contract | One token and the specified spender |
| Contract deployment | Contract-creation transaction | New code and storage on HyperEVM |
A token transfer, allowance update, and deployment can all consume HYPE gas without moving the same asset. With the gas balance available, review the call, sign the transaction, and submit it through the wallet’s RPC connection. Signing authorizes the transaction; the returned hash identifies it. Inspect the receipt after inclusion, then confirm the intended contract state or token balance. A successful receipt establishes EVM execution without proving every application-level outcome.
If the HYPE exists only in HyperCore spot, transfer it to HyperEVM before attempting the call. That transfer requires HYPE for its charge on the HyperCore side. The incoming balance becomes available when the queued transfer reaches an EVM block. An insufficient HyperEVM gas balance requires funding that balance before submission.
What determines the HYPE fee for a contract transaction?
Gas used and the effective price per gas determine the transaction’s HYPE network fee. Gas measures the execution work performed by contract logic and storage operations, so calls to the same application can consume different amounts.
Fee caps and execution charges
EIP-1559 separates the block’s base fee from the transaction’s priority fee; demand for blockspace can increase the base fee. A transaction’s fee settings govern its permitted price, while the gas limit governs how much work execution can consume.
The price ceiling
The
maxFeePerGas
field caps the combined price per gas unit. The effective priority fee cannot exceed either
maxPriorityFeePerGas
or the amount left after the base fee. A fee cap below the applicable base fee prevents inclusion under those settings.
The execution charge
The network charge equals
gasUsed
multiplied by
effectiveGasPrice, with the price expressed in compatible HYPE units. Unused gas does not add to the charge, so a wallet’s maximum estimate can exceed the receipt’s recorded fee.
HyperEVM burns both the base fee and the priority fee. An application can charge separately for its own operation, so its fee and the network charge need separate accounting.
Token approvals control spending permissions
An ERC-20 approval records a specified spender’s allowance over the owner’s balance within one token contract. Approval does not transfer the approved amount immediately, and it does not authorize spending unrelated tokens or native HYPE. The remaining allowance caps authorized spending; a transfer also requires a sufficient token balance. Where an application requires separate approval and execution transactions, both consume gas and incur their own network charges. Review the spender address and permitted amount before authorizing access. The updated allowance confirms the permission; it does not establish that a later swap or deposit succeeded.
Native HYPE and wrapped HYPE occupy different balances
Native HYPE pays network gas, while WHYPE represents HYPE as a token balance in an ERC-20 wrapper contract. The canonical wrapper credits wrapped tokens when it receives native HYPE and returns native HYPE on withdrawal. An unwrap transaction also requires native HYPE, so holding only WHYPE cannot fund that transaction’s network charge.
Reverts, pending transactions, and rejected requests have different consequences
A reverted transaction reaches EVM execution and spends gas; a request rejected before inclusion has no onchain execution charge. A revert rolls back contract state changes while leaving a gas charge for the execution work completed before the failure. A hash without a receipt does not establish an execution result. The transaction may remain pending, or the queried RPC may have no receipt available. Nonce ordering also matters: a later transaction cannot simply bypass an earlier missing nonce from the same address.
Gas estimation through
eth_estimateGas
simulates execution against the latest state on the default HyperEVM RPC. Balances or permissions can change before inclusion, so a successful simulation does not guarantee the same execution outcome. Increasing a fee cap does not make invalid contract inputs valid.
Error code 10055 covers problems at the HyperCore and HyperEVM boundary. Possible causes include nonce errors, insufficient funds, duplicate transaction hashes, and underpriced replacement transactions. The accompanying error detail determines which condition needs attention; the number alone does not identify one universal fix.
Small blocks and large blocks differ in frequency and gas capacity
Small blocks provide more frequent inclusion opportunities, while large blocks accommodate transactions requiring more gas, including complex deployments. A transaction must fit its targeted block class, whose gas capacity does not expand with a higher fee cap.
Small and large HyperEVM blocks interleave within one increasing EVM block-number sequence.
Next-block base fee estimates use
eth_gasPrice
for small blocks and
eth_bigBlockGasPrice
for large blocks. Routing uses the HyperCore account’s
usingBigBlocks
flag and requires an existing HyperCore user. The setting persists until changed, so returning to small blocks requires clearing it.
HyperCore interfaces connect contracts with native actions
HyperEVM contracts can connect application logic with HyperCore through read precompiles and the CoreWriter system contract. Read precompiles expose HyperCore data, while CoreWriter sends supported actions for processing. Orders, asset transfers, and native staking operations concern HyperCore state, separate from the contract’s EVM gas balance.
Token links and contract behavior
Moving a non-native token between these environments requires an established link between its Core token and ERC-20 contract. Each token has its own transfer system address. Linking does not guarantee correct ERC-20 behavior or sufficient backing in the system address. The linked contract’s implementation and reserves affect whether its transfer mechanism works as expected.
Account activation and action timing
The address calling CoreWriter, including an application contract’s own address, must already exist on HyperCore before the EVM block begins. A transfer that initializes the account within that same block arrives too late for the action. A new HyperCore account also incurs its own activation charge, separate from ordinary EVM gas.
CoreWriter order actions and vault transfers include an onchain delay, so an enqueued action does not yet establish HyperCore execution. When the requested operation crosses that boundary, check its HyperCore outcome separately from the EVM receipt.
An inactive HyperCore account prevents CoreWriter actions even when the address holds enough native HYPE for EVM gas.
Hyperfoundation HyperEVM questions, answered
Can an Ethereum wallet display HyperEVM contract tokens automatically?
An EVM-compatible wallet needs the HyperEVM network configuration to display balances on that network. ERC-20 assets can also require adding the correct token contract to the wallet’s display. Using the same address on Ethereum and HyperEVM does not merge their balances. A missing wallet entry does not by itself establish that an onchain token balance is absent.
Does reading a HyperEVM contract balance incur a gas fee?
A balance query through eth_call does not create an onchain transaction or deduct HYPE gas. RPC request limits still apply. When a contract performs a read during an onchain transaction, that execution contributes to the transaction’s gas use. Displaying a balance and changing it therefore have different fee implications.
What should I change when a HyperEVM wallet asks for ETH gas?
HyperEVM uses HYPE for network gas, so an ETH warning can indicate an incorrect network configuration or inadequate wallet support. Check that the selected network is HyperEVM and that its native currency setting is HYPE. ETH held elsewhere does not pay the HyperEVM transaction fee. The relevant balance is native HYPE on the selected HyperEVM network.
How can I fix an invalid type-2 transaction envelope on HyperEVM?
A type-2 transaction must use maxFeePerGas and maxPriorityFeePerGas instead of a legacy gasPrice field. An envelope error concerns the transaction’s construction, including the wallet or software producing it. Adding HYPE or increasing the gas limit does not replace invalid fee fields. The transaction builder needs to produce the supported dynamic-fee format before submission.
Is a token symbol enough to identify an ERC-20 contract on HyperEVM?
A token’s contract address and network identify its deployment; its symbol does not uniquely identify the contract. ERC-20 defines the symbol as optional metadata, and different contracts can use the same text. Spending authorization applies to the selected token contract. The displayed ticker alone cannot establish that the address represents the asset that an application expects.
Which EVM target matches HyperEVM contract deployment?
HyperEVM implements the Cancun EVM hardfork without blobs. Contract compilation and transaction construction must match the features that this environment supports. EVM compatibility does not recreate another chain’s external contracts, token deployments, or account state. Code that depends on those objects needs the corresponding HyperEVM configuration, even when its execution instructions are compatible.
Will a successful HyperEVM testnet deployment publish the contract on mainnet?
A successful testnet deployment creates contract state on testnet, not mainnet. HyperEVM testnet uses chain ID 998, while mainnet uses chain ID 999. Their contract state and HYPE balances remain separate. Publishing on mainnet requires a mainnet deployment transaction with its own gas funding; a testnet receipt does not establish that mainnet deployment.
Updated: