Back to Blog 
HyperliquidSecurity ChecklistDeFi
Hyperliquid Security Checklist for Builders: HyperBFT, HyperCore, HyperEVM Risks Before Mainnet
13 min
TL;DR, the Hyperliquid security checklist builders should clear before mainnet
If you are building on Hyperliquid, your main risk is not writing a normal Solidity app on a fast chain. Your real risk is misreading where security responsibility changes across HyperBFT, HyperCore, and HyperEVM. Teams that miss that boundary often ship contracts that look fine in isolation but fail when order flow, liquidations, token conversions, or exchange state assumptions hit production.
Use this Hyperliquid security checklist before code freeze:
- Consensus assumptions are explicit: your protocol documents what a HyperBFT halt, validator liveness issue, or RPC outage does to user flows.
- HyperCore dependencies are mapped: every balance, order, liquidation, vault, or token dependency coming from HyperCore is listed as a trust assumption, not treated like local EVM state.
- HyperEVM timing is tested: your team validates whether logic depends on small block cadence, large block cadence, or deployment specific big block settings.
- Bridging and transfer paths are reviewed: token movement between HyperCore and HyperEVM, plus any external bridge path, is tested against wrong address, wrong asset, and delayed settlement cases.
- Precompiles and reads are hardened: every HyperCore read path fails safely when data is stale, missing, or shaped differently than your contract expects.
- Liquidation and oracle logic is bounded: your app survives bad market conditions even when HyperCore state moves faster than your frontend or offchain automation.
- Audit readiness is real: architecture docs, deployment plan, threat model, and integration assumptions are frozen before mainnet review.
Hyperliquid builder next step
Run the free Krait readiness pass first, then scope the full review
This query cluster already attracts builders comparing HyperBFT, HyperCore, and HyperEVM before launch. Use Krait to pressure test contracts, permission paths, and integration assumptions while fixes are still cheap, then move into the quote path when you want Zealynx to validate protocol specific launch risk.
Why this query matters now
The existing Zealynx Hyperliquid cluster already captures builder intent from two angles. One page explains Hyperliquid architecture, HyperBFT, HyperCore vs HyperEVM. Another explains what Hyperliquid is and how developers can use it. Those pages are useful, but they still leave a commercial gap for a higher intent search like hyperliquid security checklist.
That query usually comes from teams that are past curiosity. They are deciding whether their integration is safe enough to launch, whether they are about to misuse HyperCore data, and whether they need a pre audit review before mainnet. That is exactly where a checklist article should help.
The core mental model, HyperBFT secures ordering, HyperCore owns exchange state, HyperEVM hosts your contracts
Start with one rule. Do not treat Hyperliquid like a standard EVM chain with an app on top.
According to the Hyperliquid developer docs, HyperEVM blocks are built as part of Hyperliquid execution and inherit security from HyperBFT consensus. The same docs also note that HyperEVM uses JSON RPC, EIP 1559 style gas, and HYPE as the native gas token. Separately, the Chainlink Hyperliquid integration guide describes the dual network model clearly: HyperCore handles the high speed trading state and HyperEVM handles external smart contracts.
That leads to the practical security model:
- HyperBFT gives you shared ordering and finality assumptions.
- HyperCore is the source of truth for exchange native state, such as spot balances, order books, liquidations, and protocol managed market behavior.
- HyperEVM is where your contracts live, but not where the full market truth originates.
If your team forgets that split, you will mis scope the threat model.
Hyperliquid security checklist, 4 domains to clear before mainnet
1. HyperBFT and chain level assumptions
1.1 Document what happens if the chain slows, halts, or degrades
HyperBFT is designed for fast finality, which is a major strength. But builders should not convert that strength into a hidden assumption that the chain is always live, always reachable, and always mirrored perfectly by every RPC endpoint they use.
Checklist
- Define whether users can cancel, pause, redeem, or unwind if Hyperliquid RPC access is degraded.
- Identify every keeper, backend, or frontend path that depends on fresh Hyperliquid data.
- Decide which functions should pause versus continue in degraded chain conditions.
- Confirm that guardian or admin actions do not rely on the same failing infrastructure path as user actions.
Common mistake
Teams write emergency logic that assumes they can always push a cleanup transaction through HyperEVM exactly when market stress is highest.
1.2 Separate finality confidence from operational availability
Fast finality is not the same thing as guaranteed app level availability. Your contracts may be correct while your offchain automation, API clients, or monitoring stack still fail.
Checklist
- Run incident drills where reads fail but contracts remain deployed and correct.
- Verify that alerting covers RPC errors, stale reads, sequenced but unobserved events, and delayed operator action.
- Make sure user messaging explains whether funds are locked, delayed, or still safe.
2. HyperCore trust boundaries
2.1 List every place your protocol depends on HyperCore state
HyperCore is not a generic storage layer you control. It is the protocol financial engine. If your app reads balances, order state, or exchange native token data through precompiles or offchain services, that dependency belongs in the threat model.
Checklist
- Inventory all reads that originate from HyperCore, including balances, positions, fills, vault state, and market metadata.
- Mark whether each dependency is used for pricing, permissions, accounting, settlement, or UX only.
- Decide which reads are advisory and which ones are safety critical.
- Add explicit fallback behavior for missing or delayed HyperCore reads.
Common mistake
A vault or router treats a HyperCore balance read as if it were equivalent to local ERC 20 accounting, then uses that assumption for withdrawals or position sizing.
2.2 Review liquidation and margin adjacency carefully
The Chainlink integration guide highlights that Hyperliquid combines HyperCore trading state with HyperEVM applications. That is powerful, but it also means your contract may sit next to liquidation and order flow dynamics it does not control.
Checklist
- Model what happens if collateral value changes sharply between a read and an action.
- Review whether user vault logic can be sandwiched by market moves, liquidations, or delayed automation.
- Bound leverage, batch size, and execution assumptions around fast moving exchange conditions.
- Verify that liquidation related state cannot silently break accounting invariants in your contract.
2.3 Treat HIP 1 and ERC 20 paths as different systems
Hyperliquid uses native HIP 1 assets in HyperCore and ERC 20 tokens in HyperEVM. The integration guide makes that distinction explicit. If your team blurs those models, you risk permanent deployment mistakes.
Checklist
- Document which asset representation each function expects.
- Verify conversion, transfer, and user messaging flows between HyperCore and HyperEVM.
- Test wrong asset index, wrong system address, and wrong decimals cases.
- Confirm that spot slot or token configuration mistakes cannot trap user funds in the happy path.
3. HyperEVM execution and deployment risks
3.1 Respect the dual block model when designing user flows
HyperEVM uses small blocks for ordinary execution and large blocks for heavier actions such as deployments. The Chainlink guide summarizes this as roughly one second small blocks and one minute large blocks, and notes that developers may need to explicitly switch to big blocks for deployments.
That matters because many teams prototype on simple assumptions, then discover their launch tooling or deployment scripts depend on the wrong execution cadence.
Checklist
- Test deployment scripts with the exact big block settings required for production.
- Confirm frontends do not promise timing guarantees tighter than the chain can deliver.
- Audit multi step flows that assume immediate follow up state after deployment or configuration changes.
- Rehearse redeploy and rollback procedures if a large block deployment partially succeeds.
3.2 Harden precompile reads and contract assumptions
HyperEVM can access HyperCore state through precompiles. This is useful, but every precompile boundary deserves the same care you would give to an external system dependency.
Checklist
Get the DeFi Protocol Security Checklist
15 vulnerabilities every DeFi team should check before mainnet. Used by 30+ protocols.
No spam. Unsubscribe anytime.
- Validate decoding assumptions for every precompile response.
- Decide how your contract behaves if a read fails, returns zero, or returns data outside expected bounds.
- Make sure externalized read assumptions are mirrored in tests and spec docs.
- Keep authorization logic independent from brittle external data whenever possible.
Common mistake
Teams gate sensitive functions on an external state read that was only tested on the happy path and never fuzzed against malformed, stale, or boundary values.
3.3 Do not import standard EVM playbooks without adaptation
HyperEVM supports familiar Solidity patterns, but a Hyperliquid app still lives next to a protocol specific execution environment. Reusing Ethereum mainnet assumptions blindly is how teams under scope reviews.
Checklist
- Re evaluate oracle, bridge, and settlement assumptions for Hyperliquid specific flows.
- Review whether your protocol needs extra monitoring around market state changes that do not exist on a normal app chain.
- Test governance and admin procedures against chain specific deployment and funding requirements.
4. Oracle, bridge, and integration edge cases
4.1 Bridge dependencies deserve first class threat modeling
Many Hyperliquid teams will bridge assets in, deploy on HyperEVM, then expose user deposits to multiple trust layers at once. That is not just a contract audit problem. It is an integration audit problem.
Checklist
- Enumerate every bridge, relayer, and external token representation in your flow.
- Define what the app does if a bridge pauses, a relayer delays, or wrapped supply drifts from expected state.
- Add caps and circuit breakers for newly bridged assets before they reach large TVL.
- Keep emergency withdrawal logic simple and tested.
4.2 Oracle assumptions must be tied to liquidation speed
If your app relies on exchange native data, external price feeds, or both, you need to know which system leads during stress.
Checklist
- Map all price inputs used for collateral, health factors, fees, and liquidations.
- Define max staleness for each price path.
- Test divergent prices, delayed updates, and abrupt gaps.
- Verify that fallback logic cannot be manipulated into a better price path.
A short pre audit readiness checklist for HyperEVM teams
Before code freeze, a Hyperliquid team should be able to hand an auditor the following without scrambling:
- A one page architecture note showing HyperBFT, HyperCore, HyperEVM, offchain services, and user fund flows.
- A list of every HyperCore dependency, precompile use, and bridge dependency.
- Deployment runbooks for mainnet, including gas funding, big block requirements, and rollback steps.
- Tests that cover stale reads, failed reads, delayed automation, and wrong asset mapping.
- Admin and guardian procedures that work during chain stress.
- A clear statement of what is out of scope, especially if your contracts depend on exchange native behavior you do not control.
If you cannot produce those artifacts quickly, your audit is starting too late.
The integration mistakes we see most often
Across exchange infrastructure and app chain deployments, the mistakes repeat:
- Treating HyperCore like local app state, then using it for accounting decisions without failure bounds.
- Ignoring deployment cadence, especially when contracts or setup actions depend on large block behavior.
- Blurring HIP 1 and ERC 20 asset paths, which creates token mapping and user fund handling errors.
- Assuming fast finality removes operational risk, even though keepers, frontends, and RPCs can still fail.
- Starting the audit with no system diagram, which forces auditors to reverse engineer integration assumptions instead of reviewing protocol risk first.
These are preventable, but only if they are acknowledged before launch pressure takes over.
When to move from checklist to audit
A checklist is not a substitute for a real review. It is a filter for obvious scope mistakes.
You should move into a Hyperliquid audit when any of the following are true:
- You read HyperCore state to make safety critical decisions.
- You combine user deposits with trading, vault, liquidation, or collateral logic.
- You depend on token transfers between HyperCore and HyperEVM.
- You need confidence that deployment and rollback procedures are safe under mainnet conditions.
- You already know the architecture, but you are no longer sure the trust boundary is scoped correctly.
Final takeaway, the real Hyperliquid checklist is about boundaries
The best Hyperliquid teams do not just ask whether the Solidity compiles or whether the tests pass. They ask where responsibility changes across the stack, which assumptions belong to HyperBFT, which belong to HyperCore, and which belong to their own HyperEVM contracts.
That is the checklist that prevents mainnet surprises.
Hyperliquid audit readiness
Use Krait for the first pass, then bring Zealynx in for the launch blockers
If your team is mapping HyperCore dependencies, precompile reads, deployment timing, and bridge assumptions right now, you are already in pre audit territory. Krait helps you catch cheap mistakes early. Zealynx helps you validate the system level risks before you ship.
FAQ, Hyperliquid security checklist
Do HyperEVM contracts inherit HyperBFT security automatically?
They inherit chain level ordering and finality from HyperBFT, but your application still owns contract logic, admin controls, deployment safety, integration correctness, and offchain operational risk.
What is the biggest builder mistake on Hyperliquid?
The most common mistake is treating HyperCore state like ordinary local EVM state, then using that assumption in accounting, liquidation, or permission logic without enough failure handling.
Is a Hyperliquid security checklist enough before mainnet?
No. A checklist helps catch obvious architecture and integration mistakes. If user funds, vault logic, market interactions, or bridge dependencies are involved, you still need a protocol specific security review.
When should we request a Hyperliquid audit quote?
Request a quote once the architecture, trust boundaries, deployment plan, and integration assumptions are stable enough that an auditor can review the real system, not a moving target.
Get the DeFi Protocol Security Checklist
15 vulnerabilities every DeFi team should check before mainnet. Used by 30+ protocols.
No spam. Unsubscribe anytime.