> For the complete documentation index, see [llms.txt](https://docs.konnex.world/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.konnex.world/understand-konnex/design-overview.md).

# 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&#x20;*****shape*****&#x20;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.
