A camera or delivery outage doesn't by itself stop the device saving accepted work.
Uncertain sensor readings, time, or storage stop counting rather than producing guessed work.
A restored display doesn't mean all pending work has settled.
Pausing settlement stops new reward funding through checkpoints, but already funded rewards can still be claimed if their other checks work.
Not necessarily. The device saves accepted work locally, so a network outage can delay delivery while counting continues. A camera failure can stop the video without stopping the sensor or measurement service. An API or website failure can hide records without changing them.
Sensor, clock, and storage faults are different. If the Pi can't reliably accept and save a passage, it stops counting rather than inventing a result. There is no guaranteed uptime or catch-up deadline, and a missing response never means zero work.
If the Pi itself stops, its rounds keep elapsing. When it restarts, it closes those rounds as zero-work rounds, because it accepted no passages in them. Settled history then shows zero work for the outage, which is indistinguishable from an idle wheel.
A SqueekCore pause stops settlement and checkpoints from funding new rewards. It doesn't stop the physical device from counting otherwise valid passages, and it isn't a pause of every owner action.
Owners can still claim already funded rewards if NFT ownership checks and SQK payments work. The pause alone doesn't block NFT transfers, mint registration, or merges; minting and merging still depend on successful contract checks.
A recovered feed only tells you video is available again. A recovered display doesn't prove a delivery or settlement backlog has cleared. Pending work must still pass its usual checks, and recovery doesn't authorize anyone to invent, reassign, or roll back measurement history.
The Pi saves measurements locally and tracks delivery separately for each configured reporting history. The Oracle checks records, the Reporter authorizes settlement, and chain readers build public views.
Cameras run independently. A public API or browser failure can hide records without changing them.
The Oracle blocks ineligible rounds, and the Reporter stops signing when settlement checks fail. Neither fills missing Pi records or treats a browser estimate as settled work.
The Guardian can pause SqueekCore; Timelock governance controls upgrades. API outages and camera failures grant no new permissions.
The Pi keeps saved telemetry during a network outage until the Oracle records a response. Only acceptance marks its rounds delivered; rejected or quarantined rounds remain available for later delivery in a corrected message.
A delivery failure for one reporting history does not delete or block another. Camera faults do not stop counting, round closure, telemetry, or other cameras.
Counting needs valid sensor readings, a reliable clock, and working local storage. Delivery and settlement also need networks, databases, signing, and Ethereum; there is no guaranteed uptime or catch-up deadline.
Public views distinguish missing, pending, and settled data. A missing response does not mean zero work.
| Failure | Expected boundary |
|---|---|
| Pico identity, sequence, heartbeat, or overflow fault | Stop counting rather than infer missing passages |
| Database or clock uncertainty | Stop counting; do not keep an unsaved fallback counter |
| Pi stopped or restarted | Rounds elapsed during the stop are closed as zero-work rounds on restart |
| Round reaches its work cap | Reject the passage and stop counting until an operator recovers the Pi |
| Network or Oracle outage | Save pending records; counting and rounds continue while sensor, clock, and storage remain healthy |
| Signing-chip failure | Delay delivery without switching to a software key; continue counting and saving work |
| Invalid or conflicting telemetry | Reject or quarantine it without changing accepted rounds |
| Uncertain broadcast outcome or chain mismatch | Check saved transaction attempts; a mismatch with chain history opens an incident and stops signing |
| Reorganization or insufficient confirmations | Do not show tentative results as confirmed settlement |
| Camera, overlay, or provider failure | Video can stop while measurement continues |
| Invalid, nonlive, or expired playback information | Show the feed as offline |
| Indexer or API lag | Mark public data stale or unavailable without changing chain records |
SqueekCore pause rejects settlement and makes SqueekMining checkpoint revert CorePaused. Owners can still claim funded rewards if NFT ownership checks and SqueekToken payments work; claims neither call SqueekCore nor mint SQK.
SqueekCore pause alone does not block NFT transfers, mint registration, or merges. Minting and merging still check SqueekCore, and a failed registration, donor burn, or payment cancels the entire transaction.
A backlog is waiting for delivery, not permission to invent or reassign old work. A restored display does not prove that all pending work has settled, and restoring an old backup cannot justify rolling back measurement history.
Applies SqueekCore or SqueekMining upgrades authorized by its governing Timelock.
Generates Squeek images and metadata from fixed onchain visual data.
Records physical work and earned block units on Ethereum, with difficulty adapting after active rounds.
Calculates rewards from settled work, holds funded SQK, and pays eligible NFT owners.
The Squeeks ERC-721 contract. Tracks NFT ownership and coordinates minting and merges with SqueekMining.
The SQK ERC-20 contract. Enforces the lifetime supply cap; only SqueekMining can mint SQK.
Queues governance operations and enforces a delay before they can be executed.
Checks that visual data conforms to the required DotGrid format.
When new power starts earning. Minting and merging schedule it for the next round, and a checkpoint applies it.
A reward update that processes settled Squeek blocks, issues their SQK, and applies scheduled power changes.
The Squeek permanently burned in a merge. Its unclaimed rewards move to the survivor, but its image is not combined or kept.
SQK issued as settled Squeek blocks are processed: 5,600 SQK for each completed block, up to the lifetime cap.
Squeekchain's record of accepted wheel-magnet passages.
Combining two eligible same-level Squeeks you own into one higher-level Squeek. One NFT is burned; the survivor keeps both Squeeks' unclaimed rewards.
The completed Squeek blocks a Squeek waits through before it can merge again. It follows the Squeek through transfers.
What a Squeek earns with. Its level sets its maximum power; each Squeek block's SQK is divided across all active power in proportion.
A ten-minute period used to group measured work. The device saves a completed round's work total when measurement remained uninterrupted.
The token each completed Squeek block issues, shared by active power. It has a lifetime supply cap.
An NFT that owns a share of the Squeekchain network. It receives SQK from the hamster's work according to its active power, set by its level and the SQK staked to it.
One billion block units earned from settled work at each round's difficulty. Completed blocks supply SQK under the mining reward rules.
Squeekchain's ecosystem for hamster-powered onchain finance, built on the public work record.
The Squeek you keep in a merge. It gains a level, keeps its ID and image, and receives both Squeeks' unclaimed rewards.
A Squeek's recorded reward balance that hasn't been paid to a wallet. It stays with the Squeek when ownership changes.
The hamster mining device. It records accepted wheel-magnet passages as work.
One wheel-magnet passage that met the device's counting rules.