Forem: Chainstack

Hyperliquid HIPs Explained: HIP-1 to HIP-4

Chainstack — Fri, 08 May 2026 08:33:30 +0000

TL;DR

Hyperliquid Improvement Proposals (HIPs) are formal, on-chain protocol upgrades governed by HYPE token holders. Each proposal targets a specific domain: HIP-1 introduced the native token standard and spot order books, HIP-2 embedded an automated liquidity mechanism into HyperCore to solve the cold-start problem for new token launches, HIP-3 made perpetual futures deployment permissionless for builders who meet the staking requirement, and HIP-4 introduces outcome contracts — binary markets that settle to 0 or 1 in USDH based on whether a specified real-world event occurs.

All of this runs on HyperCore, a fully on-chain central limit order book with one-block finality, paired with HyperEVM for general smart contract execution. The public API exposes the same endpoints across all market types, making it straightforward for builders to extend existing integrations to new primitives as each HIP activates.

What are Hyperliquid HIPs?

A Hyperliquid Improvement Proposal is a formal, on-chain protocol upgrade mechanism for the Hyperliquid blockchain. Proposals are authored by builders, reviewed by the community, and implemented directly into HyperCore. Governance is HYPE token weighted — any eligible participant can submit a proposal, HYPE holders vote proportional to their stake, and approved changes are integrated into the protocol stack.

This design keeps protocol evolution modular. Each HIP targets one specific domain rather than bundling broad changes into a single upgrade. The chain never forks — the protocol extends.

Hyperliquid architecture overview

HyperCore is the fully on-chain central limit order book (CLOB) at the heart of Hyperliquid. All order books, trades, and liquidations are recorded on-chain with one-block finality. There is no off-chain matching layer. The consensus mechanism is HyperBFT, running on a dual-layer design: HyperCore and HyperEVM.

HyperEVM is an EVM-compatible execution environment on the same L1. Standard Ethereum tooling — ethers.js, viem, Foundry, Hardhat — works without modification. The two environments share state but are optimized for different workloads: HyperCore handles the high-frequency trading loop, HyperEVM handles general smart contract execution.

The public API exposes two primary endpoints. The /info endpoint handles all read-only queries: market metadata, order book depth, user state, and fills. The /exchange endpoint handles all signed write operations: order placement, cancellation, leverage updates, and market deployment actions.

Why HIPs matter for builders

HIPs extend HyperCore in a structured way, adding new market types directly into the core matching and settlement engine. Spot markets, perpetuals, and outcome contracts all run on the same CLOB, price-time priority matching engine, account and margin system, and API structure.

This creates a stable integration surface. A bot built for spot under HIP-1 can route orders to perpetuals under HIP-3 using the same execution logic. The same bot can trade HIP-4 outcome markets by adjusting position sizing and payoff logic, while reusing order handling, signing, and state tracking. Differences between HIPs show up as metadata rather than requiring new infrastructure.

HIP-1: Native token standard

HIP-1 established the formal fungible token standard on Hyperliquid. It introduced a governance-based process for new spot token listings and the on-chain spot order books that back them. The PURR memecoin was the first live deployment of HIP-1 infrastructure.

Querying spot metadata uses the /info endpoint:

const options = {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({type: 'spotMeta'})
};
fetch('https://hyperliquid-mainnet.core.chainstack.com/API_KEY/info', options)
  .then(res => res.json())
  .then(res => console.log(res))
  .catch(err => console.error(err));

HIP-2: Hyperliquidity mechanism

HIP-2 introduced an on-chain liquidity mechanism embedded directly into HyperCore. When a new spot token launches, Hyperliquidity automatically places buy and sell orders around the current price, seeding the order book with depth before any human market maker participates. When PURR/USDC launched, Hyperliquidity seeded initial depth instantly — real trades executed before any external liquidity provider connected.

The mechanism operates continuously for supported tokens, contributing to a stable spread and reducing impact cost for early traders. From a builder's perspective, HIP-2 markets are indistinguishable from any other spot market at the API level — same order book query, same asset index, same fill events.

HIP-3: Permissionless perpetuals

HIP-3 was activated on Hyperliquid mainnet in October 2025. It made the deployment of perpetual futures markets permissionless. The staking requirement for mainnet is 500k HYPE. A builder meeting this threshold can deploy one perpetual DEX and control market operation: setting oracle prices, configuring leverage limits, and settling markets if needed.

HIP-3 markets have already reached $1B in open interest and $4.8B in 24-hour volume. Silver and Gold commodity perpetuals launched under HIP-3 reached ~$3B and ~$700M weekly volume respectively. The NVDA equity perpetual accumulated over $1.2B in cumulative volume.

💡 Want the full HIP-4 breakdown — outcome contract mechanics, the opening auction, continuous trading, settlement, builder considerations, and code examples? Read the complete article on Chainstack Blog →

HIP-4: Outcome contracts (preview)

HIP-4 was announced February 2, 2026, with testnet infrastructure active from the announcement date. It introduces outcome contracts: fully collateralized binary instruments that settle to exactly 0 or 1 in USDH based on whether a specified real-world event occurs.

Unlike spot and perpetual markets, outcome contracts have no continuous underlying price process, no incremental oracle-driven pricing, and no funding or basis mechanics. Price discovery occurs entirely through the order book during trading; external input appears only at resolution. The staking requirement for deployment is 1,000,000 HYPE — double the HIP-3 requirement. HIP-4 mainnet launches in two phases: curated canonical markets first, permissionless builder deployment second. No date for either phase has been confirmed.

The full article covers the complete HIP-4 mechanics — outcome contract lifecycle (deployment, opening auction, continuous trading, settlement), payoff math, code examples for fetching outcome metadata, and key builder considerations including oracle dependency, expiry-driven load, and staking concentration.

Read the full article on Chainstack Blog → https://chainstack.com/hyperliquid-hips-explained/

Resources

Deploy blockchain nodes on your own infra: Introducing Chainstack Self-Hosted

Chainstack — Mon, 04 May 2026 13:53:37 +0000

Our goal has always been to be the go-to blockchain node platform across any chain and environment. Today, that includes the nodes you run on your own hardware.

Running your own Ethereum infrastructure should be the basic right of every individual and household. Nodes should be easy.
Vitalik Buterin · Mar 15, 2026

The catch? Self-hosting has always meant complexity. Manual setup, client updates, nodes falling out of sync, monitoring cobbled together from spare parts.

We built Chainstack Self-Hosted to fix that.

What is Chainstack Self-Hosted?

Chainstack Self-Hosted is a turnkey blockchain node management platform that lets you deploy and operate blockchain nodes on infrastructure you fully own and control — from cloud VPS to your local environment, and everything in between.

It brings the operational layer that Chainstack has built for managed infrastructure and makes it available on your hardware. That means automated deployment on any protocol, built-in monitoring and alerts, self-healing, automated updates, and configurable failover — all running inside your own environment, with your data never leaving your perimeter.

The core idea is simple: you shouldn’t have to choose between owning your infrastructure and having a production-grade operational experience. Chainstack Self-Hosted gives you both.

How it compares to DIY

If you’ve run self-hosted nodes before, you know what DIY actually looks like in practice. We wrote a detailed breakdown of the challenges and a direct comparison of DIY vs Chainstack Self-Hosted if you want to go deeper — but here’s the short version:

What you get

One-click deployment across all major protocols: Select your protocol, network, and node type — and you’re live in minutes. Right-sized node configurations are applied automatically based on your hardware and protocol requirements, so you’re not guessing at specs. Snapshots reduce initial sync time significantly, cutting what used to take days down to hours.

Self-Healing and auto-updates: Nodes monitor themselves and recover automatically from failures. When client updates are available, you get notified and control when they’re applied — no manual coordination, no maintenance windows that turn into incidents.

Zero downtime failover: Configure failover to a secondary node, a Chainstack high-performance RPC endpoint, or any endpoint you specify. Your applications stay online even when a node goes through an update or unexpected failure.
Monitoring, alerts, and observability: Real-time insights into node performance, alerts for important events, and the data you need to understand what’s happening across your infrastructure — without building a monitoring stack from scratch.

Your data stays yours: Nodes run in secure, isolated environments with encryption and strict access controls. Nothing leaves your infrastructure. Chainstack Self-Hosted is built for teams where data sovereignty isn’t optional.

Who it’s for

Chainstack Self-Hosted is built for teams and individual developers who need the operational maturity of a managed service without giving up control of their infrastructure.

That includes enterprises with compliance and data residency requirements, teams that need to own their node stack, traders that need guaranteed RPC access without rate limits, and developers that are tired of spending cycles on node maintenance instead of product development.

If you’ve been putting off self-hosting because of the operational overhead — or if you’re already self-hosting and spending too much time keeping things running — this is built for you.

Get started

Chainstack Self-Hosted is available now. Check out the documentation to get started, or jump straight into the quick start guide.

Explore Chainstack Self-Hosted →

Self-hosted blockchain node: challenges and solutions

Chainstack — Wed, 29 Apr 2026 04:43:48 +0000

Running a self-hosted blockchain node — one that validates transactions and provides blockchain data to dapps, wallets, and exchanges — is a key way to participate in and help secure a decentralized network. But the real challenges emerge after deployment, not during setup.

Ethereum founder Vitalik Buterin acknowledged the problem directly: managing a node has quietly become a complex DevOps task handled by professionals, despite that never being the intention. Most teams end up choosing between running nodes themselves — with all the operational burden that entails — or handing control to a third-party provider. Chainstack Self-Hosted is a third path: a control plane that deploys and manages full blockchain nodes on your own infrastructure, reducing deployment time from weeks to hours.

Why organizations self-host

Exchanges, wallets, infrastructure providers, and financial organizations rely on direct blockchain data access as part of their core systems. Running their own nodes lets them verify transactions independently and avoid API dependency on external providers. Coinbase, Kraken, Consensys, and Circle all operate their own nodes. The question isn't whether to self-host — it's how to do it without it becoming a full-time operational burden.

Challenge 1: Time to sync nodes

A node isn't ready to use immediately after deployment. Before it can serve applications, it must download the full blockchain and synchronize with the latest block and global state. According to Besu documentation, a fast sync takes 1.5 days; a full sync takes weeks. Teams already spend significant time on initial hardware and software setup — sync time compounds that delay further.
Chainstack Self-Hosted supports snap sync, allowing nodes to start from a recent verified state rather than downloading all historical data. Most major protocols — Polygon, Base, Optimism — now recommend snap sync specifically to bring nodes online faster.

Challenge 2: Enterprise-grade architecture

Institutional teams need infrastructure that is reliable and scalable from day one, not something they assemble themselves and harden over months. Under the hood, Chainstack Self-Hosted runs on Kubernetes, providing reliability and scalability without requiring operators to build or maintain the underlying architecture. Nodes run in secure environments with encryption and strict access control.
When a self-hosted node fails, operators can fall back to Chainstack's production-grade RPCs — 99.99% uptime, 24/7 SLA-backed operations, low-latency global endpoints — trusted by more than 1,000 customers. Self-Hosted currently supports Ethereum Mainnet, Sepolia, and Hoodi, with plans to expand to 70+ protocols. It uses Reth as the execution client and Prysm as the consensus client, with predefined configurations that reduce misconfiguration risk.

💡 Want the full breakdown — node monitoring and update management? Read the complete article on Chainstack Blog →

Challenge 3: Node monitoring

As of March 2026, Ethernodes estimates 29% of nodes are out of sync at the execution layer and 6.2% at the consensus layer. Without centralized visibility, operators often don't know a node has fallen behind until an application breaks.

Challenge 4: Updating nodes

Ethereum runs a twice-yearly hard fork schedule — nodes that miss an update become incompatible with the chain. In 2025 alone, Reth published 33 releases and Prysm 18. Coordinating updates across multiple nodes manually, node by node, creates real risk of inconsistency and misconfiguration.

Conclusion

Deploying a node is straightforward. Operating it reliably over time is not. Chainstack Self-Hosted addresses the four main challenges — sync time, enterprise architecture, monitoring, and updates — letting teams fully own their infrastructure while using a managed control plane to run it.

💡 Want the full breakdown — monitoring, updates, and the complete comparison table? Read the complete article on Chainstack Blog →

Self-hosted blockchain node: DIY vs Chainstack Self-Hosted

Chainstack — Wed, 29 Apr 2026 02:53:14 +0000

Getting a blockchain node running isn't the hard part. The hard part is everything that comes after — keeping it synchronized, updated, monitored, and available, day after day. Most teams underestimate this. Deployment goes smoothly. Then a node falls out of sync at 2am. A protocol hard fork requires coordinated updates across every node. A client crashes and nobody gets alerted. This is where DIY self-hosting gets expensive — not in servers, but in engineering time.

Why organizations run a self-hosted blockchain node

Organizations self-host for three reasons: compliance (some industries mandate on-premises or jurisdiction-specific infrastructure), control (direct access to blockchain data without rate limits or API dependency), and cost (at scale, self-hosting beats managed node pricing). The question isn't whether to self-host — it's how much of your team's time you want to spend on infrastructure versus your actual product.

Two paths: build it yourself or use a control plane

Teams that self-host typically choose one of two approaches. DIY means assembling open-source components, writing your own deployment configs, setting up monitoring, and maintaining everything in-house. Chainstack Self-Hosted means deploying a control plane on your own infrastructure that handles the complexity — while you retain full ownership of the underlying servers and data. Both give you full infrastructure control. The difference is how much engineering time goes into maintaining the plumbing.

The reality of running a self-hosted blockchain node yourself

Setup and installation

A production blockchain setup requires container orchestration, storage provisioning, networking configuration, and monitoring — each with its own dependencies. A misconfiguration at any layer can prevent nodes from starting or corrupt existing data. For a single Ethereum node, this is manageable. The challenge compounds with every additional node or protocol: each new protocol means rebuilding the deployment system from scratch. Expect 2+ weeks to get a production-ready setup running for the first time.

Node deployment

An Ethereum node requires two separate clients — an execution client and a consensus client — that must communicate continuously. Every deployment decision (resource allocation, storage sizing, sync strategy) requires deep familiarity with both Kubernetes and the specific blockchain clients you're running. Every decision becomes a configuration artifact that someone on your team needs to maintain indefinitely.

Ongoing operations

Client updates, security patches, sync issues, and failed nodes all need ongoing attention. Without a centralized management layer, this knowledge lives in runbooks and whoever originally built the system. Expect roughly 4 hours per week per engineer to keep a DIY setup healthy — more during protocol hard forks or corruption events.

💡 This is a preview. Read the full article — including the complete comparison table and decision framework — on Chainstack Blog

Chainstack Self-Hosted: the same control, less overhead

Chainstack Self-Hosted runs on your infrastructure — your servers, your cloud, your data. The control plane handles deployment, configuration, monitoring, and updates instead of custom scripts and runbooks.
Installation runs in 5–10 minutes, versus 2+ weeks for a DIY production setup. The platform bundles production-ready configurations for authentication, workflow orchestration, state management, and the control panel — tested together, not assembled from scratch.

Node deployment happens through a web interface: select your protocol and click deploy. Chainstack Self-Hosted provisions Reth and Prysm with configurations tested in production — resource allocation, storage sizing, and sync modes are predetermined based on real-world requirements. Updates, monitoring, and recovery all happen through the same control panel. Failover routing lets you define where traffic goes when a node becomes unavailable — a secondary node, a Chainstack RPC endpoint, or one you specify.
The trade-off: you work within supported configurations rather than customizing every component. For most teams, tested defaults are faster and more reliable than custom setups. For genuinely specialized requirements, DIY may still be the right call.

The real cost: engineering time

Infrastructure hardware costs are easy to calculate. Engineering time is less visible but often larger. Building a production-ready DIY setup requires approximately two weeks from someone with Kubernetes and blockchain infrastructure experience. Ongoing maintenance runs ~4 hours per week. At typical senior engineer rates, that's roughly $6,000 upfront and $15,000+ annually — for a single protocol. Three protocols don't cost three times as much; coordination overhead compounds.
Chainstack Self-Hosted has a licensing cost. But the maintenance burden drops significantly, and the compounding value increases at scale. More importantly, engineering hours spent on infrastructure are hours not spent on the product that differentiates your business.

💡 Want the full comparison table and decision framework? Read the complete article on Chainstack Blog →