# **FQ-BTC on Hyperliquid**

## TL;DR

**Product:** BTCFQ (Front-Quarter BTC), a “dated-perp” implemented as a HIP-3 perp that is **funding-free** and **settles at a scheduled time** via `haltTrading`

**What it tracks:** A **Front-Quarter Delivery Index** (median of Binance/Bybit/OKX *quarterly* BTC futures mids).

**Key MM property:** We continuously publish the Delivery Index into **HIP-3 `markPxs`**, so both **risk/margin** and **halt settlement** reference an externally hedgeable object (CEX quarterlies), not Hyperliquid’s native BTC perp.

**Funding:** disabled (funding multiplier = 0).

**Settlement:** at a pre-announced timestamp we push a final oracle update (respecting ≥2.5s spacing), then call `haltTrading` to cancel orders + settle positions to **current mark price**; later we unhalt and recycle for next quarter.

## What is BTCFQ

BTCFQ is a HIP-3 perpetual market purpose-built to behave like a **fixed-maturity BTC futures leg** on Hyperliquid:

1. **Index-referenced:** the market is anchored to a **Front-Quarter Delivery Index** derived from liquid CEX quarterlies (Binance/Bybit/OKX).
2. **Zero funding:** funding is disabled by setting the HIP-3 funding multiplier to `0`.
3. **Scheduled settlement:** at expiry we settle using Hyperliquid’s `haltTrading` (settles positions to **mark price**), then recycle the asset slot for the next quarter.

When paired with Mobius strategy tooling, BTCFQ becomes a clean, delivery-anchored leg for delta-neutral vaults and other structured strategies on Hyperliquid.

## Why BTCFQ

### A necessary leg for delta-neutral strategies on Hyperliquid
Today, a “native” carry trade on Hyperliquid usually means **long spot + short perp**, which is:
- **funding-dependent** (can flip sign in bear regimes),
- often **capital-inefficient** (one leg frequently can’t be margined the way you’d want), and
- mechanically awkward for many users.

BTCFQ provides a more intuitive “dated” short/long leg with **no funding drift**, enabling structured carry strategies that are less regime-dependent.

### Why a delivery index (not just spot)
A “minimal dated perp” (spot oracle, funding = 0, settle by `haltTrading`) tends to drift rich when shorts hedge via perps and price in expected funding. Anchoring to delivery allows makers to hedge with **quarterly futures** (no perp funding bleed), tightening spreads and producing a more meaningful curve (Delivery − Spot) rather than an internal surcharge.

## Why HIP-3

* **We can mirror dated economics with low surface area via HIP-3:**
* set our **oracle** to a **front‑quarter delivery index** (median of Binance/Bybit/OKX quarterlies),
* set **funding = 0** on the “dated” leg, and
* **settle** positions by calling **`haltTrading`** at a published time (settlement pays **MARK**).
* **MARK is maker‑friendly:** HL’s MARK updates ~**every 3s** and is the **median** of (oracle+EMA, HL microprice, external perp mids). We also supply **`externalPerpPxs`** so MARK can’t be yanked by a local print into settlement. That’s exactly what lets market makers quote tight through the event.

## Why Mobius

**Only Mobius can make dated futures work for delta neutral strategies on Hyperliquid**

HIP‑3 markets are **natively isolated** (`onlyIsolated: true`), but Mobius **packages both legs** inside one strategy so Mobius users enjoy portfolio margins even though HL books see two isolated positions.

**Organic two‑leg flow**

* **Mobius** routes **Long BTCFQ / Short spot‑perp** with best‑ex guardrails, generating predictable two‑leg flow makers can model.

**Microstructure advantage**

* HL’s **MARK** is robust and predictable (~q3s updates, median of oracle/micro/external perps). Our oracle cadence + `externalPerpPxs` reduces print risk into `haltTrading` so makers can quote tight through settlement.

**Economic flywheel**

* **Users** get a clean delivery‑anchored leg (no funding) → better realized carry.
* **Makers** get paid for tight books and inventory → better spreads & depth.
* **Mobius** reinvest HIP‑3 **fee‑share** into rebates → more flow → more fees → stronger books.

As a result, users get **leveraged, delta‑neutral carry** that *feels* cross‑margined, while makers face a **delivery‑anchored**, funding‑free short (hedgeable in quarterlies), so they **don’t** price a “perp‑hedge funding tax.” **FQ-BTC + Mobius** creates a two‑sided market that’s *easier* for MMs to warehouse and *better* for users to farm.

*For the long‑form background, see our essay: [**A Case for Dated Futures on Hyperliquid: What, Why, and How**](https://x.com/dunkin_torus/status/1988527406219723235)*

## Why BTCFQ over a minimal “dated perp”
A minimal design (spot oracle, funding=0, settle‑by‑halt) tends to drift rich because shorts hedge long perps (they pay funding) and charge it back as a premium that decays into settlement. Anchoring to delivery lets shorts hedge in quarterlies (no funding bleed), so spreads tighten and users trade a real curve (Delivery − Spot), not an internal surcharge.

#### ❌ Minimal dated futures design
Use the regular spot oracle, turn funding to zero, and rely on `haltTrading` for settlement. This keeps surface changes small but forces every short (including market makers) to hedge with the HL's main perp, so expected funding costs get pushed into the quote price as an artificial premium that decays into expiry.

#### ✅ BTCFQ
Register a HIP‑3 market that points its oracle to a front‑quarter delivery index, still zeroes funding, and halts for settlement—but now the oracle reflects a real dated curve. Makers could hedge in quarterlies (delivery instruments) on other venues, so spreads show true basis instead of perp funding costs, and users can run clean delta‑neutral carry without subsidizing someone else’s hedge.

#### Example
Assume spot = $60k, HL perp = $60.1k (pays 0.05%/day to longs), and the CEX front-quarter future = $61k (2 months to expiry).

**Minimal HIP‑3:** you quote the dated contract at $60.2k, get lifted, and are now short $60.2k that will settle to MARK ≈ spot. To be flat, you must buy something that settles to the same object (spot). On HL the only such product is the perp, so you buy the perp at $60.1k and agree to pay funding until expiry—hence you immediately care about future funding and bake it into your quote.

**BTCFQ:** you quote $61k, get lifted, and are now short something that settles to the **delivery index** (the same $61k future). You can hedge by **shorting spot + borrowing** or, more simply, buying the exchange-traded quarterlies that converge to the same delivery print. No HL-perp hedge is needed, so there is no funding bill to pass through.

> **Premium decay:** Market makers that supply asks on a spot‑anchored “dated” perp are, by definition, **short** that contract whenever they get hit. The cleanest hedge is to long perp to offset the short inventory they just sold in the dated market, which usually trades rich to spot and therefore **pays funding**.
>
> Makers bake that expected funding cost into their quotes by marking the dated contract **above spot**; as actual funding accrues, the amount left to pay shrinks, so the premium bleeds toward zero (hence the name premium decay) even if spot is flat.
>
> Users feel this as a persistent roll cost that isn’t tied to real carry. FQBTC removes that behavior: by anchoring to delivery, makers hedge in quarterlies (no perp
funding drag), so they can quote on true basis instead of passing a hedge tax through the book.

## Spec

### Front-quarter delivery index construction
* **Constituents:** Track the nearest quarterly BTC futures listed on Binance, Bybit, and OKX venues.
* **Price normalization:** Pull the best bid/ask mid from each venue’s public order book API, convert to **USD per BTC**, and round to 2 decimal places before aggregation. Ignore feeds that are stale (>10s old) or deviating by >100 bps from the two-venue median.
* **Aggregation:** Take the **median** of the surviving feeds each cycle(one 3‑second sampling window aligned with the `setOracle` cadence). If only one venue remains, hold the last good median and flag the data source until at least two feeds recover. This median is what we refer to throughout the doc as the “delivery-weighted oracle” or “front-quarter delivery index.”
* **Cadence & publication:** Recompute every **3 seconds** because HIP‑3 enforces a minimum spacing of ~2.5 seconds between `setOracle` calls and stale marks revert to the local mark after 10s (per the Hyperliquid docs). Running at 3s keeps us inside those guardrails, keeps MARK fresh, and ensures settlement can’t be gamed with slow feeds. Remember that MARK (not last trade) drives margin, liquidation, and the halt-time settlement price. If we stop pushing, HL falls back to its own microprice, which mirrors the on-venue perp, so the “dated” leg would instantly revert to perp pricing. Frequent oracle pushes are therefore what actually keep BTCFQ anchored to the external delivery curve even while orderflow floats around. Each update writes the median into `oraclePxs` and mirrors it inside `externalPerpPxs`: MARK == median(oracle+EMA, HL microprice, external perps), so by seeding both legs with the delivery index we prevent HL’s microprice (which reflects local perp trades) from yanking MARK away from delivery right before `haltTrading`.

### Deployment Params

| Parameter | Value | Rationale |
|-----------|-------|-----------|
| `dex` | `FQBT` | 4-char DEX identifier (HIP-3 requires 2–4 chars) |
| `coin` | `BTCFQ` | Asset symbol traders see |
| `szDecimals` | `4` | Matches BTC perp precision on Hyperliquid |
| `marginTableId` | `20` | Single-tier 20× max leverage (conservative launch) |
| `marginMode` | `strictIsolated` | HIP-3 requirement; no cross-margin |
| `fundingMultiplier` | `"0"` | Disables funding — core product property |
| `openInterestCap` | `50,000,000` | $50M notional cap; must be ≥ max(1M, 0.5× current OI) |
| `feeRecipient` | `0x<REBATE_WALLET>` | Routes deployer fees to MM rebate program |

### Settlement

At a pre-announced expiry timestamp:
1. Push final `setOracle` (≥2.5s after previous update)
2. Call `haltTrading` → cancels all orders, settles positions to **mark price**
3. Unhalt and reconfigure for next quarter

### Route fee‑share to rebates(TBD)

{ "type":"perpDeploy","setFeeRecipient":{"dex":"FQPX","feeRecipient":"0xRebate"} }

*HIP‑3 deployers receive a **fixed 50% fee‑share** on their market.*

## Incentives

### Rebate Program

We share deployer fee revenue with market makers for tight spreads and deep books.

**Per-epoch (daily) accounting:**
- `fees_deployer` = deployer fee proceeds received at the feeRecipient address
- `rebate_budget` = 75% of `fees_deployer`

**Attribution & enforcement:** TBD (MM-by-MM terms / reporting / compliance).

### Token Incentive
In addition to the regular OI-volume–weighted points program, we may allocate up to 15% of the total token supply to market-maker incentives, subject to the terms we negotiate with individual market makers.

## Appendix

### Example JSON (Hyperliquid HIP-3 deployer actions)

> IMPORTANT: All lists of tuples should be lexicographically sorted before signing.

#### A) Register DEX + asset (using `registerAsset2`)

{
  "type": "perpDeploy",
  "registerAsset2": {
    "dex": "FQBT",
    "schema": {
      "fullName": "Front-Quarter BTC",
      "collateralToken": "<COLLATERAL_TOKEN_INDEX>",
      "oracleUpdater": "0x<ORACLE_UPDATER>"
    },
    "assetRequest": {
      "coin": "BTCFQ",
      "szDecimals": 4,
      "oraclePx": "61200.00",
      "marginTableId": 20,
      "marginMode": "strictIsolated"
    }
  }
}

#### B) Set OI cap

{ "type": "perpDeploy", "setOpenInterestCaps": [["BTCFQ", 50000000]] }

#### C) Disable funding

{ "type": "perpDeploy", "setFundingMultipliers": [["BTCFQ", "0"]] }

#### D) Set fee recipient (rebate wallet)

{ "type": "perpDeploy", "setFeeRecipient": { "dex": "FQBT", "feeRecipient": "0x<REBATE_WALLET>" } }

#### E) Oracle + mark publishing (every ~3 seconds)

{
  "type": "perpDeploy",
  "setOracle": {
    "dex": "FQBT",
    "oraclePxs": [["BTCFQ", "61192.35"]],
    "markPxs": [
      [["BTCFQ", "61192.35"]],
      [["BTCFQ", "61192.35"]]
    ],
    "externalPerpPxs": [["BTCFQ", "61190.00"]]
  }
}

**Interpretation:** The protocol takes the median of:
- local mark = median(best bid, best ask, last trade), and
- the 1–2 `markPxs` feeds,
to form the new mark update.

#### F) Settlement (halt + unhalt)

{ "type": "perpDeploy", "haltTrading": { "coin": "BTCFQ", "isHalted": true } }
{ "type": "perpDeploy", "haltTrading": { "coin": "BTCFQ", "isHalted": false } }