Pauses and unavailable servicesLink to this section

TL;DRLink to this section

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.

Does an outage mean counting has stopped?Link to this section

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.

What does a contract pause stop?Link to this section

A Core 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.

How should you read a recovery?Link to this section

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.

Technical detail: independent servicesLink to this section

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.

PermissionsLink to this section

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 Core; Timelock governance controls upgrades. API outages and camera failures grant no new permissions.

GuaranteesLink to this section

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.

AssumptionsLink to this section

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 behaviorLink to this section

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
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

Contract dependency failuresLink to this section

Core pause rejects settlement and makes Mining checkpoint revert CorePaused. Owners can still claim funded rewards if NFT ownership checks and Token payments work; claims neither call Core nor mint SQK.

Core pause alone does not block NFT transfers, mint registration, or merges. Minting and merging still check Core, and a failed registration, donor burn, or payment cancels the entire transaction.

Interpreting recoveryLink to this section

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.

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.