How to Bridge to Hyperliquid: HyperCore, HyperEVM, and Route Verification

Direct answer and scope

To bridge to Hyperliquid, first decide which destination you actually need. If you want to trade perpetuals on the order book, you need USDC credited to HyperCore. If you want to use DeFi applications, hold HYPE as an ERC-20-style asset, or interact with smart contracts, you need assets on HyperEVM (chain ID 999). The two are part of the same L1 but are separate execution environments with separate balance accounting.

The most direct documented path for trading collateral is the native Hyperliquid deposit flow, which accepts USDC from Arbitrum. Third-party bridges, aggregators, and intent-based routers can move assets from many chains, but they generally land on HyperEVM, not HyperCore. This article covers how to reason about that split, how to execute a transfer, and how to verify it independently. It does not recommend a specific bridge vendor; for endpoint and provider selection, use the RPC Assistant.

• HyperCore: order-book trading, USDC collateral, native deposit/withdraw flow.
• HyperEVM: EVM-compatible chain (ID 999), smart contracts, HYPE and bridged tokens.
• Internal transfers between HyperCore and HyperEVM are handled by Hyperliquid itself, not by an external bridge.

Prerequisites and assumptions

Before starting, confirm you have a self-custody wallet that can sign on both the source chain and, if needed, HyperEVM. You need the source-chain gas token (for example ETH on Arbitrum or Ethereum, SOL on Solana) and enough of it to cover the bridge transaction. You also need to know your destination address format: HyperCore deposits are credited to your Hyperliquid account address, while HyperEVM uses a standard 0x EVM address.

This guide assumes you are bridging a stablecoin such as USDC for trading, or HYPE-adjacent assets for DeFi. It assumes you can read a block explorer and run a curl command. It does not assume any particular bridge is safe or available in your jurisdiction; bridge risk, smart-contract risk, and counterparty risk are yours to assess.

Mental model: why the destination matters more than the source

Most bridging confusion comes from treating Hyperliquid as one chain with one balance. In practice, a bridge transaction has a source chain, a destination environment, and a delivery asset. The source chain is usually the easy part; the destination environment is where funds get stranded or misrouted.

The native Hyperliquid deposit flow is designed around USDC on Arbitrum. Historically this was the dominant entry point, and Hyperliquid's documentation notes that the legacy Arbitrum bridge now holds a minority of USDC supply on HyperCore as other routes have grown. That does not make the native route obsolete; it means you should check current supported assets and fees in the official docs before assuming it is cheapest.

Third-party bridges and aggregators typically mint or release assets on HyperEVM. If your goal is perp trading, arriving on HyperEVM means you still need an internal transfer or a supported deposit step to reach HyperCore. If your goal is DeFi, arriving on HyperCore means you need to move assets to HyperEVM. Always identify the destination environment before signing.

Route selection procedure

Use a repeatable checklist rather than picking the first bridge in a search result. The goal is to compare routes on destination correctness, delivered asset, fee, and finality, then verify after execution.

Record each candidate route in a table before you sign anything. Do not fill in numbers from marketing pages; use the quote the bridge returns at the time of transfer, and note the timestamp. A route that quotes a low fee but delivers a wrapped asset you cannot use is not cheaper in practice.

• Destination environment: HyperCore or HyperEVM? Does the bridge explicitly support it?
• Delivered asset: native USDC, bridged USDC, HYPE, or a wrapped representation?
• Source chain support and required gas token.
• Quoted fee, slippage tolerance, and estimated time to finality.
• Whether the bridge is custodial, lock-and-mint, or intent-based.
• Withdrawal path back to your source chain and its cost.

Results table template for route comparison

Use the following Markdown table to record your own measurements. The columns are deliberately generic so you can compare a native deposit, an aggregator, and a direct bridge on the same terms. Leave cells blank until you have a live quote; never copy figures from a guide, including this one.

| Route | Source chain | Destination env | Delivered asset | Quoted fee | Est. time | Tx hash | Verified balance delta |
|---|---|---|---|---|---|---|---|
| Native deposit | Arbitrum | HyperCore | USDC |  |  |  |  |
| Aggregator A | Ethereum | HyperEVM | USDC |  |  |  |  |
| Direct bridge B | Solana | HyperEVM | USDC |  |  |  |  |

Executing a native USDC deposit to HyperCore

The native flow is conceptually simple: you send USDC on Arbitrum to the Hyperliquid bridge contract, and Hyperliquid credits your HyperCore account. The exact contract address, minimum deposit, and supported assets change over time, so always copy them from the official Hyperliquid documentation rather than from a third-party page.

A typical sequence is: acquire USDC on Arbitrum, approve the bridge contract if required, call the deposit function with your Hyperliquid account address, then wait for the Arbitrum transaction to finalize and for Hyperliquid to credit the balance. The credit is not instant at the EVM level; it depends on Hyperliquid's validator set observing the deposit.

• Confirm the bridge contract address from official docs before approving.
• Deposit to your own Hyperliquid account address, not a random address.
• Keep the Arbitrum transaction hash; you will need it for verification.
• Check the minimum deposit amount; small deposits may be rejected or uneconomical.

Verifying a HyperEVM transfer with RPC

If your route delivers to HyperEVM, you can verify the result without trusting the bridge UI. Query the destination address balance and the transaction receipt over JSON-RPC. Replace RPC_URL with an endpoint you control or a provider endpoint; see the HyperEVM RPC provider guide for selection criteria and the RPC pricing page for capacity planning.

The following curl commands check the chain ID, the native balance, and a transaction receipt. A correct HyperEVM endpoint returns chain ID 0x3e7 (999). If it returns a different chain ID, you are pointed at the wrong network.

curl -s -X POST RPC_URL \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -s -X POST RPC_URL \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_getBalance","params":["0xYOUR_ADDRESS","latest"]}'

curl -s -X POST RPC_URL \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":3,"method":"eth_getTransactionReceipt","params":["0xYOUR_TX_HASH"]}'

Checking an ERC-20 balance after bridging

Native balance checks only tell you whether gas arrived. To confirm a bridged token, query the token contract's balanceOf for your address. The example below uses Python with the standard library so it runs without extra dependencies. Replace TOKEN_CONTRACT and YOUR_ADDRESS with the values from the bridge's documentation or the explorer.

Decode the returned hex value using the token's decimals (commonly 6 for USDC, 18 for many others). A mismatch between the expected amount and the decoded amount usually indicates a fee, a different token representation, or a failed delivery.

import json, urllib.request

RPC_URL = "RPC_URL"
TOKEN_CONTRACT = "0xTOKEN_CONTRACT"
YOUR_ADDRESS = "0xYOUR_ADDRESS"

# balanceOf(address) selector = 0x70a08231
padded = YOUR_ADDRESS.lower().replace("0x", "").rjust(64, "0")
data = "0x70a08231" + padded

payload = json.dumps({
    "jsonrpc": "2.0", "id": 1,
    "method": "eth_call",
    "params": [{"to": TOKEN_CONTRACT, "data": data}, "latest"]
}).encode()

req = urllib.request.Request(RPC_URL, data=payload,
    headers={"Content-Type": "application/json"})
resp = json.loads(urllib.request.urlopen(req).read())
raw = int(resp["result"], 16)
print("raw balance:", raw)
print("assuming 6 decimals:", raw / 10**6)

Expected verification result

A successful bridge produces three observable facts: the source-chain transaction is confirmed, the destination balance increases by the expected amount minus fees, and the bridge's own status page or explorer shows the transfer as complete. If any of these disagree, treat the transfer as unresolved and investigate before sending more funds.

For HyperCore deposits, the destination balance appears in the Hyperliquid trading interface, not in an EVM balance query. For HyperEVM transfers, the balance delta should be visible via the balanceOf call above. Record the before and after values in your results table so you have a reproducible record.

Troubleshooting common bridging failures

Most failures fall into a few categories: wrong destination environment, insufficient gas on the source chain, unsupported asset, or a bridge that is paused or rate-limited. Work through them in order rather than retrying blindly.

If the source transaction succeeded but the destination balance did not change, first confirm you queried the correct environment. A HyperEVM balance query will not show HyperCore collateral. Second, check whether the bridge requires a manual claim step. Third, check the bridge's status page for known delays. Only after those checks should you contact support, and never share your private key or seed phrase with anyone claiming to help.

• Wrong chain ID: confirm 0x3e7 for HyperEVM.
• Stuck deposit: check Arbitrum finality and Hyperliquid validator credit.
• Missing token: verify the token contract address, not just the symbol.
• Paused bridge: check official status channels before retrying.
• Phishing: never enter a seed phrase into a bridge site.

Limitations and tradeoffs

Bridging always involves tradeoffs. Native routes may be slower or support fewer assets but reduce the number of smart contracts you trust. Aggregators may find cheaper or faster routes but add routing and solver risk. Direct bridges may be fast but can deliver wrapped assets that are less useful on the destination.

There is also an operational tradeoff: running your own HyperEVM node gives you independent verification and lower latency for automated strategies, but requires maintenance. A managed endpoint is simpler but introduces a provider dependency. For teams running trading infrastructure, the dedicated node option and the API service are worth evaluating against your latency and uptime requirements. The networks directory lists supported chains if you need to confirm coverage before committing.

Next steps

Once your assets are on the correct environment, the next step is to set up reliable RPC access for whatever you plan to do: trading, DeFi interactions, or monitoring. If you are building automation, read the Hyperliquid low-latency RPC guide and the Hyperliquid RPC provider overview to compare approaches. For a concrete endpoint recommendation, use the RPC Assistant rather than guessing.

Finally, document your route and verification steps in your own runbook. Bridges change, fees change, and supported assets change. A runbook that records the destination environment, the contract addresses you used, and the RPC checks you ran will save time the next time you need to move funds.