DePIN Infrastructure Library

What happens when the device that feeds the AI also closes the loop?

The Gap​

The destination is built. The on-ramp isn't.

Smart contracts know what a device IS — identity, state, capabilities, performance, rewards. TypeScript clients can call those contracts. But between a physical sensor and the blockchain sits nothing. The HardwareAdapter interface has the right shape (start(), stop(), onEvent()). Its only implementation is InMemoryHardwareAdapter — a test double.

PHYSICAL DEVICE (sensor, actuator, gateway)
    │
    │  ← THE GAP: No MQTT, no HTTP webhook, no WebSocket, no BLE, no LoRa
    │     Zero real transport implementations
    │
    ▼
libs/infrastructure/hardware/         ← InMemoryAdapter only
    │
    │  ← PARTIAL: DePIN data adapters pull project analytics
    │     (DefiLlama, TokenTerminal, on-chain metrics)
    │     NOT device telemetry
    ▼
libs/infrastructure/blockchain/       ← TS clients call contracts ✓
    │
    ▼
libs/blockchain/                      ← Move + Anchor contracts ✓
    (device_registry, depin_core, depin_incentives, data_oracle)

The contracts handle on-chain identity and rewards. The data-api adapters handle DePIN project analytics (revenue, tokenomics). Nothing speaks to actual physical devices. The Raspberry Pi led_control experiment proved the concept — physical device → blockchain transaction — but it was a direct experiment, not an infrastructure pattern.

This PRD builds the road between physical devices and on-chain settlement.

Demand-Side Jobs​

Five jobs, ordered by the data flow from physical world to blockchain and back. Job 1 is the critical gap. Jobs 2-4 are partially built. Job 5 closes the VVFL loop.

Job 1: Connect Physical Devices to the Stack (THE GAP)​

Situation: A DePIN operator deploys 500 weather sensors across a city. Each sensor speaks MQTT. The blockchain contracts expect SensorEvent data with signatures and location proofs. Between MQTT publish and on-chain attestation there is nothing — every project builds a custom bridge from scratch.

Features that serve this job:

• Transport adapter interface (extending existing HardwareAdapter)
• MQTT adapter — industry standard for IoT telemetry (billion+ devices speak it)
• HTTP webhook adapter — simplest path, any device with WiFi can POST JSON
• WebSocket adapter — bidirectional, enables actuator commands back to devices
• Data normaliser — raw device payload → canonical SensorEvent schema
• Device signature verification — ed25519 or device-specific signing
• Location proof attachment — GPS coordinates with accuracy and timestamp
• Batch aggregator — collect N readings, hash, anchor one proof on-chain
• Quality scorer — uptime, data freshness, reading accuracy per device
• Dead letter queue — handle offline devices, failed deliveries, retries

Transport priority matrix:

Job 2: Register and Manage Devices On-Chain (BUILT — needs wiring)​

Situation: A DePIN protocol builder needs to onboard 10,000 weather sensors. Each device needs a unique on-chain identity, ownership tracking, firmware versioning, and the ability to transfer between operators.

What's already built:

• Sui device_registry — 5 device types, 4 states, owner/agent/operator, Location, capabilities, reputation, staking, metadata
• Sui depin_core — Protocol config, stats, pause/resume, admin transfer
• Solana depin_incentives — 7 device types, staking, performance metrics, reward multiplier, slashing
• Sui TS client for device registry
• Sui event indexer with device handlers

What's missing:

• Chain-agnostic TypeScript Device type that maps to both Sui and Solana shapes
• Solana depin_incentives full TypeScript client (9 instructions in contract, client partial)
• Fleet hierarchy (operator → fleet → device → sensor) in domain types
• Batch onboarding (Sui: object creation, Solana: compressed NFTs via Bubblegum)

Job 3: Verify and Store Sensor Data (PARTIALLY BUILT)​

Situation: A geospatial DePIN project collects positioning data from 50,000 GNSS receivers. The data needs verifiable provenance — proof that this data came from this device at this time at this location.

What's already built:

• Solana data_oracle — 11 instructions: provider registration, data submission with cryptographic proofs, multi-source aggregation, temporal validation, reputation, slashing
• Walrus adapter — blob storage on Sui's native storage layer
• SEAL encryption adapter — IBE encryption for device data at rest
• HardwareEvent interface — canonical event shape (deviceId, eventType, payload, timestamp)

What's missing:

• Transport adapters that produce HardwareEvent from real device protocols (Job 1)
• Normaliser — raw device payloads vary wildly, need canonical schema
• Verification pipeline wiring data_oracle proof verification to ingest flow
• Storage routing — policy-based: Walrus for hot data, Filecoin for archival, DB for indexing
• On-chain data anchoring — hash commitment per batch, not per reading
• Solana data_oracle TypeScript client (11 instructions in contract, client partial)

Job 4: Distribute Rewards Sustainably (PARTIALLY BUILT)​

Situation: A compute DePIN network needs to distribute tokens to 5,000 GPU providers weekly. The reward calculation depends on actual utilisation, not just uptime. Token emissions must stay below revenue to avoid the Ponzi trap.

What's already built:

• Solana depin_incentives — performance-weighted reward multiplier (uptime 50% + quality 100% + success rate 50%), staking, slashing, claim flow
• depin-score algorithm in agency lib — investment-grade DePIN project scoring
• DePIN data adapters — DefiLlama, TokenTerminal, on-chain metrics for project analytics

What's missing:

• Revenue/emission ratio tracking wired to on-chain ProtocolStats
• Sui incentives — rewards.move is a stub (RewardPool only), needs full epoch/distribution logic
• Epoch management — snapshot contributions, calculate, distribute cycle
• Sustainability dashboard data — revenue vs emissions over time, projected crossover
• Merkle tree distribution for Solana (cheaper than individual transfers at scale)

Job 5: Close the Loop — Actuator Commands (NOT BUILT)​

Situation: An AI agent processes sensor data, makes a decision, and needs to send a command back to a physical device — adjust irrigation, reroute a drone, change a traffic signal. The precision_agriculture contract already models weather predictions and yield forecasts. But the command path from AI decision to physical actuator doesn't exist.

Features that serve this job:

• WebSocket adapter with bidirectional channels (read telemetry + send commands)
• Command queue with confirmation (device ACKs execution)
• Safety constraints — max actuation rate, geofencing, human-override flag
• VVFL loop completion: Perceive → Question → Act → Measure → Learn
• Integration with existing A2A orchestrator for agent-to-device messaging
• Audit trail — every command logged with decision context and outcome

Chain Comparison: Sui vs Solana​

Both chains serve DePIN. Neither dominates the other. The split is architectural.

Where Each Chain Wins​

Architectural Verdict​

Solana wins for: token economics, reward distribution, DeFi composability, anything needing immediate ecosystem and liquidity. Helium's 900K hotspot cNFTs cost ~$122 total. The patterns are proven. Ship now.

Sui wins for: device state management with complex ownership hierarchies, IoT networks with independent device streams (owned-object tx bypass consensus entirely), and applications needing native programmable storage via Walrus. Build right.

The library supports both. Chain-specific implementations behind shared ports. Composition root selects the provider. Device management can run on Sui while token rewards run on Solana. The same workflow orchestrator doesn't care which chain settles which layer.

Other Chains to Watch​

Value Chain Architecture​

The AI data value chain has five layers. This library provides the TypeScript infrastructure to interact with each layer.

COLLECTION        CONNECTIVITY      STORAGE           COMPUTE           APPLICATION
(devices)         (transport)       (persistence)     (intelligence)    (actuation)

GEODNET           Helium            Walrus            io.net            Peaq robots
Hivemapper        World Mobile      Filecoin          Render            Autonomous agents
WeatherXM                           Arweave           Akash
DIMO                                                  Gensyn

High margin       Medium margin     Low-Med margin    High margin       Very high margin
Non-commodity     Commodity unless  5x cost advantage GPU shortage =    Where value is
data              coverage unique                     pricing power     consumed

The Alexander Wang insight: Scale AI proved data labeling is infrastructure ($870M→$2B revenue, 165% CAGR, $29B valuation). DePIN extends this from data LABELING to data COLLECTION — but the moat is community-owned devices, not a labour marketplace.

The transmitter/actuator insight: DePIN devices are dual-function. GEODNET feeds cm-accuracy GPS to drones (transmitter). The same positioning data guides the drone's flight path (actuator). The device that feeds the AI also closes the loop. This IS the VVFL feedback loop implemented in hardware.

Domain Model​

OPERATORS ←→ FLEETS
    ↕            ↕
DEVICES  ←→  SENSORS
    ↕            ↕
DATA STREAMS   REWARDS
    ↕            ↕
PROOFS       EPOCHS

Relationships​

Library Architecture​

The Full Data Flow​

PHYSICAL WORLD                    IoT TRANSPORT (THE GAP)              ON-CHAIN SETTLEMENT

Temperature sensor  ──MQTT──→  ┌─────────────────────┐               ┌──────────────────┐
GPS receiver        ──HTTP──→  │  Transport Adapter   │               │  device_registry  │
Camera feed         ──WS────→  │  (MQTT/HTTP/WS/BLE)  │               │  (Sui Move)       │
Actuator            ←─WS────   │                      │               │                   │
                               │  ↓ normalise         │               │  depin_core       │
                               │  ↓ sign              │               │  (protocol config) │
                               │  ↓ verify            │  ──anchor──→  │                   │
                               │  ↓ batch             │               │  depin_incentives  │
                               │  ↓ store (Walrus)    │               │  (Solana Anchor)   │
                               │  ↓ score quality     │               │                   │
                               │                      │  ←─rewards──  │  data_oracle       │
                               │  ↓ route commands    │               │  (Solana Anchor)   │
                               └──────────┬───────────┘               └──────────────────┘
                                          │
                                          ▼
                               ┌─────────────────────┐
                               │  Agent Orchestrator  │
                               │  (A2A + messaging)   │
                               │                      │
                               │  perceive → question  │
                               │  → act → measure     │
                               │  → learn             │
                               └──────────────────────┘

Layer Map​

libs/infrastructure/depin/
├── domain/                          # Zero deps — pure types
│   ├── device.types.ts              # Device, Fleet, Operator (chain-agnostic)
│   ├── sensor-event.types.ts        # SensorEvent (extends HardwareEvent + signature + location proof)
│   ├── reward.types.ts              # Epochs, distributions, sustainability
│   ├── command.types.ts             # Actuator commands, ACKs, safety constraints
│   └── ports/                       # Abstract interfaces
│       ├── transport.port.ts        # Start, stop, onEvent, sendCommand (bidirectional)
│       ├── device-registry.port.ts  # Register, transfer, query devices
│       ├── data-ingest.port.ts      # Normalise, verify, batch, route
│       ├── reward-engine.port.ts    # Calculate, distribute rewards
│       └── storage.port.ts          # Store and retrieve data blobs
│
├── transport/                       # IoT TRANSPORT ADAPTERS — the critical gap
│   ├── mqtt.adapter.ts              # P0 — MQTT 3.1.1/5.0 via broker (mosquitto, EMQX, HiveMQ)
│   ├── http-webhook.adapter.ts      # P0 — POST endpoint for device/gateway callbacks
│   ├── websocket.adapter.ts         # P1 — Bidirectional: telemetry in, commands out
│   ├── ble.adapter.ts               # P2 — Bluetooth Low Energy via gateway
│   ├── lorawan.adapter.ts           # P2 — LoRaWAN via TTN/Helium/Chirp gateway
│   ├── in-memory.adapter.ts         # Test/dev (migrated from InMemoryHardwareAdapter)
│   └── transport-factory.ts         # Create adapter from config: { type: 'mqtt', broker: '...' }
│
├── pipeline/                        # Data processing pipeline
│   ├── normaliser.ts                # Raw device payload → canonical SensorEvent
│   ├── signer.ts                    # Attach device signature (ed25519 or device-specific)
│   ├── verifier.ts                  # Verify signature, location proof, timestamp
│   ├── batch-aggregator.ts          # Collect N readings, hash batch, anchor one proof
│   ├── quality-scorer.ts            # Uptime, freshness, accuracy per device
│   ├── storage-router.ts            # Policy: Walrus (hot) / Filecoin (archive) / DB (index)
│   └── dead-letter.ts               # Offline devices, failed deliveries, retries
│
├── commands/                        # Actuator command channel (Job 5)
│   ├── command-queue.ts             # Queue commands, await ACK, retry/timeout
│   ├── safety-constraints.ts        # Max rate, geofencing, human-override flag
│   └── audit-trail.ts              # Log every command with decision context + outcome
│
├── clients-sui/                     # Sui-specific implementations (wire existing)
│   ├── sui-device-registry.ts       # Move contract client (object model) — EXISTS
│   ├── sui-depin-core.ts            # Protocol config client — NEEDED
│   ├── sui-reward-distributor.ts    # Direct transfer to owned objects — NEEDED
│   └── walrus-storage.ts            # Walrus blob storage — EXISTS (in adapters/)
│
├── clients-solana/                  # Solana-specific implementations
│   ├── solana-depin-incentives.ts   # 9-instruction client — NEEDED (contract built)
│   ├── solana-data-oracle.ts        # 11-instruction client — NEEDED (contract built)
│   ├── solana-device-registry.ts    # cNFT via Bubblegum — NEEDED
│   └── merkle-distributor.ts        # Batch reward distribution — NEEDED
│
├── reward-engine/                   # Chain-agnostic reward logic
│   ├── calculators/                 # Utilisation, coverage, quality weighted
│   ├── sustainability.ts            # Revenue/emission ratio wired to ProtocolStats
│   └── epoch-manager.ts             # Snapshot, calculate, distribute cycle
│
└── orchestrator/                    # Cross-layer workflow coordination
    ├── depin-provider.port.ts       # Abstract interface for any DePIN network
    ├── dual-mode-provider.ts        # Tier 1 (browser) + Tier 2 (API) execution
    ├── workflow-composer.ts          # Transport → verify → store → reward → command
    └── auto-promoter.ts             # Scout learns patterns, graduates to structured

Path Aliases (tsconfig.base.json additions)​

{
  "@stackmates/depin":              "libs/infrastructure/depin/domain/index.ts",
  "@stackmates/depin-transport":    "libs/infrastructure/depin/transport/index.ts",
  "@stackmates/depin-pipeline":     "libs/infrastructure/depin/pipeline/index.ts",
  "@stackmates/depin-commands":     "libs/infrastructure/depin/commands/index.ts",
  "@stackmates/depin-sui":          "libs/infrastructure/depin/clients-sui/index.ts",
  "@stackmates/depin-solana":       "libs/infrastructure/depin/clients-solana/index.ts",
  "@stackmates/depin-rewards":      "libs/infrastructure/depin/reward-engine/index.ts",
  "@stackmates/depin-orchestrator": "libs/infrastructure/depin/orchestrator/index.ts"
}

Dependency Rules​

@stackmates/depin (domain)          → zero deps, client-safe, runs anywhere
@stackmates/depin-transport         → @stackmates/depin, mqtt.js, ws (Node/edge)
@stackmates/depin-pipeline          → @stackmates/depin, @stackmates/depin-transport
@stackmates/depin-commands          → @stackmates/depin, @stackmates/depin-transport
@stackmates/depin-sui               → @mysten/sui, @stackmates/depin
@stackmates/depin-solana            → @solana/kit, @stackmates/depin
@stackmates/depin-rewards           → @stackmates/depin, @stackmates/agency (depin-score)
@stackmates/depin-orchestrator      → @stackmates/depin, @stackmates/depin-pipeline,
                                      @stackmates/depin-commands, @stackmates/infra-messaging

The domain layer imports nothing. Transport adapters implement domain ports. Pipeline composes transport + verification + storage. Chain clients talk to contracts. Orchestrator wires the full VVFL loop at the composition root.

Composition Root Pattern​

// libs/app-server/composition/depin-workflow.composition.ts

import { createTransport } from '@stackmates/depin-transport';
import { createPipeline } from '@stackmates/depin-pipeline';
import { SuiDeviceRegistry } from '@stackmates/depin-sui';
import { SolanaDataOracle } from '@stackmates/depin-solana';
import { WalrusStorage } from '@stackmates/depin-sui';
import { createRewardEngine } from '@stackmates/depin-rewards';
import { createWorkflowComposer } from '@stackmates/depin-orchestrator';

// 1. IoT TRANSPORT — the on-ramp from physical world
const transport = createTransport({
  type: 'mqtt',
  broker: 'mqtt://sensors.local:1883',
  topics: ['sensors/+/telemetry'],     // subscribe to all device telemetry
  commandTopic: 'devices/+/commands',  // publish actuator commands
});

// 2. DATA PIPELINE — normalise → verify → batch → store
const pipeline = createPipeline({
  transport,
  normaliser: sensorEventNormaliser,         // raw MQTT payload → SensorEvent
  verifier: ed25519SignatureVerifier,        // prove device identity
  batchSize: 100,                            // anchor 1 proof per 100 readings
  storage: new WalrusStorage({ publisherUrl }), // hot data on Walrus
  oracle: new SolanaDataOracle({ connection }), // proof verification on-chain
});

// 3. DEVICE MANAGEMENT — on-chain identity
const deviceRegistry = new SuiDeviceRegistry({ client: suiClient });

// 4. REWARDS — utilisation-weighted, sustainability-tracked
const rewards = createRewardEngine({
  calculator: utilisationWeighted,
  distributor: solanaRewardDistributor,
  sustainabilityThreshold: 1.0,  // revenue/emission ratio floor
});

// 5. ORCHESTRATOR — full VVFL loop
const orchestrator = createWorkflowComposer({
  perceive: pipeline,           // sensor data flows in
  question: agencyAlgorithms,   // AI processes data
  act: transport,               // commands flow back to actuators (bidirectional)
  measure: pipeline,            // telemetry confirms execution
  learn: rewards,               // quality scores feed reward calculation
  deviceRegistry,
});

Dual-Tier Agent Architecture​

The DHH/OpenClaw insight applied to DePIN: agents don't always need structured APIs.

// libs/infrastructure/depin/orchestrator/dual-mode-provider.ts

interface DePINProviderPort {
  // Tier 2: Structured, fast, cheap — for production workloads
  getDeviceData(deviceId: string): Promise<SensorReading>;
  submitProof(proof: ContributionProof): Promise<TxHash>;

  // Tier 1: Browser-based, flexible — for exploration and onboarding
  exploreNetwork(networkUrl: string): Promise<NetworkSchema>;
}

interface DualModeConfig {
  structured?: StructuredProvider;   // Use when API/SDK exists
  exploratory?: BrowserProvider;     // Use when it doesn't (yet)
  autoPromote: boolean;              // Learn patterns, graduate to structured
}

Tier 1 (Scout): Agent navigates a new DePIN network's web interface cold. Signs up, reads docs, discovers data structures. Slow, expensive, infinitely flexible. Used for onboarding to networks that don't have APIs yet.

Tier 2 (Operator): Structured SDK calls. Fast, cheap, reliable. Used for production workloads — real-time data ingestion, reward distribution, device management.

Auto-promotion: Tier 1 scouts learn patterns. When a pattern stabilises, the system generates a Tier 2 integration. Over time, the library accumulates structured integrations that started as zero-accommodation exploration. The scout becomes the operator.

Existing Assets — Three-Layer Stack Already Built​

The engineering repo has a substantial DePIN stack across three layers. This PRD connects and extends what exists.

Layer 1: Smart Contracts (libs/blockchain/)​

Sui Move contracts:

The device.move contract is production-grade: 5 device types, 4 device states (active/inactive/maintenance/decommissioned), owner + agent + operator separation, location with GPS accuracy, capabilities as dynamic vector, reputation scoring, staking, metadata table. This is the Sui device management layer.

Solana Anchor programs:

The Solana depin_incentives program has a performance-weighted reward multiplier: uptime bonus (50%), quality bonus (100%), success rate bonus (50%). Device types include Custom(u8) for extensibility. Performance metrics track uptime, data provided, quality score, jobs completed/failed, average response time.

The data_oracle program is a complete oracle network: provider registration, data submission with cryptographic proofs, multi-source aggregation, temporal validation, reputation scoring, and slashing for malicious providers.

Layer 2: TypeScript Clients (libs/infrastructure/blockchain/)​

Layer 3: Infrastructure Adapters (libs/infrastructure/)​

What's Actually Missing​

The contracts and clients exist. What's missing is the wiring layer — the TypeScript infrastructure lib that composes all three layers into usable workflows.

Rename: hardware → depin​

The current libs/infrastructure/hardware/ library has the right abstractions but the wrong name and scope. The rename is structural, not cosmetic:

The existing interface becomes the seed. The chain-agnostic domain types unify the Sui device.move struct and Solana Device account into one TypeScript shape.

Business Model​

Revenue Architecture​

Stackmates captures value at three points in the DePIN stack:

Unit Economics Targets​

Flywheel​

More agent templates
  → More DePIN operators adopt Stackmates
    → More workflow data
      → Better agent performance
        → More templates
          → repeat

The data from orchestration becomes the moat, not the code.

Commissioning​

Ordered by the data flow: physical device → transport → pipeline → chain → rewards → commands.

What's Built vs What's Needed​

Maturity Targets​

Success Criteria​

Functional​

Non-Functional​

Risk + Kill Signal​

Kill signal: If after 6 months no DePIN protocol has integrated any library component, the abstraction is wrong. The market wants vertical solutions (per-protocol), not horizontal infrastructure (cross-protocol). Pivot to building protocol-specific agent templates instead.

What would change the thesis: If revenue/emission ratios prove unsustainable across most DePIN projects (revenue never catches emissions), the economic model fails. Watch: io.net revenue trajectory, Helium subscriber growth, Filecoin paid storage volume.

Shape Up​

Appetite: 3-week cycle, transport-first.

Cycle 1 — The On-Ramp (P0): Rename hardware → depin. Define domain types (SensorEvent extending HardwareEvent, chain-agnostic Device). Build MQTT adapter and HTTP webhook adapter. Test: ESP32 sensor → MQTT broker → adapter → SensorEvent → console log. This proves the physical-to-digital bridge.

Cycle 2 — The Pipeline: Build normaliser, signature verifier, batch aggregator, storage router. Wire Walrus adapter as storage backend. Wire Solana data_oracle TS client for proof verification. Test: MQTT sensor reading → normalise → verify → store on Walrus → anchor proof hash on-chain.

Cycle 3 — Close the Loop: Build WebSocket adapter (bidirectional). Build command queue with ACK and safety constraints. Wire to precision_agriculture contract (sensor reading → AI prediction → irrigation command → device executes). Wire reward sustainability tracker to on-chain ProtocolStats.

Next Steps​

1. Rename libs/infrastructure/hardware/ → libs/infrastructure/depin/
2. Define domain types: SensorEvent (extends HardwareEvent + signature + locationProof + qualityScore),
   Device (unifies Sui device.move + Solana Device account), Command (actuator instructions)
3. Build MQTT transport adapter implementing TransportPort (mqtt.js, topic subscription, reconnect)
4. Build HTTP webhook transport adapter (POST endpoint → SensorEvent)
5. Build data normaliser (raw device payloads → canonical SensorEvent)
6. Wire pipeline: MQTT adapter → normaliser → verifier → Walrus storage → data_oracle proof anchor
7. Build Solana data_oracle TypeScript client (11 instructions in contract, needed for verification)
8. Build WebSocket adapter (bidirectional — telemetry in, commands out)
9. Build command queue with ACK, retry, and safety constraints
10. Wire depin-score algorithm to on-chain ProtocolStats for sustainability tracking

Smallest move: Rename the lib. Build MQTT adapter that implements the existing HardwareAdapter interface — start() connects to broker, stop() disconnects, onEvent() forwards messages as HardwareEvent. Run against a local mosquitto broker with a temperature sensor publishing JSON. If a real sensor reading arrives as a typed HardwareEvent in the Node process, the on-ramp exists.

Kill signal: If the MQTT adapter can't sustain 1,000 messages/second from a local broker without dropping messages, the architecture won't scale to real DePIN networks. Test throughput before building the pipeline.

Key architectural insight: The contracts model the destination (what a device IS, what it earns). The transport models the journey (how data gets from physical world to digital). The pipeline is the bridge. The command channel closes the loop. Build bottom-up: transport → pipeline → chain wiring → orchestration. Not top-down.

Key insight from contracts review: The Sui contracts model devices as things with identity (UID, capabilities, metadata table). The Solana programs model devices as things with performance (uptime, quality score, jobs completed, reward multiplier). Both are needed. The chain-agnostic type should carry identity from Sui and performance from Solana — the two chains complement rather than compete at the type level.

Mycelium Capability​

The DePIN Infrastructure Library is a physical-world capability. It extends the Mycelium into hardware — devices that perceive, compute, store, and act. Every other Mycelium capability operates in software. This one closes the loop with the physical world.

Currently Growing In: stackmates

The VVFL connection: DePIN devices PERCEIVE (collect ground truth) → AI QUESTIONS (trains on data, builds predictions) → Actuators ACT (robots, autonomous systems execute) → Outcomes MEASURED (device telemetry records results) → System LEARNS (model improves, device network adapts). The dual transmitter/actuator role means the same device that feeds the loop also closes it.

Context​

• DePIN Platform — Core DePIN concepts, stack layers, device categories
• DePIN Devices — Hardware evaluation framework
• Phygital Marketing — Physical + digital integration patterns
• Solana DePIN Programs — Raspberry Pi example, circuit → blockchain
• Sui Tech — Object model, Move, zkLogin, PTBs
• Sui Wallet Safety — Safety patterns for chain interactions
• DePIN Tokens — Token economics reference
• Jobs To Be Done — Demand-side thinking
• AI Data Industry — Value chain, transmitter/actuator framing
• Robotics Industry — Autonomous systems that consume DePIN data
• The Infrastructure Flip — DePIN coordination thesis
• Phygital Mycelium — The capability catalogue