> Documentation index: https://docs.squeekchain.com/llms.txt. Use it to find every page.

# How work reaches Ethereum

> How verified measurement rounds become settled work on Ethereum.

Web version: https://docs.squeekchain.com/system/settlement/

## TL;DR

- Settlement adds verified wheel-work records to Ethereum, where they complete Squeek blocks.
- A submitted transaction succeeds and passes confirmation checks before it appears as confirmed work.
- A later checkpoint issues the SQK for settled blocks.

## Why settle on Ethereum?

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

Each step follows the previous one: recent activity, an accepted record, a transaction hash, and confirmed settlement are successive stages. Settled work then waits for a [checkpoint](https://docs.squeekchain.com/rewards/checkpoints.md) to issue its SQK.

## How it works

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.

`SqueekCore` checks the signed batch before recording the work. Public chain views show it after deployment checks and 12 confirmations. Every settled round traces back to a saved device record.

## Why can settlement take longer?

The Reporter runs on a five-minute schedule. Outages, eligibility checks, incidents, insufficient gas, and indexing delays can all delay the public result, so the schedule sets how often the Reporter checks for work rather than a settlement deadline.

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 | `SqueekCore` 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 rules

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. `SqueekCore` prices each active round at the previous difficulty, then steers difficulty for later work. Its `RoundRecorded` events carry physical work, earned block units, and the new difficulty; `BatchSettled` closes the certified interval.

- 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 `SqueekCore` 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.
- An elapsed all-zero span can settle with an empty active-round list; certification need not wait for later positive work or a nightly boundary.
- Work above the configured per-round cap rejects the whole batch. `SqueekCore` never truncates or repairs the device's work.
- 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 `SqueekCore` records, Pi counting, or Oracle receipt checks.
- `SqueekMining` and `SqueekToken` fund rewards; a `SqueekCore` `BatchSettled` event does not tell you how much SQK you can claim.

### Example

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. `SqueekCore` adds 10 work units but creates no token balance.

Illustrative batch: `SqueekCore` 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. `SqueekCore` records rounds 11 and 12 as zero and adds only 5 work units.

If rounds 11 and 12 are eligible before round 13 arrives, an empty active-round list can instead certify through round 12. The frontier advances while physical work, earned block units, and difficulty remain unchanged.

## Related pages

- [Rounds and Squeek blocks](https://docs.squeekchain.com/system/rounds-and-blocks.md)
- [SqueekCore](https://docs.squeekchain.com/developers/core.md)
- [How SQK is issued](https://docs.squeekchain.com/rewards/creation.md)
- [Governance and upgrades](https://docs.squeekchain.com/security/governance.md)