Parameters

Every number in Regent is defined once, in a single file of this site's repository: lib/regent/params.ts. The simulator behind the preview imports it. These docs import it. The landing page imports it. No page types a protocol number by hand, so the copy and the simulated behaviour cannot drift apart. If a value changes in that file, it changes here on the next build.

The file holds two objects, and the difference between them matters.

• SPEC is the design as specified: session times, auction rules, the protocol cut, fee bounds, the bell window, the duty band and the slash split.
• PREVIEW_ASSUMPTIONS holds values the design leaves open but a working simulator cannot run without. They are placeholders, not decisions.

The tables#

The first table is the full specification. The second lists the preview assumptions. Both are generated from the code at build time.

Protocol parameters

Preview assumptions, not final

1 bp = 0.01%. Basis-point denominators use BPS = 10,000.

How to read the values#

Percentages are stored in basis points in the code, where one basis point is one hundredth of a percent, and shown here as percentages. Fees always show two decimals. Durations are stored in seconds. Session times are wall-clock times in New York (ET), not UTC; the conversion, including daylight saving time, is the job of the planned SessionClock contract described in Sessions and the calendar.

Docs pages reference values by name rather than by number:

import { D, SPEC, PREVIEW_ASSUMPTIONS } from "@/lib/regent/params";
// D.minRaise, D.bellWindow, D.protocolCut, SPEC.sessions.OPEN.start, ...

The same objects feed the TypeScript reference logic for the auction, the rent stream, the duty monitor and the session clock, which is covered by unit tests. A number cannot be right in the docs and wrong in the simulator, or the other way round.

What stakers can change#

The design makes four groups of parameters governable by $RGNT stakers. The token is not live and governance does not exist yet; this is the planned scope.

The spec names no other governable parameter. The auction rules (+5% minimum raise, 60 s anti-snipe window, 2 min hard close, reserve at 50% of the median of the last 10 winning bids), the 30 min anti-JIT rule, the 10% protocol cut and its split, the 0.30% band floor, the 60 s grace period and the slash split are fixed by the design as currently written. The design can still change before any deployment. If it does, it changes in SPEC.md and in the params file first, and these pages follow.

Governance power is a risk as well as a feature. A captured vote could set fee caps or the bell window badly. See Edge cases and attack surface and Risks and disclaimers.

What a preview assumption is#

The design document is precise about the mechanism and silent on a few values. It says the fee cap is raised during a halt, but not to what. It says an unsold seat falls back to a default fee, but not which one. It says the bond is sized by pool tier and slashed per breach-second, but gives no tiers and no rate. A simulator has to pick something, so it does, and every such pick is labeled.

The preview also hands every visitor paper balances so they can bid in the simulator. Those balances are not tokens and not money.

Resolving these assumptions is an explicit exit criterion of the testnet phase on the Roadmap. Until then, treat any figure that depends on them, such as a simulated slash amount, as an illustration of the mechanism and not as a forecast.