How work reaches EthereumLink to this section

TL;DRLink to this section

Settlement adds checked wheel-work records to Ethereum.
A submitted transaction still needs to succeed and pass confirmation checks before it appears as confirmed work.
There isn't a promised settlement time.
Recording work doesn't mint SQK or make rewards ready to claim.

What does settlement add?Link to this section

The device saves wheel work before any of it reaches Ethereum. Settlement takes eligible, checked rounds from that history and records them in Core, the contract that tracks settled work. The public chain view then waits for confirmations before showing the result.

These are separate steps, not an instant update from the wheel. Seeing recent activity, an accepted record, or a transaction hash doesn't mean the work has settled. Even a successful settlement doesn't by itself fund rewards: Mining and Token handle that separately.

How it worksLink to this section

The Oracle first verifies the device's records and completed round totals. The Reporter selects eligible work and signs permission to settle that exact batch. A separate relayer sends the transaction to Ethereum and pays its gas cost.

Core checks the signed batch before recording the work. Public chain views show it after deployment checks and 12 confirmations. Neither the Oracle nor the Reporter may invent missing device records to move this process forward.

Why can it take longer?Link to this section

The Reporter runs on a five-minute schedule, but that's not a settlement deadline. Outages, eligibility checks, incidents, insufficient gas, and indexing delays can all delay the public result.

The stages below help distinguish waiting for a submission from waiting for a confirmed result.

Milestone	What it means	What it does not mean
Accepted telemetry	Oracle checks passed	Work has settled or rewards are funded
Eligible closure	A completed round is approved for settlement	A transaction has been sent
Prepared authorization	The batch has been signed and saved	Ethereum has executed it
Submitted transaction	The relayer sent it to Ethereum	It succeeded or has enough confirmations
Successful receipt	`Core` executed the transaction	Public confirmed views already include it
Confirmed projection	The result passed confirmation and deployment checks	It can never be reorganized, or rewards are funded

Technical detail: settlement rulesLink to this section

Each batch names the last round it covers, called the certification frontier. It lists positive-work rounds explicitly and certifies omitted rounds within that range as zero. Core emits RoundRecorded and BatchSettled events for the settlement.

The Oracle checks signatures, device identity, approved counter history, record order, hardware origin, and exact round totals. Cumulative work must not decrease.
The Reporter uses EIP-712 to sign the batch, including the Core implementation, a one-use nonce, and a deadline.
If a submitted transaction's outcome is uncertain, the service checks the saved attempt rather than guessing a replacement batch.
A batch contains at most 16 positive-work rounds. Zero-work gaps do not count toward this limit.
The Reporter waits for positive work before submitting preceding zero-work rounds.
Retrying identical telemetry does not count it twice; the Oracle rejects conflicting duplicates.
A successful authorization uses up its nonce. Pausing, unpausing, or rotating the Reporter invalidates prepared signatures.
The Reporter stops signing if deployment, RPC, contract code, telemetry, incident, or saved transaction checks leave an unresolved outcome.
Indexer or API failure affects public views, not Core records, Pi counting, or Oracle receipt checks.
Mining and Token fund rewards; a Core BatchSettled event does not tell you how much SQK you can claim.

ExampleLink to this section

Illustrative sparse batch: round 1 closes with 4 work units, round 2 with zero, and round 3 with 6. A batch through round 3 carries positive entries for rounds 1 and 3 while certifying round 2 as zero. Core adds 10 work units but creates no token balance.

Illustrative batch: Core has settled through round 10. The Pi records zero work in rounds 11 and 12, then 5 work units in round 13.

The Reporter submits a batch through round 13 with one positive entry for that round. Core records rounds 11 and 12 as zero and adds only 5 work units.

Without a later positive-work round, the Reporter keeps the zero-work rounds waiting. They remain recorded zeros, not missing observations.

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.