Hyperliquid Security Checklist for Builders: HyperBFT, HyperCore, HyperEVM

TL;DR, the Hyperliquid launch checks that matter

If you are building on Hyperliquid, do not scope security like a normal EVM deployment. Hyperliquid has three different trust boundaries that your launch plan has to respect:

HyperBFT, the consensus layer that finalizes the shared L1 block order.
HyperCore, the exchange engine that owns order books, margin, vaults, funding, liquidations, and native spot state.
HyperEVM, the smart contract environment that inherits HyperBFT finality but does not magically control every HyperCore failure mode.

That split is what makes Hyperliquid powerful. It is also what makes bad audit scopes dangerous. A HyperEVM contract can look clean in isolation while the real risk sits in order flow, liquidation timing, token linking, oracle assumptions, or the bridge between Core state and EVM state.

Use this Hyperliquid security checklist before mainnet, before code freeze, and before you ask an auditor to price the work.

Hyperliquid audit scope

Building on HyperEVM, HyperCore integrations, or exchange infrastructure?

Zealynx can scope a focused Hyperliquid security review around your contracts, signing flows, liquidation assumptions, oracle usage, token linking, and pre launch controls.

Request a Hyperliquid audit quote

Why Hyperliquid security is not just EVM security

A typical EVM audit asks whether the contracts preserve access control, accounting, invariants, upgrade safety, and integration assumptions. That still matters on HyperEVM. But Hyperliquid adds a separate exchange engine and a separate asset movement model.

The official HyperEVM docs describe EVM blocks as part of Hyperliquid execution, inheriting security from HyperBFT consensus. They also point out several details that matter to builders:

HyperEVM uses HYPE as the native gas token.
HyperEVM currently interacts through JSON RPC, not an official EVM frontend.
HyperEVM uses a dual block architecture with fast small blocks and slower large blocks.
HyperCore to HyperEVM transfers use system addresses and token linking.
Core to EVM transfer behavior depends on linked ERC20 contracts, emitted events, decimals, and system balances.

Those are not footnotes. They are security boundaries.

A lending protocol, vault, liquidation bot, structured product, market making tool, or trading terminal can fail even when its Solidity code passes a generic checklist. The launch question is not only, "Is the contract safe?" The better question is, "Does the full Hyperliquid system behave safely when consensus, exchange state, EVM execution, order flow, and offchain infrastructure move at different speeds?"

The three trust boundaries builders misread

1. HyperBFT, finality is not the same as application safety

HyperBFT gives the system fast finality and a shared block order. For builders, that reduces classic reorg assumptions. It does not remove operational or application level risk.

Security checks:

Can the protocol tolerate a chain halt or delayed finality without trapping user funds in an unsafe state?
Does the UI clearly distinguish pending, submitted, finalized, and failed actions?
Are keepers, market makers, and liquidation bots designed to pause safely if RPC data stalls?
Does the incident plan cover validator level censorship, RPC disagreement, and delayed execution?
Are contracts written so retries are idempotent when an offchain executor submits the same intent twice?

The mistake is treating finality as a replacement for defensive product design. Finality tells you when state is committed. It does not tell you whether your liquidation, oracle, or vault logic remained solvent during stress.

2. HyperCore, the exchange engine is part of your risk surface

HyperCore owns the native exchange functions that make Hyperliquid valuable. Order books, positions, vaults, funding, liquidations, and native spot mechanics live here.

Security checks:

If your app reads HyperCore state, what exact state does it trust, and how stale can it be?
If users can open or close positions through your interface, who signs the order, who relays it, and what can be replayed?
If your protocol depends on liquidations, can a delayed or failed liquidation create bad debt or unfair withdrawals?
If you use vault, margin, or position data, have you modeled correlated liquidation cascades instead of isolated position failure?
If you run keepers, are they rate limited, monitored, and able to degrade safely under volatile markets?

The audit surface is not just the code you deploy. It includes the economic and operational assumptions you import from HyperCore.

3. HyperEVM, EVM compatibility does not mean Ethereum equivalence

HyperEVM gives builders a familiar smart contract environment. That is useful, but familiar syntax can hide unfamiliar assumptions.

Security checks:

Does the contract depend on block timing assumptions that break under small block and large block scheduling?
Does deployment tooling correctly handle large contracts and the big block user flag when needed?
Does the protocol assume websocket JSON RPC support where the official RPC path may not provide it?
Does gas pricing logic account for HyperEVM fee behavior, including burned priority fees?
Do tests run against HyperEVM specific chain IDs, native HYPE behavior, and RPC quirks?

Porting Ethereum code is not enough. You need HyperEVM specific tests for timing, deployment, fees, integrations, and monitoring.

Launch blocking checklist by risk area

Order flow and signing

Order flow bugs usually come from ambiguity. A user thinks they signed one action. The system relays another. A backend retries a stale request. A frontend displays a safe price while the signed payload allows a worse path.

Pre launch checks:

Define every signer role, including user wallets, API wallets, relayers, keepers, admin keys, and backend services.
Validate EIP 712 domain separation and chain ID usage wherever typed data is signed.
Prevent replay across testnet, mainnet, staging, and internal tools.
Bind orders to explicit market, side, size, price, expiry, slippage, destination, and user intent.
Make cancellation semantics visible and testable.
Simulate duplicate submissions, delayed submissions, and partial failure.
Log signed payload hashes so incident response can reconstruct what users authorized.

If the user can lose money because the signature was broader than the UI implied, the launch is not ready.

Liquidation logic and solvency

Hyperliquid is performance oriented, but your protocol still has to survive adverse markets. Liquidation logic is not just a bot problem. It is a product solvency problem.

Pre launch checks:

Model price gaps, funding jumps, oracle stalls, and liquidity cliffs.
Test whether liquidation keepers compete safely or can grief each other.
Define who absorbs bad debt when a position cannot be liquidated in time.
Verify withdrawals cannot drain healthy collateral while unhealthy positions remain hidden.
Add circuit breakers for abnormal market states.
Measure liquidation latency from signal to signed action to confirmed state.
Run chaos tests where keepers stop, RPCs disagree, or markets move while transactions wait.

A liquidation system that works only during normal volatility is not a security control. It is an optimism layer.

Oracle and market data assumptions

Many Hyperliquid builders will be tempted to treat native market data as a free oracle. That can be valid in some designs, but only if the trust model is explicit.

Pre launch checks:

Identify whether each price comes from HyperCore, an external oracle, your backend, or a blended source.
Define stale price thresholds for every market.
Decide what happens when spot, perp, mark, index, and external prices disagree.
Test low liquidity markets separately from majors.
Prevent a single manipulated market from poisoning collateral valuation across the system.
Treat websocket streams as advisory unless confirmed by deterministic reads.
Record price source, timestamp, and confidence in critical state transitions.

The key question is simple, if the price lies for one block, one minute, or one market cycle, who pays?

HyperCore to HyperEVM asset movement

HyperCore and HyperEVM transfers are one of the most important audit areas because assets can cross a boundary where ERC20 behavior, system addresses, emitted events, decimals, and supply assumptions all matter.

Pre launch checks:

Verify every linked ERC20 bytecode and implementation before supporting it.
Confirm system addresses and token indexes match the intended asset.
Check decimals and any extra EVM wei decimal configuration.
Test non round amounts and dust behavior.
Do not assume ERC20 validity, supply sufficiency, or fungibility without verification.
Confirm Core to EVM transfer gas assumptions in user flows.
Monitor Transfer events and system address balances for anomalies.
Treat token linking as a privileged operation with its own runbook and approvals.

The official transfer model makes one thing clear, linking is not just a UI configuration step. It is part of the asset security model.

Bridge and external dependency risk

Get the DeFi Protocol Security Checklist

15 vulnerabilities every DeFi team should check before mainnet. Used by 30+ protocols.

No spam. Unsubscribe anytime.

Even if your core product lives on Hyperliquid, users, collateral, analytics, and admin workflows may depend on outside systems.

Pre launch checks:

Map every external bridge, RPC, indexer, custody service, oracle, signer, dashboard, notification service, and admin panel.
Decide which dependencies can block withdrawals or liquidations.
Add fallback RPC providers where safe, but avoid silent provider disagreement.
Validate bridge asset provenance and canonical addresses.
Separate monitoring credentials from trading or admin credentials.
Write a manual recovery path for each dependency that can fail.

Security does not stop at the chain boundary. It stops where user funds can no longer be harmed.

Common integration mistakes from docs to mainnet

Mistake 1, copying EVM deployment playbooks without HyperEVM checks

Generic Foundry or Hardhat deployment scripts may work for simple contracts, but larger deployments, chain IDs, block cadence, gas estimation, and RPC behavior need HyperEVM specific testing.

Fix it:

Add HyperEVM mainnet and testnet profiles.
Test small and large deployment flows.
Verify explorer, monitoring, and verification support before launch.
Dry run admin actions with production style wallets.

Mistake 2, treating exchange state as if it were contract storage

HyperCore state is not your contract storage. If your app depends on positions, fills, funding, or liquidations, the audit has to include read paths, synchronization, and failure behavior.

Fix it:

Document every Core read and who consumes it.
Compare API, websocket, and contract side views in tests.
Add stale data guards and explicit user warnings.
Pause risky actions when state freshness cannot be proven.

Mistake 3, making the backend the hidden custodian

Trading tools often hide dangerous privilege in a backend relay. If the backend can sign, replace, delay, reorder, or suppress actions, it becomes part of the custody model.

Fix it:

Minimize backend authority.
Put every relayed action behind user signed intent.
Use scoped API wallets and strict withdrawal limitations.
Log all privileged actions with tamper resistant audit trails.

Mistake 4, launching with testnet confidence but no mainnet stress model

Testnet validates flow. It does not prove production liquidity, keeper performance, user behavior, or economic safety.

Fix it:

Run scenario tests with mainnet like liquidity assumptions.
Stress withdrawal queues, liquidation queues, and stale data windows.
Add kill switches that are narrow, documented, and tested.
Publish user facing risk disclosures for unsupported edge cases.

Pre audit readiness checklist for HyperEVM teams

Before asking for a quote, prepare this package. It makes the review faster, cheaper, and more accurate.

Architecture artifacts

One diagram showing HyperBFT, HyperCore, HyperEVM, offchain services, signers, keepers, and users.
A table of trust boundaries and which component is allowed to move funds.
A list of all external dependencies and fallback behavior.
A clear statement of what is in scope and what is explicitly out of scope.

Code and deployment artifacts

Frozen commit hash.
Deployment scripts and chain configuration.
Admin key list and multisig policy.
Upgrade process, if any.
Emergency pause process, including who can unpause.

Economic and operational artifacts

Liquidation assumptions.
Oracle and pricing assumptions.
Funding, fee, and collateral logic.
Keeper architecture.
Bad debt handling.
Monitoring and alerting rules.

Test evidence

Unit tests for access control, accounting, and edge cases.
Integration tests against HyperEVM testnet or forked simulations where possible.
Scenario tests for stale data, delayed execution, duplicate submissions, and failed keepers.
Invariant tests for solvency and accounting.
Manual runbooks for bridge, oracle, and liquidation incidents.

If you cannot explain one of these areas, it belongs in the audit scope.

A practical Hyperliquid audit scope

A strong Hyperliquid review should not be priced only by Solidity lines of code. It should include the full money path:

User intent and signing.
Frontend and backend relay behavior.
HyperCore reads and writes.
HyperEVM contract logic.
Token linking and asset movement.
Liquidation and oracle assumptions.
Keeper operations.
Admin controls and incident response.

That does not mean every audit needs to be huge. It means the boundaries must be explicit. A narrow contract review is fine if the product truly has narrow risk. A trading, vault, margin, bridge, or liquidation system usually does not.

Final checklist before mainnet

Use this as the go or no go gate:

Conclusion

Hyperliquid gives builders a rare combination, high performance exchange infrastructure plus a programmable EVM environment. That combination is exactly why the security model deserves more care than a normal chain launch.

The dangerous failures will not always look like textbook reentrancy or access control bugs. They will look like mismatched trust boundaries, stale exchange state, over broad signatures, liquidation delays, token linking mistakes, bridge assumptions, and backend privilege that nobody put in the audit scope.

If you are building on HyperEVM, connecting to HyperCore, or launching exchange infrastructure around Hyperliquid, scope the full system before mainnet.

Need a focused review? Request a Hyperliquid audit quote from Zealynx and include your architecture diagram, frozen commit, signer model, and launch timeline.

Get the DeFi Protocol Security Checklist

15 vulnerabilities every DeFi team should check before mainnet. Used by 30+ protocols.

No spam. Unsubscribe anytime.