The peg

DAT is launched in USD peg mode: the protocol's job is to keep DAT'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

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

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

• TWAP(WHYPE per DAT) — 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%):

DAT price	Action
$1.05 or higher	positive rebase — expand supply (and harvest, below)
above $0.95, below $1.05	nothing — inside the deadband
$0.95 or lower	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. With default timing, execution is allowed at most once per 12-hour interval, during one-hour windows beginning at 08:00 and 20:00 UTC.

A 10% deviation therefore produces a 1% damped delta. On a negative rebase, the whole delta changes the scaling factor. On a positive rebase, rebaseMintPerc diverts 10% of that delta by default to the treasury mint path, leaving about 0.9% for the scaling-factor increase.

The DAT mechanism

Harvesting HYPE's upside into the treasury.

This is the distinctive part of USD mode. Because DAT is priced in WHYPE but pegged to USD, anything that makes WHYPE worth more in dollars makes DAT read above $1 — even if DAT's value in WHYPE did not change. Outside the deadband this triggers a positive rebase. The protocol diverts rebaseMintPerc of the damped delta (10% by default) to a treasury mint budget. maxSlippageFactor controls how much of that budget is used in the DAT→WHYPE swap (90% by default); the balance is retained as DAT.

The intended effect is to accumulate WHYPE and DAT in the rebase treasury while the supply mechanism targets a dollar-denominated unit. The mechanism does not guarantee that DAT trades at $1 or that treasury assets accrue directly to token holders.

Keeper controls: commit/reveal + oracle drift

Rebases are driven by allowlisted keepers through a two-step commit/reveal (25 blocks apart), where the commit binds the keeper, salt, and minReserveOut. In USD mode the commit also snapshots the primary reserve/USD price, and reveal reverts ("oracle drift") if that price has moved more than maxCommitRevealOracleDrift (default 2%).

This prevents changing the floor after commit and limits timing discretion, but it does not validate that the committed floor is economically safe. A compromised keeper can commit a weak floor. It cannot redirect the swap output, which always goes to treasuryAddress.

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.