The peg: how HAM targets $1.00

HAM is launched in USD peg mode: the protocol's job is to keep HAM's market price near $1.00. This page explains how it measures that price and what it does about deviations. For exact parameter values and bounds, see the parameters reference.

The price signal

HAM trades in a Uniswap-V2-style pool against WHYPE (wrapped HYPE) — there is no direct HAM/USD market. So the protocol composes two measurements:

exchangeRate (USD per HAM) = TWAP(WHYPE per HAM) × (USD per WHYPE)
                             └─ from the pool ─┘   └─ from an oracle ─┘

• TWAP(WHYPE per HAM) — a 1-hour-minimum time-weighted average of the pool price. Using a TWAP (not the spot price) is the primary defense against someone manipulating a single block to force a rebase.
• USD per WHYPE — because this leg is on the critical path, it is dual-sourced from two native HyperCore price precompiles wrapped in Chainlink-style adapters: the perp oracle price (a validator-weighted median of external CEX prices) as primary, bracketed by Hyperliquid's own spot-book price as secondary — two independent data pipelines with zero third-party oracle dependencies. Every rebase checks the two agree within maxOracleDeviation (default 10%) or reverts.

The $1.00 target itself is immutable in USD mode (setTargetRate reverts) — it was pinned at deployment and cannot be moved by the owner. (This was hardened as audit finding F20.)

The deadband and rebase direction

The protocol does not rebase on every tiny wobble. It only acts when the price leaves a band around $1.00 set by deviationThreshold (default ±5%):

HAM price	Action
above $1.05	positive rebase — expand supply (and harvest, below)
$0.95 – $1.05	nothing — inside the deadband
below $0.95	negative rebase — contract supply

Expanding supply adds sell-side pressure to push the price down toward $1; contracting does the reverse. See Elastic supply for what this does to your balance.

Why rebases are gradual

A rebase never closes the whole gap at once. The off-peg percentage is divided by rebaseLag (default 10) before it is applied, and rebases happen at most about twice a day (minRebaseTimeIntervalSec, 12h, inside a twice-daily window at 08:00 and 20:00 UTC). So a 10%-off-peg condition nudges supply ~1% per rebase and converges over several days if the deviation persists — damping oscillation and removing any single keeper's ability to swing supply hard.

The DAT mechanism

Harvesting HYPE's upside into the treasury.

This is the distinctive part of USD mode. Because HAM is priced in WHYPE but pegged to USD, anything that makes WHYPE worth more in dollars makes HAM read above $1 — even if HAM's value in WHYPE didn't change. That triggers a positive rebase, and on a positive rebase the protocol mints a slice of the new supply (rebaseMintPerc, default 10%), sells most of it into the pool for WHYPE (maxSlippageFactor, default 90%), and forwards the proceeds to the treasury.

The net effect: as HYPE appreciates in USD over time, the protocol continually skims that appreciation into a HYPE-denominated treasury — a Digital-Asset-Treasury (DAT) flywheel — while holders keep a token that stays near $1. This is why you'd choose USD mode over a plain HYPE-tracking token: holders get a dollar unit, and the protocol accumulates the HYPE upside.

Keeper honesty: commit / reveal + oracle drift

Rebases are driven by allowlisted keepers through a two-step commit/reveal (25 blocks apart), where the commit binds the slippage floor so a keeper can't pick a favorable number after seeing the pool. In USD mode the commit also snapshots the reserve/USD price, and the reveal reverts ("oracle drift") if that price has moved more than maxCommitRevealOracleDrift (default 2%) in between — removing the keeper's ability to wait for a favorable oracle print to size the treasury harvest. Keeper operation is covered by the operator runbooks in the protocol repository.

The liveness trade-off (read this)

The dual oracle and timelocks buy safety at a real cost: both reserve/USD feeds are load-bearing — the secondary bracket read is mandatory in every USD-mode rebase — so a failure in either halts all rebases, including the owner's emergency forceRebase. With the launch adapters, staleness cannot trigger (they report updatedAt = block.timestamp); the fail-stop conditions are a precompile call failure or an answer outside the adapter's absolute band — including the price legitimately exiting the band, in which case reads pause until governance rotates in re-centered adapters. Rotation is itself timelocked 24h (ORACLE_ROTATION_DELAY) so observers can react to a hostile rotation. Monitor both adapters as launch-critical infrastructure. This is the main availability risk of USD mode and it is deliberate — the protocol prefers to stop rebasing over rebasing on a bad price.