Correction and scope
Editorial correction — October 3, 2026: The previous version claimed that HyperEVM had no automated detection tools, listed several services as supported or unsupported, described specific project incidents, and set numeric liquidity and holder-risk thresholds. Those statements were not supported by the primary sources reviewed here and have been removed.
This guide offers a manual screening process. It cannot prove that a token is safe, predict a rug pull, or guarantee that a sell will succeed.
Identify the exact token and network
Start with the full contract address and network, not the token name, ticker, logo, or search result. HyperEVM mainnet uses chain ID 999; the official HyperEVM guide lists the current mainnet RPC and other network details.
Check the token address against the project’s primary documentation or a verified official channel. Then open that address in an explorer listed in Hyperliquid’s onboarding guide or builder-tools directory . Confirm that the selected explorer is showing the expected chain.
A token with the same ticker on another chain may be unrelated. Do not use a bridge route or contract address copied from a third-party chat.
Read contract source and permissions
If the contract’s source is available, examine the parts that control transfers, supply, and administrative actions:
- Can an owner, role, or external contract pause transfers or block particular addresses?
- Can an authorized account mint more tokens, change fees, or alter transfer rules?
- Can the implementation be upgraded? If so, who controls the proxy admin or upgrade role?
- Do transfer hooks call another contract or depend on a mutable allowlist?
- Can an administrator change the router, pair, or fee destination?
- Are there hidden or hard-to-explain calls that can move funds?
OpenZeppelin’s access-control documentation explains how owner and role permissions can control functions such as minting or freezing transfers. Trace the actual role assignments and upgrade path where possible; a role name alone does not show who can exercise it.
Ethereum.org explains that source verification checks whether published source corresponds to deployed bytecode. Verification makes code inspectable; it does not prove the code is correct or safe. See its contract verification overview . If a contract is unverified, a proxy’s implementation cannot be identified, or you cannot understand a privileged function, record that uncertainty instead of treating it as a green flag.
Check the actual trading and exit route
Find the exact market or pool address used by the application. Read the app’s own documentation to confirm which router and contracts a swap will call. Check the current quote, liquidity available at your intended order size, and whether the route depends on a bridge or external service.
Do not rely on a single liquidity number. It may describe one pool, change quickly, or omit the contract that controls liquidity. Check who can withdraw or change it, whether liquidity is subject to a lock or vesting contract, and what rules govern that lock. A lock display is not a guarantee that the token itself can be sold.
Where a trusted transaction simulator is available, inspect both the buy and sell paths using the same wallet and current contract state. A simulation is a snapshot: it cannot prove that a later transaction will pass or that the rules will remain unchanged. A tiny live test can still lose funds and does not establish that larger sells will work.
Review distribution and project claims
On-chain balances and transfer history can show concentration and movement, but addresses may represent exchanges, pools, contracts, teams, or unrelated users. Do not label an address an insider without evidence. Large holder counts or visible trading activity do not establish a fair distribution or reliable exit.
Check project claims against primary documents:
- Is the team or operator named, and can its public history be verified?
- Are contract addresses and upgrade administrators disclosed?
- Are claims about audits linked to the actual report, scope, date, and covered contracts?
- Are token supply and lock-up statements supported by contracts or signed project documentation?
- Does the project explain how its application earns revenue or handles user funds?
Social activity, a contract badge, an audit logo, or an explorer listing is not a substitute for those checks.
Protect your wallet
- Use the chain and contract address you independently confirmed.
- Read the full transaction and signature prompt before approving it.
- Limit token allowances to what the transaction needs when the wallet allows it.
- Review and revoke unused allowances through a trusted interface.
- Never reveal a seed phrase or private key to a project, bot, scanner, or support representative.
- Keep assets you cannot afford to lose separate from experimental activity.
Hyperliquid’s support guidance warns users to check full website URLs and never share wallet secrets.
When a check fails
Stop if the token address differs from the project’s official materials, the trade route is unclear, critical contract permissions cannot be identified, or the wallet asks for an unexplained approval. Do not increase slippage or repeatedly sign transactions to force a sale. Preserve the contract address, transaction hash, and exact site URL, then use the project’s verified support channel or relevant official reporting route.
A failed simulation, a successful tiny test, or a scanner result is one observation. None is a safety certification. If you cannot establish how the token works and how an exit could fail, the responsible result is to leave the risk unresolved.
Limits of this review
HypeChain checked the official and technical documentation linked below on October 3, 2026. We did not inspect current token contracts, verify project claims, run scanners, test swaps, audit code, or maintain a complete incident database. This guide makes no token recommendation and does not classify any asset as safe.
Sources
- HyperEVM documentation — network identity and RPC.
- Hyperliquid onboarding — network setup and supported explorer references.
- HyperEVM builder tools — current ecosystem explorer directory.
- Hyperliquid support — wallet-secret and URL safety.
- Ethereum contract verification — what source-code verification does.
- OpenZeppelin access control — owners, roles, and privileged contract functions.
Related guide
MEV Risks on HyperEVM and HyperCore explains why transaction ordering and EVM calls need separate risk checks.