Weather Fi
Sign in

This document is moving to paper.wellbianlabs.io/weatherfi.

Documentation

How it works · settlement rules

Everything on this site - every market price, every premium, every payout - is a function of one thing: a Weather Data Market determination on a condition like “Seoul temperature ≥ 30°C at 06:00 UTC”. This page explains the data, the pricing models and the rules that decide who gets paid.

What this simulator is

Weather Fi is a simulated exchange for weather-contingent products. You start with 10,000 sUSDT, a virtual unit with no monetary value, and can trade YES/NO shares on prediction markets, buy parametric insurance covers on any of 172 cities, or go long or short weather index futures and the simulated real-asset futures that follow them. Balances cannot be deposited, withdrawn or exchanged. Nothing here is an offer to bet, trade or insure; it exists to test how products built on an objective weather oracle behave. See the simulator terms.

Data & oracle

Units and indices. Every value is measured, stored and settled in °C, mm, m/s and %. Temperatures are shown in the unit each city's country reads in - °F in the United States and a few others, °C elsewhere - and the switch in the header overrides that for everything at once; a threshold typed in °F is converted before the oracle sees it. Alongside the four metrics the oracle publishes two indices, WDI (Weather Data Index, a composite) and TDI (Temperature Data Index), on fixed, versioned weights identical for every city and season, so they are unit-free and comparable everywhere; the operator picks which one leads. Their history and sources are on weathermarket.ai, one link from each city page.

The oracle is Weather Data Market (weathermarket.io). It covers 172 cities and, every hour, pulls 11 feeds per city - three fetched directly (KWeather, METAR, MET Norway) and eight through Open-Meteo - and reduces each metric (temperature, humidity, wind, precipitation) to one consensus value. The oracle names its estimator as a median with MAD outlier rejection; its parameters, tolerances and weights are proprietary, and this site does not describe or approximate them (oracle terms, section 7-b). What each run decided - the value, the sources it excluded, the verdict - is on the page. Since 14 October 2026 the oracle counts the same observation arriving through two sources once, and does not count KWeather's world observations that were filled from the GFS model or have stopped updating as measurements; the excluded source and the reason stay in the run's record.

Every city page and every market page carries the live consensus feed: the run the oracle published for the current hour, with each of the eleven readings next to the METAR baseline and the consensus, the outliers it excluded, the measured-only figure, the corroboration between the measured sources and the verdict per metric, plus the same readings for the last twelve runs. It refreshes once a minute, names the run and the fetch time, and links to the city's dashboard on weathermarket.ai and to the anchor of the run. The rule that turns the readings into one number is the oracle's; what it decided is on the page before a market settles on it.

Pick the temperature is the ladder product: one city, one target hour, whole degrees in the city's unit from about five below the forecast to five above, open-ended at both ends. A ticket buys shares in as many degrees as it likes and names the reading that judges it - the oracle's consensus for the hour, or the station's METAR baseline- the station's own report observed nearest the target hour (the routine METAR within 30 minutes either side, as corrected). Each reference is its own market maker (LMSR over the bins), so the two crowds are visible side by side: the page shows the live determination data the oracle is producing in one window and the index the tickets are producing in the other. The degree the chosen reading lands in pays 1 sUSDT a share; a reference that cannot be read for the hour (an hour that is not settlement-eligible, or a run without a METAR) refunds its pool at cost. Tickets close an hour before the target hour; settlement uses the oracle's stored run and its per-source record, nothing else. Because a consensus ticket settles only on an eligible hour, every ladder shows how often that happened in its city over the last seven days (the oracle's own figure), and a city below 40% offers the METAR baseline only - there a consensus ticket would mostly be refunded.

Every run is checked against the observation class - airport METAR and KWeather's station and GTS feed - and graded verified (more fresh observations agree than disagree, and at least two agree), single_source, mixed, mismatch or unverified; whether the hour is settlement-eligible, overall and per metric, is the oracle's call. Each run is serialised, SHA-256 hashed and anchored on Flare mainnet in the SnapshotAnchor contract, the anchor of record since 23 September 2026; earlier runs also carry a first-generation anchor on BNB Chain. The run id and the anchor transaction are shown next to every value and verdict on this site. The full design is in the whitepaper.

With its subscription the simulator keeps each run it reads per city (consensus, indices, verdict, eligibility) so index markets can settle on the value published for their hour and the charts can show recent runs; the subscription licenses that, the free tier would not. Forecast depth is 16 days, re-cut on the station's local day where a product needs it.

METAR, measured

Many weather markets settle on METAR - the report an airport station sends, roughly once an hour - and treat it as the truth. It is a real measurement, but not a clock: reports arrive late, stations go silent, and reports are corrected after they were published. That is rarely published by the data suppliers behind weather markets. Weather Data Market watches every station's METAR feed once a minute - observation time, NOAA receipt time, first sighting, corrections with the original kept - checks each hourly consensus run against the measurements (METAR together with KWeather's official stations and GTS bulletins, never one station alone), and anchors every run and every final station day on Flare.

This site keeps, for every run and city, whether the METAR was there, whether it was usable and how old it was, and publishes the record on METAR watch: the share of runs with no usable or current report, hour by hour, and airport by airport. The principle is the reason this platform exists: do not trust a brand - trust data you can check.

Every METAR report also carries the oracle's quality-control flag - physical limits, dewpoint above temperature, a step too large for the minutes between reports, a reading stuck for six hours - beside the anchored record, which is never altered. Station markets here settle on a suspect extreme (usable, shown), but not on a bad one: a physically impossible report is not the day's high, so the extreme without it, from the same anchored record, settles instead.

15-day forward

The 15-day forward lists, for the large cities whose station feed is reliable, a ladder of daily-high lines for each of the next fifteen local days - the lines the forecast puts near 75%, 50% and 25% - as soon as the oracle's sixteen-day forecast reaches the day. Each is an ordinary station-day market and settles on the station's final, settleable record anchored on Flare. The opening price is the forecast's probability: the forecast high corrected by the bias, with a spread that widens with the lead. Both come from Weather Market's Forecast Watch, which archives each model's forecast before the day and scores it against the station record markets settle on (only final, settleable days) - eight models, the Open-Meteo blend these prices use, and KWeather's own daily forecast. The scores so far show every model's forecast high running cold against the station record (the blend by about 0.6 to 0.8 °C), so prices add the measured bias back. Leads Forecast Watch has scored use its measured spread; longer leads start from the measured level at the nearest scored lead and grow the way forecast error grows with lead; with nothing scored the lead-time model stands in (1.4 °C plus 0.35 °C a day, widened 15% for a daily extreme). Every day on the forward board says which it used, and the board shows the scores themselves.

Forecast duels

A forecast duel turns Forecast Watch itself into a market: which of two models will forecast a station's daily high closer over a Monday-to-Sunday week, on the forecast made the day before? Each reliable station lists its two closest models over the scored window and, when that is a different pair, the network's top two. The opening price is the chance the first model ends the week with the lower mean error: the station's own gap between the two, shrunk toward the network-wide gap, against how much one day's difference scatters. The week's standings - every model at the station, days scored and mean error so far - sit on the market page as the days settle, and the duel settles on the report for exactly those days. Settlement rule ↓

How products and payouts are set

Nobody sets a line, a price or a payout by hand. Every product on the board is generated, priced and - for covers - given its payout ratio automatically, from one input: the forecast the oracle publishes for each city. That forecast merges KWeather's forecast - built from official stations, ICAO METAR and GTS bulletins together with several national numerical models, AI methods and terrain data - with Open-Meteo's. Where both cover a day the two are averaged and the row carries the number of contributing sources (2); further out Open-Meteo carries the day alone (1). The forecast refreshes every few hours and the catalogue runs every hour, so new products are always priced from the latest forecast.

  1. Expected value at the hour. From the day's forecast high and low the model draws the day's curve (peaking mid-afternoon local time) and reads the expected temperature at the target hour; humidity runs opposite to temperature; wind is the day's mean; rain is the day's total spread over the hours.
  2. Uncertainty that grows with lead time. One standard deviation widens by day: temperature 1.4 + 0.35·d °C, humidity 8 + 1.2·d %, wind 1.3 + 0.25·d m/s. A station's daily high or low is priced about 15% wider than a single hour.
  3. A probability for any line. P(value ≥ line) = 1 − Φ((line − expected) / σ); rain uses the chance the hour is wet times the chance it is wet enough. Every probability is kept between 3% and 97%.
  4. Choosing the lines. For each city and date the generator tries a ladder of candidate lines and keeps the one whose probability lands nearest the product's target: about 50% for the even-money temperature, humidity and rain markets, about 25% for the hot and cold tails, about 40% for wind. A line that cannot land inside its band (a bone-dry week has no interesting rain question) is not listed. US cities get whole-°F lines.
  5. The opening price. The market maker is seeded so the first YES price equals that probability. From then on trades move it; the forecast's own number stays beside the price as Model, and the gap is shown as Edge.
  6. Temperature ladders. The same expected value and σ spread one unit of probability over whole degrees: each degree opens at the chance the reading lands in it.
  7. Cover premiums and payout ratios. A cover pays its full amount when the condition is met, so its fair price is the probability times the coverage. The premium adds a 15% loading and a 0.5% fee, and the payout ratio is what the premium buys back:
premium      = p × coverage × (1 + 0.15) + coverage × 0.005    (at least 1 sUSDT)
payout ratio = coverage ÷ premium  ≈  1 ÷ (1.15·p + 0.005)

example: p = 20%, coverage 1,000 sUSDT
  premium  = 0.20 × 1,000 × 1.15 + 1,000 × 0.005 = 235 sUSDT
  payout   = 1,000 sUSDT if met  →  4.26× the premium

The rarer the event in the forecast, the smaller the premium and the higher the payout ratio; as the forecast moves, a new quote moves with it, while a policy already bought keeps the premium it was sold at. Index markets are the one exception to the forecast: they open from the index's own values at the same hour over the last seven days of runs, because an index has no forecast of its own.

None of this touches settlement. The forecast decides where a product opens and what a cover costs; what pays is the oracle's published value for the hour - the consensus of eleven feeds - and nothing else.

Prediction markets

The catalogue is generated per city from that city's own forecast, at four horizons - next day, 3 days, 7 days and 14 days ahead, each targeting 06:00 UTC. Thresholds are not round numbers picked in advance: the pricing model's expected value at the target hour becomes the threshold, so a temperature market opens near even money instead of at 3% where nobody would trade it. Each horizon carries a different mix - the next-day slot adds a hotter temperature variant and a wind market, the longer horizons keep temperature and precipitation.

A determination is a unit of work on the oracle, and a market only needs one when it settles. Markets are therefore created without one, and the settlement job opens the official determination a few hours before the target hour. A market you open by hand asks for its determination immediately, so you can see the official id straight away.

Settlement reliability. The oracle publishes, per city, the share of recent hours that were settlement-eligible. Every market and quote carries it as a badge - settles reliably at 70% and above, settlement risk between 50% and 70%, and a red badge below that. On the first day of official settlement, cities above the line had 29% of determinations withheld; cities below it, 56–59%. The next-day set is listed automatically only for cities above the line, because a market that voids after a day of trading is the worst outcome for everyone; the 3-, 7- and 14-day sets are listed for every city, and a next-day market on any city can still be opened by hand.

Daily products. Each city's next-day set covers every category the oracle reports: an even-money temperature market, a hotter and a colder tail, precipitation, wind and humidity - six questions on one hour, all settled by the same run. Filter the board by category or by horizon to see one day's products across cities.

Simulated participants. Twenty-four simulated accounts trade the board, and take temperature-ladder tickets, twice an hour, each buying the side the price underrates against its own reading of the latest forecast. They are ordinary accounts making ordinary trades through the same market maker, so prices drift toward the forecast as it updates and the tape has something on it between your trades. They are labelled as participants in the ledger and hold no advantage: they see the same forecast you do.

Each market is a binary question on one condition at one whole UTC hour, between 2 hours and 16 days ahead. Prices come from an LMSR (logarithmic market scoring rule) automated market maker with liquidity b = 1000 sUSDT. The YES price is e^(qYes/b) / (e^(qYes/b) + e^(qNo/b)), the cost of a trade is the difference in b · ln(e^(qYes/b) + e^(qNo/b)) before and after, and buying moves the price against you smoothly. There is no order book and no counterparty risk.

Opening price. The market is seeded so that its first price equals the event probability derived from the daily forecast:

  • Expected value at the hour. Temperature follows a diurnal cosine between the day's forecast min and max, peaking at ~15:00 local solar time (from the city's longitude). Humidity moves in anti-phase with an amplitude of 12 points. Wind uses the daily mean. Precipitation uses the mean hourly rate (daily total ÷ 24).
  • Lead-time-dependent sigma. Uncertainty (1σ) grows linearly with lead time in days: temperature 1.4 + 0.35·d °C, humidity 8 + 1.2·d %, wind 1.3 + 0.25·d m/s, capped at 16 days. P(value ≥ threshold) is 1 − Φ((threshold − μ) / σ).
  • Precipitation uses a two-part model: probability the hour is wet daily / (daily + 6) (bounded 2–85%), then an exponential intensity with mean max(0.3, daily/6) mm/h given wet.
  • Probabilities are clamped to 3–97%. With no forecast row for the date the prior is 50% (15% for rain).

Trading. Buy with an amount of sUSDT (min 1, max 100,000) or sell shares you hold. Trading closes 1 hour before the target hour; the market then waits for the determination.

Settlement. Met → each YES share pays 1 sUSDT, NO pays 0. Not met → NO pays 1, YES pays 0. Withheld → the market is void and every position is refunded at its cost basis.

Parametric insurance

A parametric cover pays the full coverage amount when the condition is met - no loss assessment. Five products are offered; you can change the threshold, the target hour and the coverage.

ProductConditionDefault
Heat coverPays the full cover if the consensus temperature at the target hour is at or above the threshold.temp ≥ 33°C
Cold snap coverPays if the consensus temperature at the target hour is at or below the threshold.temp ≤ -5°C
Rain coverPays if precipitation at the target hour is at or above the threshold.rain ≥ 2mm
Wind coverPays if wind speed at the target hour is at or above the threshold.wind ≥ 10m/s
Humidity coverPays if humidity at the target hour is at or above the threshold.humi ≥ 85%

Premium. With p the event probability from the same model that seeds markets:

premium = p × coverage × (1 + 0.15)   ← pure premium + 15% loading
        + coverage × 0.005               ← 0.5% fee on the covered amount
premium = max(1, round(premium, 0.01))

Limits. Coverage 10–10,000 sUSDT per policy; target hour between 2 hours and 16 days ahead; the premium is debited immediately and must fit your balance.

Settlement. Met → paid, the full coverage is credited. Not met → expired, the premium is kept. Withheld → void, the premium is refunded in full.

Weather index futures

A weather index future is a position on how much heating, cooling or growing weather one station records over a week or a calendar month. It is the third product class on the exchange, beside prediction markets and parametric insurance, and it settles on the same record. The futures board lists every open contract.

IndexOne day addsExposure it tracks
HDD · Heating degree daysmax(0, 18 - (high + low) / 2)Heating demand · Natural gas, Heating oil, District heat
CDD · Cooling degree daysmax(0, (high + low) / 2 - 18)Cooling demand · Electricity, LNG for power
GDD · Growing degree days(high + low) / 2 - 10 with both held to 10..30 °CGrowing-season heat · Grains, Oilseeds, Soft commodities

The contract. High and low are the station's recorded extremes for each local day, in °C, and the index is the sum of the daily figures over the period, in °C-days. Each contract is listed with a band of index points, lo to hi, set about three standard deviations either side of the model's estimate on the day it is listed.

one LONG share pays   (S - lo) / (hi - lo)  sUSDT, held to 0..1     S = the final index
one SHORT share pays  1 minus that
index the price implies = lo + LONG price x (hi - lo)

A long and a short share together always pay exactly 1 sUSDT, so the same market maker that quotes the yes/no markets quotes futures: LONG is its YES, SHORT its NO. You pay the price in full when you buy, and that is the most the position can lose: there is no margin, no margin call and no liquidation. The cost of that simplicity is the band - an index that finishes outside it pays as if it had finished on the edge.

Listing. Stations with a reliable feed carry the next two Monday-to-Sunday weeks, the current month while six or more of its days remain, and the next month. A week is listed once the forecast reaches all but three of its days, a month once it reaches all but sixteen. An index expected to stay below one point a day is not listed: a week of cooling degree days in a cold city would sit on the floor of any band.

Model fair value. Beside the market price the board shows the model's own figure: the days already final on the station record counted as they stand, plus the forecast for the days ahead with the error measured at each lead. Days that lie beyond the forecast are carried at the level of its last days, with a wider spread. The market price is the crowd's; the edge column is the difference between the two, in index points.

Limits. A buy spends between 1 and 100,000 sUSDT; a sale is up to the shares you hold, at the maker's current price. Trading closes when the last local day of the period begins.

Settlement. Once the oracle marks every day of the period final and settleable, the daily figures are summed and the contract is settled: each share is paid by the formula above. If any day of the period cannot settle, the sum is not the index and the contract is void: every position is refunded at its cost. Days still waiting to go final are given 30 hours after the period ends, and a record that cannot be read at all is retried for three days before the contract is voided, so a position is never left locked.

US stations. A contract at a US station is built from the high and low in the NWS daily climate report of each day and settles one day after the last of those reports is issued; it is void if any day has no final report three days after the period ends. The full rule is under US stations settle on the NWS climate report.

What it is not. A weather index contract settles on the weather index, in virtual sUSDT. It never settles on the price of gas, power or a crop: the assets named beside a contract are the exposure a holder would be hedging. The price side of that exposure is shown by a separate, simulated product, described next.

Real-asset futures (simulated prices)

A real-asset future settles on the price of a commodity. This demo has no commodity price feed, so it generates the price itself, and says so wherever the price is shown. Each contract is a price index for one commodity at one station, 100 on the day it is listed, and it follows one weather index contract. The point is to show the two products trading as a pair: the commodity, the weather behind it, and the hedge between them. The real-asset tab of the futures board lists every open contract.

price = 100 x (1 + beta x (W - base) / scale) x market factor

W              the linked weather contract's index: model fair value while it trades, the final index at settlement
base, scale    W on the day the asset contract was listed, and the size of a 100% move in it
beta           how much of a weather move reaches the price, and in which direction
market factor  a simulated random walk, 1.00 at listing, stepped at every hourly pass, frozen when trading closes

The weather part is real: it is the index of a contract priced from the forecast and settled on the station record. The market factor stands in for everything else that moves a commodity, and is invented by the simulator. The weather part is held to 60% either side of the listing level.

ContractFollowsPer 1% of indexAssumed link
NGAS · Natural gasHDD+0.90%A colder period burns more gas for heating, so the simulated price rises with heating degree days.
HOIL · Heating oilHDD+0.55%Heating oil demand follows the cold, more loosely than gas: the simulated price rises with heating degree days.
PWR · ElectricityCDD+1.10%Heat drives air-conditioning load, and power cannot be stored: the simulated price rises steeply with cooling degree days.
LNG · LNG for powerCDD+0.60%A hotter period burns more gas in power stations, so the simulated price rises with cooling degree days.
CORN · CornGDD-0.60%More growing heat moves the crop along and lifts the expected harvest, so the simulated price falls as growing degree days rise.
SOYB · SoybeansGDD-0.50%More growing heat lifts the expected harvest, so the simulated price falls as growing degree days rise.
SUGR · Sugar caneGDD-0.50%Cane grows faster in warm weather: the simulated price falls as growing degree days rise.
COFF · CoffeeGDD+0.70%Coffee trees suffer in heat: a hotter period cuts the expected crop, so the simulated price rises with growing degree days.
WHT · WheatGDD+0.60%Heat while the grain fills cuts wheat yields, so the simulated price rises with growing degree days.
MAIZ · MaizeGDD-0.60%More growing heat lifts the expected harvest, so the simulated price falls as growing degree days rise.

The sensitivities in this table are assumptions of the simulation, chosen to show the direction of each link. They are not estimates from market data, and no price here is a quote from any market.

The contract. It is the same band contract as a weather index future, quoted by the same market maker: a LONG share pays (price - lo) / (hi - lo) sUSDT at settlement, held to 0..1, and a SHORT share the rest of 1 sUSDT. The band is set about three standard deviations either side of 100 on the day of listing. A contract is listed beside a weather index contract of its index at the commodity's stations, stops trading when that weather contract does, and is paid in full when bought: no margin, no liquidation.

Linked trading. Because the weather part of the price is the linked index, the two markets price the same weather twice. Each asset page shows the weather-implied price - the formula at the index the weather market is trading at - beside the asset's own market price. When the two drift apart, simulated spread traders buy the cheap side of the asset contract and take the offsetting position in the weather contract; both legs are marked pair on the tape of each contract.

weather shares per asset share = 100 x |beta| x market factor x (weather band) / (scale x asset band)
side: the opposite exposure to the index - SHORT the index against a LONG asset with a positive beta

Held in that ratio, the pair no longer depends on the weather while both contracts are inside their bands. What is left is the market factor, which a weather contract does not hedge. Each asset page has a scenario tool that draws both lines.

Settlement. An asset contract settles right after its weather contract settles: the final price is the formula at the final index, with the market factor as it stood when trading closed, and the settlement report lists every input so the figure can be recomputed. If the weather contract is void, the asset contract is void too and every position is refunded at its cost.

Determinations policy

The simulator inherits the determination policy of Weather Data Market without modification:

  • Determinations are final. Once an outcome is issued it is not revised, even if a feed later corrects its data.
  • Same condition + same hour → same outcome. Every market and policy on the same condition shares one determination.
  • The report explains, it does not rule. The consensus value, verdict and anchor are evidence of how the outcome was reached; the outcome itself is the rule.
  • Withheld is nobody's loss. When the hour is not verifiable, markets are void and premiums are refunded.
  • The risk is shown, not hidden. Each city's recent settlement-eligibility rate is on every market and quote, so a void is never a surprise.
  • Station-day markets settle on the oracle's final, settleable record. A condition on the daily high or low of one ICAO station's local calendar day (daylight saving applied) settles on the oracle's station record: the extreme over the METAR reports in that window, with the report that produced it and its raw text. The oracle decides whether the day can settle: it goes final three hours after local midnight (corrected reports can still land) and is settleable only if no gap between reports exceeded the station's normal interval plus 30 minutes. A final, settleable day settles on the record anchored on Flare (its SHA-256 and transaction are kept with the outcome); a day that is not settleable, or not finalised within 30 hours, is withheld and refunded. Station days are listed at the stations whose feed the oracle's one-minute METAR watch shows to be reliable.
  • Week and month markets settle only when every day is. The highest daily high, or the lowest daily low, at one station over a Monday-to-Sunday week or a calendar month, from the oracle's per-day record of the period. A period settles only when the oracle has every one of its days final and settleable - a single day with a gap could have been the extreme - and records the Flare anchor of the day that set it; otherwise it is withheld and refunded. Prices come from the station-local forecast for the days ahead and the record of the days already over; trading closes when the last day begins.
  • US stations settle on the NWS climate report, one day after it is issued. Every product that reads a US station's daily high or low - station days, the fifteen-day forward, week and month markets, and degree-day futures - settles on the NWS Climatological Report (CLI) for the date: the daily summary the local forecast office issues from the station's one-minute record, normally one to three hours after local midnight, in whole degrees Fahrenheit. The oracle carries the latest final issue for each date with its issue time, and Weather Fi settles on it only once that issue is 24 hours old. An office that corrects a report re-issues it under the same date; the latest issue is the one used and the 24 hours run again from it, so a correction made on the day reaches the settlement. A line on a whole degree Fahrenheit is compared in Fahrenheit, as printed. A week, a month or a futures period needs the final report of every one of its days and settles a day after the last of them. If a date still has no final report 72 hours after it ended, the market is withheld and refunded - or the contract void - rather than settled on another source. The live readings on a US market's page are the station's METAR feed: they show the day as it unfolds, can differ from the official value by about a degree, and do not settle it. The NWS climate day runs midnight to midnight local standard time, so during daylight saving it starts and ends an hour later than the clock day. This applies to every US station product that had not yet settled when the rule took effect in November 2026; stations outside the United States settle on the oracle's METAR-derived record as described above. How the reports behave - issue times, late and missing reports, corrections - is published in the oracle's NWS CLI Watch.
  • Forecast duels settle on Forecast Watch's report for exactly the week. A duel asks which of two weather models forecast a station's daily high closer over a Monday-to-Sunday week, on the forecast made the day before. Weather Market's Forecast Watch archives every model's forecast before the day and scores it against the station's final, settleable record; the duel is decided on the mean absolute error over the week's scored days, read from the public report with the week as its fixed window (/api/v1/forecast-watch/report?icao&from&to) - the same numbers anyone can read. Only models the oracle archives together duel, so both are scored on the same days. Withheld, every position refunded, if fewer than five days were scored, if the two were not scored on the same days, if they tie to the hundredth of a degree, or if the report is not available within 30 hours of the week ending.
  • Index markets settle on the published run. The determinations API takes temperature, humidity, wind and rain only, so an operator's market on WDI or TDI settles on the value the oracle published for the target hour's collection run - hashed and anchored like every run. An eligible hour settles met or not met on that value; a hour graded not settlement-eligible, or with no run, is withheld and refunded. It is labelled as an index settlement, not an official determination.
  • Credentialed mode registers an official determination via POST /api/v1/determinations on weathermarket.io and reads its resolution back.
  • Free tier produces a simulated determination: the public consensus at the target hour is read and evaluated locally. It is clearly labelled “simulated · public consensus” wherever it appears and is not an official determination.

Access modes

ModeForecast depthDeterminationsVerdict visibleRate
free3 dayssimulated from public consensusno (labelled “free tier”)120 req/hour; 10-city sample without a city
metered16 daysofficial (x-api-key)yes0.04 USD a call, paid in XRP
subscription (in use)16 daysofficial (Bearer token), includedyes25 USD / 30 days or 200 / year per city, in XRP; about 60 calls a minute

The current mode is shown on the home page and on /api/sim/oracle. On the free tier, probabilities beyond day 3 use the last cached forecast day with lead-time sigma growth (no climatology), so premiums for distant hours are conservative.

Simulator API reference

All routes return JSON. Reading is open: the city, market and oracle routes answer anyone. Anything that touches an account - your portfolio, a trade, buying cover, opening a market - needs a signed-in session and answers 401 without one. Money fields are sUSDT numbers; times are ISO-8601 UTC.

MethodRoutePurpose
GET/api/sim/meYour simulated account: id, balance, displayName. Returns { signedIn: false } when nobody is signed in.
POST/api/sim/me{ action: "reset" } - wipe positions, policies and ledger; balance back to 10,000 sUSDT.
GET/api/sim/oracleOracle status: weathermarket.ai health, latest anchored snapshot, credential mode, free-tier budget.
GET/api/sim/citiesCity list with latest consensus and open-market counts. ?continent=&q=&sort=name|temp|grade
GET/api/sim/cities/[slug]City dashboard: latest consensus (refreshed when stale), anchor, forecast rows, markets.
GET/api/sim/marketsList markets. ?status=open|closed|resolved|all &category= &city= &continent= &q= &sort=featured|closing|volume|newest &page= &pageSize=
POST/api/sim/markets{ citySlug, metric, op, threshold, targetHour } - open a market on a condition (201 { market }).
GET/api/sim/markets/[id]Market detail: market, recent trades, your positions, anchor for the resolving run.
GET/api/sim/markets/[id]/quote?side=YES|NO&action=BUY&spend=100 or &action=SELL&shares=12.3 - LMSR quote without trading.
POST/api/sim/markets/[id]/trade{ side, action: "BUY"|"SELL", spend?, shares? } - execute against the market maker.
POST/api/sim/insurance/quote{ citySlug, productKey, threshold?, targetHour, coverage } → { quote } with premium, pEvent, payoutRatio, condition.
POST/api/sim/insurance/buySame body → 201 { policy, balance }. Charges the premium and attaches a determination.
GET/api/sim/policiesYour policies, newest first → { policies }.
GET/api/sim/policies/[id]One of your policies → { policy, ledger, anchor } (404 if not yours).
GET/api/sim/futuresThe futures board: every open weather index contract with its band, market-implied index and model fair value, every open simulated real-asset contract with the weather contract it follows, and the last settlements.
GET/api/sim/futures/[id]One contract by id or symbol, of either product: specification, day-by-day build or price path, linked contracts, recent trades, open interest and your positions.
POST/api/sim/futures/[id]/trade{ side: "LONG"|"SHORT", action: "BUY"|"SELL", spend?, shares? } - execute against the market maker.
GET/api/sim/portfolioAccount, summary tiles, positions valued at the current LMSR price, futures, policies, last 100 ledger entries.

Operational routes (/api/cron/ingest, /api/cron/markets, /api/cron/futures, /api/cron/settle, /api/admin/sim) require a cron secret or the admin password.

Attribution & licence

Oracle data is provided by Weather Data Market under its terms (section 7). Wherever a consensus value, verdict, run id or anchor is displayed the site shows “Powered by Weather Data Market”. The data is served to this site's own pages through its own backend; it is not offered to anyone as a feed, API, dataset or bulk download, and the routes above exist for these pages, not as a data service. Free-tier data is not settlement-grade and is never accumulated.

Data provider: KWeather Co., Ltd. Operator of the oracle platform and of this simulator: Wellbian Labs Pte. Ltd., under delegation from KWeather. Technical questions: admin@wellbianlabs.io.