Settlement and data
RIP.BET temperature settlement is based on observed NYC Central Park temperature data.
Scalar settlement
Scalar markets settle each 120-minute bucket using TWAP-120: the time-weighted average of the final 120 seconds.
The settlement mark is encoded:
mark = 500 + temperature_fIf the final TWAP is 73.2 F, the settlement mark is near 573.2.
What users see near settlement
Near the bucket boundary, clients should expect several states:
| State | Client behavior |
|---|---|
| Trading | Entries and closes can be attempted |
| Final window | Show the TWAP window clearly |
| Settling | Stop new entries and refresh bucket state |
| Next bucket | Switch to the newly active asset |
Hyperliquid may expose a halted partner asset with exchange-native status fields. RIP.BET clients should label the user-facing state as Settling or Waiting, not as a permanent removal.
Data availability
The API can reject reads or trades when market data is missing or stale. That is expected behavior. Do not fill gaps with client-side estimates.
Common cases:
- Order book cache is missing.
- Ticker or oracle data is stale.
- The bucket controller is between states.
- The market is paused during a data issue.
- Outcome metadata is temporarily unavailable from the upstream registry.
Outcome settlement
Outcome markets settle by their own expiry and resolution rules, not by the scalar 120-minute bucket. Use /v1/outcomes/meta fields such as expired and settling to drive the UI.
Do not infer outcome settlement from scalar market state.