Why the numbers don't always matchLink to this section

TL;DRLink to this section

Recent wheel activity can appear before the same work is settled and confirmed on Ethereum.
A missing reading doesn't mean no work happened; old readings must stay marked stale.
Some totals already include others, so adding them can count the same work twice.
Settled work and funded rewards are separate records.

Which stage are you looking at?Link to this section

The device can record a passage while its round is still open. Later, the completed round can be checked, submitted to Ethereum, and confirmed. A live activity display and a confirmed chain total can therefore show different numbers without either being wrong.

The confirmed record belongs to Core; rewards belong to the separate Mining accounting. Neither wheel speed nor settled work alone tells you how much SQK is ready to claim. There's no promised delay between these stages.

For example, suppose 100 work units are confirmed, another 8 are in closed rounds waiting to settle, and 2 are in the current open round. An optimistic total of 110 already includes the confirmed 100. Adding 100 and 110 would count that confirmed work twice.

Why isn't missing data zero?Link to this section

A saved zero-work round says no passages were accepted during that round. A missing record says you don't have that evidence. If a half-hour history has records for only two of its three rounds, it can show the observed work, but it must also show that coverage is incomplete.

Old data can remain visible with a stale label. When chain or reward data is unavailable, the browser doesn't calculate a replacement from live activity. Sections with available data remain visible even if another source fails.

Technical detail: reading each sourceLink to this section

These values describe related but distinct records. Queue, estimated, and settled totals can contain the same work; don't add them together.

Value	Origin and meaning	Important limit
Accepted cumulative work	Saved device work verified by the Oracle	Includes unsettled work; compare only matching installations and counter epochs
RPM and speed	Motion estimates from saved passages	Do not prove identity, direction, or what caused the movement
Display distance	Accepted work multiplied by the fixed 878 mm wheel circumference	An estimate, not proof of animal travel
Optimistic builder	Confirmed work plus later recorded work, including the open round	Estimates the result if pending work settles
Settlement queue	Completed rounds and their submission status	Ready or submitted does not mean settled
Onchain work state	`Core` records from the intended deployment with enough confirmations	Excludes newer transactions still waiting for confirmations
Historical activity	Accepted round totals grouped by UTC time	Shows how many expected round records are present
Claimable rewards	Funded rewards recorded separately by `Mining`	Cannot be calculated from RPM or `Core` work alone

Data sourcesLink to this section

The Pi saves passages and round totals as measurement history.
The Oracle verifies saved device work for public measurement views.
The process API separates measurements, optimistic progress, Oracle checks, and settlement status.
The onchain API displays Core records after deployment checks and 12 confirmations.
The history API groups accepted round totals into UTC buckets with coverage labels.

Current process and chain factsLink to this section

GET /v4/public/process separates measurements, estimated progress, Oracle checks, and the settlement queue. Measurements show online or stale, with a 120-second stale threshold.

The builder labels its estimate optimistic. It shows unavailable when counter faults, unapproved counter epochs, missing rounds, or unavailable Oracle records prevent a reliable estimate.

GET /v4/public/onchain shows Core data after 12 confirmations and deployment identity checks. It does not substitute pending Oracle work when chain data is unavailable.

Units and timeLink to this section

Motion fields use thousandths of RPM, millimetres per second, and millimetres. Large work totals are decimal strings; apps must preserve their integer precision.

Displayed daily distance resets at midnight UTC; it is not a lifetime total. Historical daily distance uses the largest accepted odometer reading for each UTC day, rather than adding repeated readings.

Historical coverageLink to this section

GET /v2/public/stats?range=7d|30d shows history only. Each UTC day has 48 half-hour buckets; a completed bucket should contain three ten-minute round records.

Bucket coverage	Evidence	Work presentation
`complete`	All three round records	Total accepted work, including zero
`partial`	One or two round records	Work from the available records, with coverage marked incomplete
`missing`	No round records for elapsed time	`null`, not zero
`future`	No round has finished in the bucket yet	`null`, not zero

Typical-day averages use complete buckets only. Exact block-completion durations stay unavailable without recorded start and end boundaries; submission times are not a substitute.

Rules and boundariesLink to this section

Live and optimistic values include work that has not settled.
A transaction hash does not prove success or enough confirmations.
A Core pause or settlement delay does not itself stop counting.
The browser does not calculate substitutes for unavailable chain or reward data.
Retained older data stays marked stale; it is not a fresh reading.
Available sections remain visible when another source fails.
Queue, projected, and settled totals can include the same work. Adding them double-counts it.

ExampleLink to this section

Illustrative projection with confirmed work and separate later work:

Part of the projection	Work units
Confirmed work	100
Closed, unsettled work in the queue	8
Open-round work	2
Optimistic total	110

The confirmed Core view still shows 100, and the queue contains only the closed 8 units. The estimate of 110 already includes the confirmed 100, so adding those totals would count that work twice.

The estimate does not prove that the pending work has settled or that any SQK is funded.

For example, a half-hour bucket with 2 and 3 work units in two rounds but no third record shows 5 observed units and partial coverage. The missing record does not prove that the third round had no activity.

Records verified work and tracks settled rounds and Squeek blocks on Ethereum. Calculates rewards from settled work, holds funded SQK, and pays eligible NFT owners. The Miner ERC-721 contract. Tracks NFT ownership and coordinates minting and merges with Mining. Applies Core or Mining upgrades authorized by its governing Timelock. Generates Miner NFT artwork from fixed onchain visual data. Queues governance operations and enforces a delay before they can be executed. The SQK ERC-20 contract. Enforces the lifetime supply cap; only Mining can mint SQK. Checks that visual data conforms to the required DotGrid format. When new mining power starts earning. Minting and merging schedule it for a later round, and a checkpoint must process the change. A reward update that processes settled work and scheduled mining-power changes. It can make rewards available but doesn't pay them to an owner's wallet. The Miner NFT permanently burned in a merge. Its unclaimed rewards move to the survivor, but its image is not combined or kept. SQK issued under the mining reward rules. You can direct a share of your Miner's rewards to fund SqueekFi projects. The physical mining device that records accepted wheel-magnet passages as work. It is separate from the virtual Miner NFTs. Squeekchain's record of accepted wheel-magnet passages. It doesn't prove animal identity and isn't how Ethereum reaches consensus. Combining two eligible same-level Miners you own into one higher-level Miner. One NFT is permanently burned; the survivor keeps both Miners' unclaimed rewards. The completed Squeek blocks a Miner must wait through before merging. It measures completed work, not elapsed time or Ethereum blocks; transfers don't reset it. The power used to calculate a Miner's share of rewards when eligible and active. A larger share of total power can mean a larger share of rewards. A ten-minute period used to group measured work. The device saves a completed round's work total when measurement remained uninterrupted. The transferable token used for mining rewards. It has a lifetime supply cap and is separate from the Miner NFT and the device's work count. A completed amount of settled work. Enough recorded work completes one Squeek block; it is not an Ethereum block. Squeek Miner NFTs earn SQK linked to recorded wheel activity. Owners can direct a share of those rewards to fund SqueekFi projects. Squeekchain's ecosystem for hamster-powered onchain finance. Miner owners can choose to fund projects with a share of their SQK rewards. The Miner NFT you keep in a merge. It gains a level, keeps its ID and image, and receives both Miners' unclaimed rewards. A Miner's recorded reward balance that hasn't been paid to a wallet. It stays with the NFT when ownership changes. One wheel-magnet passage that met the device's counting rules and was saved. It records work, not an amount of SQK.