# Design overview

## The problem: attestation, not raw capability

Autonomous systems can already execute impressive **physical** work: drone inspection, robotic manipulation, 3D reconstruction. In many deployments, the **execution record** is **operator-attested** — produced and signed by the same party that ran the machine. That is acceptable in closed, low-stakes environments; it is **structurally insufficient** when the **consumer** of the record carries **liability**: a regulator, an insurer pricing risk, or an engineering sign-off on a multi-million-dollar decision.

The missing piece is **independent verification**: evidence and scoring that are **uncorrelated** with the operator’s self-interest, backed by **cryptography** and **clear economic penalties** for fraud.

Konnex addresses this with a **decentralized network** where:

* **Task instructions** are **signed and anchored** onchain.
* **Miners** compete to execute under subnet rules.
* **Validators** with **no operational stake** in a given operator score execution against the instruction.
* **Proof-of-Physical-Work (PoPW)** binds policy traces and **sensor evidence** (including **hardware-level** attestation where applicable) into a **single** verifiable record.

## Workload classes (subnets), not one generic “chat” market

Konnex is organized by **workload class** — each subnet corresponds to a real commercial pattern (aerial inspection, manipulation, 3D/SLAM) with its own **input schema** and **scoring function**. That allows:

* **Enterprises** to negotiate scoring that reflects real contracts, not only synthetic leaderboards.
* **Miners** to **specialize** in one class (e.g. SLAM) without competing on every other robot modality.

**Live on testnet today:** [drone navigation](/subnets-workload-classes/drone-navigation.md), [roboarm VLA](/subnets-workload-classes/roboarm-vla.md), and [SLAM 3D map](/subnets-workload-classes/slam-3d-map.md). **Signed enterprise counterparties** are active in these workload classes; their **full** commercial execution may still run offchain in their own environments while the testnet demonstrates the **verification and settlement** layer that **mainnet** is meant to host.

## Two protocol layers in the long-run design

1. **Coordination and verification** — Mesh-friendly transport, onchain registries, PoPW, validator economics (see [Protocol architecture](/understand-konnex/protocol-architecture.md)). **Mesh transport** and full **robot–robot** contract products are **staged**; see the [roadmap](/understand-konnex/roadmap.md).
2. **Settlement** — **Stablecoin-denominated** escrows, penalties, and rewards for **enterprise** users, with **KNX** for **protocol** security, governance, and **gas routing** — a **dual-token** design so operational teams can budget in **fiat-pegged** terms. Full stablecoin mainnet dual-staking is not all live on the first public testnet; see [Stablecoins integration](/understand-konnex/stablecoins-integration.md) and the [roadmap](/understand-konnex/roadmap.md).

## Inheritance from Bittensor-style subnet economics

Konnex **inherits the network topology and incentive *****shape***** familiar from** production-style **subnet** networks such as [Bittensor](https://docs.learnbittensor.org/) — subnet creators, miners, validators, and stakers — so experienced **node operators** can onboard with minimal relearning. The **workload and verification** layer is **different** by design: physical tasks need [Proof-of-Physical-Work](/understand-konnex/contracts-and-popw.md), not only statistical quality of text outputs.

## Where to start

* [Proof-of-Physical-Work (PoPW)](/understand-konnex/contracts-and-popw.md)

### Example policy (abridged, manipulation-style)

```
1. Move arm to a safe home pose.
2. Open fridge → smooth_move to handle position.
3. Verify ingredients; if missing, request restock or abort with proof.
4. Grasp object using camera feedback; respect torque limits.
5. Place in target container; log thermal and contact traces per subnet policy.
```

The **subnet** turns this class of task into a concrete schema, simulator or sensor checks, and **PoPW** requirements.


---

# 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/design-overview.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.