> For the complete documentation index, see [llms.txt](https://docs.brila.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.brila.finance/brila-dat/explanation/the-peg.md).

# 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](/brila-dat/reference/parameters.md).

## 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](/brila-dat/explanation/elastic-supply.md) 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.