hip-03 protocol documentation

Source and lineage

hip-03 is a fork of Hyperliquid HyperCore. The upstream tree is the matching engine, the info API, and the staking ledger that already run Hyperliquid mainnet. We keep that remote wired and rebase engine fixes forward. As of this revision we are 2,114 commits ahead and 0 behind.

The fork exists for one reason. HIP-3 — Hyperliquid Improvement Proposal 3, launched October 2025 — already proved that third-party builders can deploy perpetual markets on HyperCore and take a material share of network volume. We wanted that path to be the only path.

Architecture

A hip-03 block is a HyperCore block. The engine still sequences orders, the book still matches price-time, and liquidations still run in the same tick as the rest of the book. What is different is that there is no privileged universe. Every market is aHip3Market. Native BTC-USD on this chain is just the first builder market we deployed against the BTC index.

pub fn connect_block(state: &mut State, block: &Block) -> Result<(), Reject> {
    // 1. Engine — unchanged from upstream HyperCore.
    state.engine.apply_orders(&block.orders)?;

    // 2. HIP-3 — every fill that touches a builder market updates the
    //    coin's mark and the builder's fee accrual. A conservation
    //    fault here rejects the block, not just the fill.
    for fill in &block.fills {
        state.hip3.apply_fill(fill)?;
    }

    // 3. Bonds — slash, if any evidence landed in this block.
    state.bonds.settle(block.height)?;

    let root = state.hip3.market_root();
    if root != block.header.market_root {
        return Err(Reject::BadMarketRoot { got: root, exp: block.header.market_root });
    }
    Ok(())
}

HIP-3

HIP-3 is a permissionless upgrade Hyperliquid launched in October 2025. It lets third-party builders deploy their own decentralized perpetual futures markets on HyperCore infrastructure. It is frequently cited as 30% to 40% of total Hyperliquid trading volume, and up to 50% during peak periods. Those numbers are the reason we forked: the market already voted, in volume, for builder-listed books.

The proposal has four mechanical claims. hip-03 implements all four as consensus.

Shared matching engine

HIP-3 markets do not get a slower engine. They sit in the same price-time loop as everything else. That is the whole point of building on HyperCore instead of spinning up an AMM and calling it a perp.

The consequence is load isolation by compute budget, not by book. A popular builder market can consume a large share of an engine tick. The cap is 4,194,304 compute units per block across all books, the same number HyperCore already used for native markets.

Long / short coins

This is the hip-03-specific piece. A deployed market mints a coin whose mark tracks the Hyperliquid index of the chosen underlying, or the negation of that index.

• Long coin. Mark = Hyperliquid index. If BTC-USD on Hyperliquid prints 108,241, the long-BTC coin marks 108,241.
• Short coin. Mark = −index, rebasing so a short holder gains when the index falls. Funding is inverted relative to the long coin on the same underlying.

Any crypto Hyperliquid lists is a legal underlying. The oracle bridge refuses a deploy against an index that is not in the live Hyperliquid universe. You cannot invent an asset Hyperliquid does not already price.

pub fn mark(market: &Hip3Market, index: &HlIndex) -> Result<Px, Hip3Err> {
    if !index.contains(market.underlying) {
        return Err(Hip3Err::UnderlyingNotOnHyperliquid(market.underlying));
    }
    let px = index.px(market.underlying);
    Ok(match market.side {
        PositionSide::Long => px,
        PositionSide::Short => px.invert_from_open(market.open_px),
    })
}

Oracle binding

Deployers pick an oracle, but they do not get to pick a fantasy price. The default binding is the Hyperliquid index for the same symbol. Alternative oracles are allowed only if they publish a signed deviation band against that index; a print outside the band is ignored and the book uses the Hyperliquid print.

That is how we keep HIP-3's “builders run oracles” claim without letting a builder print their own mark and liquidate the other side.

Fee customization

Deployers set maker and taker in basis points, subject to a protocol floor. They keep the residual after the floor is burned and validators take their share. Full numbers live on the fee schedule.

Staking and slashing

HIP-3 requires a substantial HYPE stake as a security bond. hip-03 sets that bond at 500,000 HYPE, locked for a 14-epoch cooldown after a market is closed. The bond is subject to slashing so that a builder who freezes a book, forges an oracle print, or equivocates on market parameters loses the stake rather than the users.

Run a node

$ git clone https://github.com/hip-03/hypercore.git
$ cd hypercore && git checkout v1.3.0-hip3
$ cargo build --release --features hip3,oracle-hl

$ cat > ~/.hip03/config.toml <<'EOF'
[node]
hip3 = true
oracle = "hl-main"
bind_info = "127.0.0.1:4000"
bind_exchange = "127.0.0.1:4001"

[bonds]
min_hype = "500000"
EOF

$ ./target/release/hip03d
$ hip03-cli info meta | jq '{markets: (.universe|length), hip3: true}'

RPC reference

Benchmarks

24-hour soak, 12 nodes, replaying Hyperliquid mainnet traffic at 4× with synthetic HIP-3 books mixed in at the observed 37% notional share.

Upgrade history

Known limits

• Underlyings are Hyperliquid's universe. If Hyperliquid does not list it, hip-03 will not bind a coin to it.
• The bond is real size. 500,000 HYPE is not a toy deposit. Markets without a bond do not exist.
• Shared engine means shared congestion. A crowded builder book slows every book in the tick, including yours.
• Perps can go to zero, and through it. A coin that is a short can theoretically be squeezed; a coin that is a long can theoretically unwind. This is not a cash token with a peg.