Know what the numbers mean.

Source health

Checking the last collection results…

Network totals and offer observations

Overview defaults to the same CPU / VM aggregate feed used by the official Golem Stats dashboard. It covers all networks. Headline totals use the latest 5-minute aggregate; the 24-hour chart uses 5-minute averages and the 7-day chart uses hourly averages updated hourly. The 30-day view uses the older daily archive. An hourly chart may end earlier than the headline observation. Collection time and observation time are shown separately.

The YAGS observations view counts unique online nodes, including nodes without current offers, in the selected network. Its CPU total sums known offered VM threads. Golem Stats counts runtime offers and reports the separate CPU cores field, so these totals should not be treated as the same measurement. Upstream memory and storage aggregates divide GiB by 1024; YAGS labels these TiB, while the official dashboard labels them TB.

Providers and the current network aggregate are collected every 60 seconds. The visible dashboard checks collected data every 60 seconds and refreshes when returning to the tab. Upstream aggregation and caching can delay the next observation. Refresh does not manufacture a newer upstream sample.

Providers, offers and available capacity

Online means the source observes a network node. A node may have no current compute offer. One provider can advertise multiple runtimes, which do not represent additional machines. Our resource totals use one VM offer per provider in the selected network.

Locally collected resource history sums known VM values and excludes offers explicitly marked stale by upstream. Missing resource values contribute nothing to that sum. A zero known-resource sum does not establish zero physical capacity or prove that no resources exist; source coverage may be incomplete.

Offered CPU threads are the logical CPU resources declared in an offer. Host physical cores are a different field. RAM and storage use GiB, with 1 GiB equal to 1,073,741,824 bytes.

No activity reported means the source has not marked an open activity or agreement. Missing telemetry can also produce this state. It does not guarantee an idle host, free RAM, a successful negotiation, or a successful deployment.

Offer age and collection time

YAGS fetch time records when we retrieved a response. Offer last observed comes from last_seen_at; it may be much earlier. The upstream freshness flag is displayed independently. A recent fetch does not make an old offer new.

Failed collections retain the last valid snapshot and expose source errors. Individual unknown resource values remain unknown, and gaps in observation history are not filled with zeros. YAGS provider history begins with this installation; imported network history is attributed separately.

Comparable workload prices

We use the offer's linear pricing coefficients and match them by usage name. The estimate is start fee + hours × environment rate + hours × threads × utilization × CPU rate. The default scenario is one hour, four CPU threads and 100% CPU use.

Insufficient CPU capacity, unknown rates and unsupported usage models produce no estimate. GLM is the comparison unit; these estimates are not final invoices. We do not reuse upstream's amortized monthly hourly price as a one-hour task quote.

Market and requestor observations

Upstream requestor counters estimate approved agreements from telemetry. They are not exact completed tasks. When upstream omits requester IDs, YAGS shows anonymous observations and makes no identity claims.

Transfer statistics cover the upstream Polygon index. Its “on Golem” classification is based on recognized sender addresses; it does not prove that every transfer purchased computation. A transfer record is not necessarily a unique blockchain transaction. Current-day totals are incomplete.

Reported all-time network earnings include upstream historical adjustments. Earnings for a shared wallet are not attributed in full to each associated provider.

Operator earnings

Operator Total Earnings is reported for the whole payment address. The same value appears on each associated provider profile and on the address group; it must not be counted once for each machine. The Polygonscan link opens that address's token transfers.

The total uses Golem Stats' indexed transaction dataset. The 24-hour, 7-day, 30-day and 90-day windows use separately classified Polygon transfers. They are rolling periods, not calendar periods, and are not additive. A period can exceed the reported total; YAGS preserves those source values rather than trying to reconcile them.

Earnings are retrieved on demand with a five-minute refresh target and a shared, bounded cache. Failed or malformed responses retain the last good values and expose an error. Missing amounts remain unknown. The upstream service can itself return zero after an internal transfer lookup failure, so a reported zero is not independent proof of no earnings. The source supplies no observation timestamp; the card shows YAGS fetch time.

Rankings and reputation

Rankings compare explicit reported metrics within one source and scope. We do not invent a universal trust score. Upstream uptime uses its own observation period and should be read alongside provider age. Missing benchmark or reputation data remains unavailable.

Reputation service access is optional and currently not a dependency of YAGS. Its endpoints use different scales and aggregation methods; they must not be combined as interchangeable measurements.

Sources and project

• Golem Stats — public provider feed
• Golem Stats backend source
• Golem provider negotiation documentation
• Golem Reputation methodology

Saved views, starred providers and theme preferences are stored only in this browser. There are no user accounts, wallet connections or advertising trackers.