WeatherXM is building a network of weather stations installed by individuals and partners. The devices measure temperature, humidity, rain, wind, pressure and radiation; owners receive WXM tokens when their data passes the network's checks. The product exists: a public map, four hardware families, accessible data, a professional API and reward contracts on Arbitrum.
The most flattering number is not the most useful one. On 9 September 2026, the Explorer API distinguished 23,762 “onboarded” devices, 9,834 stations claimed by an owner and 5,286 active stations. Marc Norat's original contribution is to read this path as an operating funnel: 41.4% of manufacturer-onboarded devices had been claimed, 53.8% of claimed stations were active, and active stations represented 22.2% of onboarded hardware. The network is real; nominal capacity does not describe daily production.
A physical network, not merely a token
A WeatherXM station signs measurements inside the device before transmitting them over Wi-Fi, Helium LoRaWAN or a mobile network. GPS also supports a signed location. The signature helps prove that a packet came from a particular device and was not altered in transit. By itself, it does not prove that the device is correctly installed or that the rain it measured represents conditions around it.
WeatherXM therefore adds three groups of offchain checks. Self-checks reject impossible values, flat series, jumps and missing periods. Comparative checks confront a station with neighbours, third-party networks or weather models. Deployment detectors look for indoor installations and obstacles in front of the solar sensor; the wind-obstacle detector is still listed as forthcoming in the documentation.
The daily result combines data quality, proof of location, hardware class and local density. In an oversupplied cell, only the highest-scoring stations, then the oldest in a tie, receive the base reward. WeatherXM's infrastructure still performs that calculation. A Merkle root posted to Arbitrum lets users verify an allocation and claim tokens, but the blockchain does not recalculate temperature or meteorological quality.
Installed hardware and active supply are diverging
The Explorer presents three populations that should not be added together. “Onboarded” covers 23,762 devices processed by manufacturers. “Claimed” covers 9,834 units associated with the network by an owner. “Active” covers 5,286 stations. Among those, 4,323 were classified as high quality, or 81.8% of active stations.
That separation changes the portrait. An independent DePin.Builders analysis dated 5 June 2026 counted 9,787 deployed stations and 6,079 active ones. By 9 September, the first comparable indicator had gained 47 units, or 0.5%, while the active count had lost 793, or 13.0%. The activity definition and measurement window may change, so this comparison does not establish a lasting outage. It does show why a larger fleet is not proof of a growing service.
The H2 model illustrates the gap. The API counted 7,004 onboarded devices, 563 claimed and 387 active. For the older M5: 5,056 onboarded, 4,142 claimed and 2,451 active. Product age, inventory, shipping, installation, radio coverage and maintenance necessarily separate those stages. Publishing the layers is a useful form of transparency; blending them into “network stations” would hide the main execution risk.
This finding complements our GEODNET portrait: in a DePIN, sensor count describes supply, not continuity, quality or demand for the data.
An algorithmic quality score is not a weather certification
WeatherXM reported an average quality score of 86 and 4,323 high-quality stations. These scores are operationally useful: they identify inconsistent packets, penalise poor siting and steer rewards. It would still be misleading to translate them into “86% accuracy” or general compliance with meteorological standards.
The World Meteorological Organization's WMO-No. 8 guide devotes separate chapters to temperature, wind, precipitation, radiation, automatic stations, calibration and intercomparison. That structure matters because one installation may be suitable for one variable and poor for another. A signed sensor beside a wall can authentically transmit a locally biased temperature; a low or sheltered anemometer can sign underestimated wind.
WeatherXM's own documentation recognises several such limits. The solar detector examines only the southern horizon and needs long time series; the wind check has not yet been deployed; validity for reward purposes can differ from meteorological validity. Comparisons with nearby stations also become less robust precisely in the remote areas the network wants to cover.
The sensible reading is layered. Cryptographic signing protects provenance. Algorithms estimate plausibility and deployment quality. A sensitive use — parametric insurance, power systems or civil protection — still needs calibration, site history, documentation and validation tailored to the decision being made.
Revenue exists, but public measurement is lagging
The economic model combines hardware sales, onboarding fees paid by manufacturers, commercial licences and API access. The WeatherXM association charges $100 per manufactured device and auctions up to four commercial licences in WXM each year. Two holders are named for 2026: WeatherXM AG and the Zeus Bittensor Subnet.
The association's financial page itemises $650,000 and 200,000 WXM of revenue in 2024, then $75,000 in 2025, with links to transactions. As of 9 September 2026, it showed neither a 2026 total nor the price of this year's two licences. Customers and payments are therefore observable, but a complete, audited and current revenue figure that can be compared with reward costs is not.
The API showed 13.13 million WXM allocated since launch and 217,580 over the preceding 30 days, around 7,253 a day. The schedule allows up to 14,246 WXM daily for ten years. Eligibility rules and leftovers may explain the gap; it is not a revenue measure. The relevant economic test is not the token price, but how much data income can sustainably pay for collection, validation and maintenance as emissions decline.
Voting is decentralised before execution is
WXM also carries voting rights. A proposal starts on GitHub, goes through the association's General Assembly and then reaches Snapshot. Voting weight follows token holdings and the stated quorum is 150,000 WXM. But only signalling proposals are currently available: an accepted vote executes no code. The General Assembly promises to implement it.
That arrangement is not fictional governance, but it preserves an institutional filter and human execution. The 30 million WXM allocated to initial supporters and 10 million reserved for the treasury also make the actual distribution of voting power material; the documents reviewed here do not provide a current concentration measure.
WeatherXM has crossed the line that many DePIN projects never do: deployed devices, browsable data, explicit controls and early traceable revenue. Its decisive indicator is no longer how much hardware has shipped. The next evidence should be monthly active retention by model and region, intercomparison results against references, 2026 revenue and the share of operating costs covered without fresh emissions. A dense map is a promise of observation; only a reliable and used time series becomes weather infrastructure.