# Proof-of-Physical-Work (PoPW), TEE, and contracts

> **Spelling:** The verification primitive is **Proof-of-Physical-Work (PoPW)**. Do not confuse it with unrelated “proven work” phrasing.

## What PoPW binds

**Proof-of-Physical-Work (PoPW)** is the Konnex verification primitive for physical-world jobs. A PoPW record combines four elements into a coherent onchain (or onchain-anchored) artefact:

1. **Task instruction** — Agreed at issue time, signed by the operator, content-hashed and anchored onchain.
2. **Policy execution trace** — The sequence of actions the robot’s policy (or full stack) produced in response to that instruction.
3. **Sensor bundle** — Pose, frames, IMU, torque, temperature, and other channels the subnet’s verification function requires. Where enterprise assurance applies, critical telemetry is signed in hardware (TEE or secure element) *before* it reaches a general-purpose host OS, so validators can detect post-hoc synthesis or replay.
4. **Independent scoring** — Validators with no operational stake in the operator score safety, task match, efficiency, and coherence with the instruction and subnet rules.

Downstream users—regulators, insurers, customers, other robots—can line up a single story: this instruction, this trace, this signed evidence, these scores, with instruction hashes and commitments onchain.

Independent scoring is not enough if an attacker can spoof sensors at the source. The full design therefore assumes two additional security layers:

### Hardware-rooted provenance (TEE / secure elements)

If the bits are fake, off-device verification does not help. The first line of defense is on the device: trusted execution environments and secure elements sign telemetry and media at capture time. Validators check signatures, freshness, and binding to the task so that synthetic or replayed streams fail verification.

### Economic finality and asymmetric risk

Hardware roots the data; economics constrains behavior. Miners and validators are intended to post stake in KNX and, on mainnet, stablecoin assurance tranches. Slashing for proven misbehavior—collusion, fraud, or bypassing attestation—is designed so the expected cost of attack exceeds the plausible upside from faking a job.

Together, these are what make PoPW a *physical* verification primitive, not a renamed “best-of-N text” competition.

## Why inference networks are a different game

Open decentralized networks for inference excel when the output is a token stream and quality is a statistical property. Physical work fails differently: the drone flew to the wrong structure, the arm grasped the wrong object, the mesh invented geometry. Those are safety, task-match, and provenance errors. Verification has to follow the work: sensor traces, timestamps, and binding to a signed task—not only benchmark scores on sampled outputs.

## Subnets and workload classes

Each subnet encodes a commercial workload class (schema, scoring, and miner competition). See the [subnets overview](/subnets-workload-classes/subnets.md). Subnet app URLs are published with official testnet releases.

## Robot-to-robot smart contracts and stablecoin escrows (roadmap)

> **Scope:** Inter-robot smart contracts with native stablecoin escrow, deadlines, and penalties on mainnet are part of the long-term product surface. They are *not* guaranteed in the first public testnet build. For what runs today, see the [roadmap](/understand-konnex/roadmap.md) and official **release notes**.

The intended job flow is:

1. **Offer** — Post a job with reward and deadline (stablecoin on mainnet).
2. **Bid** — Robots or fleets respond with ETA, location, and deposits.
3. **Match** — Parties lock escrow and deposits onchain.
4. **Execute** — Worker records sensor snapshots per policy.
5. **Prove** — Submit a PoPW bundle bound to the JobID.
6. **Settle** — Validators verify; release funds or apply penalties.

What counts as proof is workload-specific: delivery (path plus arrival media), process control (thermal logs and camera stills), inspection (imagery of named elements), and so on. Disputes, missed deadlines, and bad evidence trigger slashing and refunds according to the contract and validator layer.

## See also

* [Protocol architecture](/understand-konnex/protocol-architecture.md)
* [Stablecoins integration](/understand-konnex/stablecoins-integration.md)
* [Validating](/participate/validating.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.konnex.world/understand-konnex/contracts-and-popw.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.