Summary
Hyperliquid has a public testnet for both its trading layer (HyperCore) and its EVM (HyperEVM). If you searched for "hyperliquid testnet", you likely need one of three things: a testnet RPC endpoint to connect a wallet or app, testnet HYPE or mock USDC from a faucet, or the correct chain settings for HyperEVM testnet (chain ID 998). This page gives you the practical reference first, then explains how to debug common testnet issues and when a managed RPC service is worth using.
OnFinality provides RPC API access and dedicated node infrastructure for supported networks. For Hyperliquid testnet, check the supported RPC networks page for current availability and endpoint details, and see RPC pricing if you need a managed endpoint for development or CI. The official Hyperliquid testnet app and docs remain the source of truth for faucet rules and protocol behavior.
Key Takeaways
- Hyperliquid testnet covers two surfaces: the trading app (HyperCore) and HyperEVM testnet, which uses chain ID 998 and HYPE as its native currency.
- The official testnet faucet requires a mainnet deposit from the same address; email-login wallets may need to be exported and imported into a browser wallet first.
- For wallet or app configuration, use the HyperEVM testnet chain settings (chain ID 998, HYPE gas token) and verify the RPC URL you choose is reachable before debugging contract code.
- Public testnet RPC endpoints are fine for manual testing, but CI pipelines and multi-developer teams usually need a managed or dedicated endpoint to avoid shared rate limits.
- Most "testnet not working" issues come from wrong chain ID, wrong RPC URL, unfunded testnet wallet, or a wallet still pointed at mainnet.
- OnFinality offers RPC API and dedicated node options for supported networks; check the networks page for Hyperliquid testnet availability and pricing before committing.
Hyperliquid testnet at a glance
Hyperliquid testnet is the staging environment for the Hyperliquid ecosystem. It has two practical surfaces: the trading application at app.hyperliquid-testnet.xyz, where you can place orders against testnet order books, and HyperEVM testnet, the EVM-compatible chain that developers connect to with a standard JSON-RPC endpoint.
If your goal is to test a trading strategy or a front-end integration, you will mostly work with the testnet app and its API. If your goal is to deploy Solidity contracts, index events, or connect a wallet through ethers or viem, you need the HyperEVM testnet chain settings and an RPC URL.
- Trading testnet: app.hyperliquid-testnet.xyz, with its own faucet and API surface.
- HyperEVM testnet: EVM chain with chain ID 998 and HYPE as the native gas token.
- Faucet: the official testnet faucet requires a mainnet deposit from the same address.
- RPC: public endpoints exist, but availability and rate limits vary; managed providers are an option for heavier use.
| Criterion | What to check | Why it matters |
|---|---|---|
| Trading testnet (HyperCore) | Use the official testnet app and API docs for order placement, faucet, and account setup. | Trading behavior and faucet rules are protocol-specific and not covered by generic EVM RPC settings. |
| HyperEVM testnet | Chain ID 998, HYPE gas token, and an EVM-compatible RPC URL. | This is what wallets, ethers, viem, Hardhat, and Foundry expect when you deploy or read contracts. |
| Faucet | Mainnet deposit requirement and wallet address consistency. | Without testnet funds you cannot pay gas or place test orders, and email-login wallets may use different addresses per environment. |
HyperEVM testnet chain settings for wallets and apps
When you add HyperEVM testnet to a wallet or configure a development framework, the key values are the chain ID and the native currency. Use the settings below as a reference and confirm them against the official Hyperliquid documentation before relying on them in production tooling.
The RPC URL is the part that changes most often. Public endpoints are convenient for manual testing, but they are shared and may rate-limit or change without notice. For repeatable development, choose an endpoint you control or a managed provider that documents its testnet support.
| Criterion | What to check | Why it matters |
|---|---|---|
| Network name | Hyperliquid EVM Testnet | A clear label helps you avoid mixing mainnet and testnet configurations in wallet settings. |
| Chain ID | 998 (0x3e6) | Wallets and libraries reject transactions signed for the wrong chain; a wrong chain ID is a common cause of failed deployments. |
| Native currency | HYPE | Gas is paid in HYPE on HyperEVM testnet; an empty wallet cannot send transactions even if the contract code is correct. |
| RPC URL | A reachable EVM JSON-RPC endpoint for HyperEVM testnet | The endpoint determines whether your wallet or app can read state and broadcast transactions. |
| Block explorer | The explorer linked from the official Hyperliquid testnet app or docs | You need transaction and contract verification during debugging. |
Getting testnet funds from the Hyperliquid faucet
The official Hyperliquid testnet faucet is not a generic "connect and claim" faucet. According to the Hyperliquid documentation, you need to have deposited on mainnet with the same address before you can receive mock USDC for testnet use. That design ties testnet access to real mainnet activity and prevents anonymous draining of the faucet.
If you use an email login, the wallet provider may generate different addresses for mainnet and testnet. In that case, export the email wallet from mainnet, import it into a browser wallet such as Rabby or MetaMask, and connect that wallet to the testnet app. Then use the faucet page linked from the official testnet app.
- Confirm you are on the official testnet app before connecting a wallet.
- Check that the address you use on testnet matches the address that deposited on mainnet.
- If you used email login, export and import the wallet so both environments share the same address.
- After claiming, verify the balance in the testnet app and, for HyperEVM, in your wallet's testnet network view.
Debug path: why your testnet connection is failing
A quick reachability check with curl can separate endpoint problems from application problems. Replace the URL with the HyperEVM testnet endpoint you are using:
``bash
curl -s -X POST <YOUR_HYPEREVM_TESTNET_RPC_URL> \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
``
If the response returns 0x3e6, the endpoint is reachable and reporting chain ID 998. If it returns a different chain ID, you are pointed at the wrong network. If it times out or returns an HTTP error, the endpoint is the problem.
| Criterion | What to check | Why it matters |
|---|---|---|
| Wallet shows zero balance | Faucet eligibility, address match with mainnet deposit, and correct testnet network selected. | Funds claimed on one address or network will not appear on another. |
| Transactions fail immediately | Chain ID 998, HYPE gas balance, and nonce state in the wallet. | Wrong chain ID or missing gas causes rejection before the transaction reaches the node. |
| RPC calls time out | Endpoint reachability with a simple JSON-RPC request, then check for rate limiting. | Shared public endpoints can throttle or drop requests under load. |
| Contract deployment reverts | Compiler target, constructor arguments, and gas estimation on the testnet endpoint. | Testnet behavior can differ from mainnet in gas costs and available precompiles. |
| App works locally but not in CI | Environment variables for the RPC URL and chain ID, and whether CI uses a shared public endpoint. | CI often hits rate limits that a single developer does not see locally. |
When a public testnet endpoint is enough, and when it is not
Public testnet endpoints are appropriate for manual wallet testing, one-off contract deployments, and learning the tooling. They are less appropriate for CI pipelines, multi-developer teams, or any workflow that sends bursts of requests, because shared endpoints can rate-limit or change without notice.
A managed RPC provider gives you a documented endpoint, predictable access, and a support path when something breaks. A dedicated node gives you isolated infrastructure when you need custom configuration or consistent throughput. OnFinality offers both RPC API access and dedicated node infrastructure for supported networks; check the supported RPC networks page for current Hyperliquid testnet availability and see RPC pricing for plan details.
| Criterion | What to check | Why it matters |
|---|---|---|
| Manual wallet testing | Public endpoint is usually sufficient. | Low request volume and interactive debugging do not stress shared infrastructure. |
| CI/CD pipelines | Managed RPC endpoint with documented limits. | Automated runs can hit rate limits and fail intermittently on shared public endpoints. |
| Multi-developer team | Managed endpoint with separate API keys or project isolation. | Shared keys make it hard to attribute failures and can exhaust a single quota. |
| Custom node configuration | Dedicated node infrastructure. | Some testing scenarios need specific node versions, logging, or networking that shared endpoints do not expose. |
Moving from testnet to mainnet without surprises
The transition from Hyperliquid testnet to mainnet is mostly a configuration change, but the failure modes are different. Mainnet has real funds, different gas economics, and production traffic patterns. Before you switch, make the environment boundary explicit in your code and your deployment process.
Keep chain ID, RPC URL, and faucet or funding steps in environment variables rather than hard-coded values. Run the same contract deployment and smoke tests against testnet that you plan to run against mainnet, and verify that your monitoring can distinguish testnet and mainnet traffic.
- Store chain ID and RPC URL in environment variables, not in source code.
- Run a smoke test that reads state and sends a transaction on testnet before mainnet rollout.
- Confirm wallet network switching works for both testnet and mainnet.
- Review gas assumptions; testnet costs do not predict mainnet costs.
- Keep a rollback plan for the RPC endpoint in case a provider has an incident.
FAQ
Frequently Asked Questions
Does Hyperliquid have a testnet?
Yes. Hyperliquid operates a public testnet with a trading application and a HyperEVM testnet chain. The trading testnet is accessed through the official testnet app, and HyperEVM testnet is accessed through an EVM-compatible RPC endpoint with chain ID 998.
What is the Hyperliquid testnet chain ID?
HyperEVM testnet uses chain ID 998 (0x3e6). Confirm this against the official Hyperliquid documentation before configuring wallets or deployment scripts, since testnet settings can change.
How do I get testnet HYPE or mock USDC?
Use the official Hyperliquid testnet faucet linked from the testnet app. The documentation states that you need to have deposited on mainnet with the same address before you can receive mock USDC for testnet use. If you use email login, export the mainnet wallet and import it into a browser wallet so both environments share the same address.
Can I use a public RPC endpoint for Hyperliquid testnet?
Yes, for manual testing and low-volume work. Public endpoints are shared and may rate-limit or change. For CI pipelines or team use, a managed or dedicated endpoint is usually more predictable.
Why does my HyperEVM testnet transaction fail?
Common causes are wrong chain ID, missing HYPE for gas, an unfunded testnet wallet, or an RPC endpoint that is unreachable or rate-limited. Run an eth_chainId request against your endpoint first to confirm it reports 0x3e6.
Does OnFinality support Hyperliquid testnet?
Check the supported RPC networks page for current availability. OnFinality provides RPC API access and dedicated node infrastructure for supported networks, and the networks page is the authoritative list.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
