Each scenario below uses the Robot Shares primitives — RS-ID, RS-Registry, RS-Pay, RS-Access, RS-Verify — to show how autonomous machines transact and cooperate on Kaspa L1 without human intervention.
01 // Autonomous Charging Network
A decentralized network of charging stations — solar-powered rooftop units, garage chargers, commercial fast-chargers — all registered on RS-Registry and earning KAS from any machine that needs power. No company runs the network. No app required. The machines negotiate directly.
The Scenario
A delivery drone (Bot0) is running low on battery mid-route. It needs to find the nearest compatible charger, negotiate a rate, pay for the session, and resume its delivery — all autonomously, in under 60 seconds.
+--[Charger C]--+
| solar rooftop |
| 0.0008 KAS/kWh|
+-------+--------+
|
+--[Bot0]--+ RS-Registry +--+--+ +--[Charger A]--+
| Drone |------ query ------>| REG |-----| garage unit |
| 28% batt| | vProg| | 0.0015 KAS/kWh|
+----+-----+ +--+---+ +----------------+
| |
| Best match: Charger C | +--[Charger B]--+
|<----------------------------+ | commercial |
| | OFFLINE |
| +----------------+
|
| Fly to Charger C
| Authenticate (RS-ID)
| Check permissions (RS-Access)
| Lock 0.5 KAS escrow (RS-Pay)
| Charge for 12 minutes
| Charger submits proof (RS-Verify)
| Escrow releases 0.38 KAS to Charger C
| Refund 0.12 KAS to Bot0
|
v
Resume delivery route (92% battery)
Economic Model
Anyone with a charger and a solar panel becomes a node in the network. The charger earns KAS for every session. The owner can set their own rates, availability windows, and compatible machine types — all configured in their RS-Registry entry. No platform takes a cut. The only fee is Kaspa's near-zero transaction cost.
Over time, a charger builds an on-chain reputation: sessions completed, uptime percentage, dispute rate. Machines prefer chargers with strong track records. The market self-regulates.
02 // Drone Fleet Operations
A fleet of autonomous drones — owned by different operators, serving different clients — shares airspace, coordinates handoffs, and settles payments for shared infrastructure. No central air traffic controller. The fleet self-organizes through on-chain coordination.
The Scenario
An e-commerce package needs to travel 40km across a metropolitan area. No single drone has the range. Three drones from different operators relay the package, each earning KAS for their leg of the journey.
WAREHOUSE RELAY POINT A RELAY POINT B CUSTOMER
========= ============= ============= ========
| | | |
| Drone-1 (Op.A) | Drone-2 (Op.B) | Drone-3 (Op.C) |
| Range: 15km | Range: 18km | Range: 12km |
| | | |
+===== LEG 1: 14km ======>+ | |
| RS-Pay: 2.1 KAS | | |
| | | |
| Handoff Protocol: | | |
| 1. RS-ID verify | | |
| 2. RS-Access check | | |
| 3. Cargo scan | | |
| 4. RS-Verify proof | | |
| 5. Custody transfer | | |
| | | |
| +====== LEG 2: 17km ====>+ |
| | RS-Pay: 2.8 KAS | |
| | | |
| | +===== LEG 3: 9km ======>+
| | | RS-Pay: 1.5 KAS |
| | | |
| TOTAL: 6.4 KAS across 3 operators |
| Settled atomically on Kaspa L1 |
| Package delivered in 38 minutes |
Handoff Protocol
Each relay point is a choreographed sequence:
- Incoming drone broadcasts approach to RS-Registry with cargo manifest hash
- Relay drone authenticates via RS-ID mutual credential exchange
- RS-Access confirms relay drone is authorized for this cargo class
- Physical handoff — both drones scan cargo, generate RS-Verify proof of intact transfer
- RS-Pay escrow for the completed leg releases to the delivering drone
- New escrow locks for the next leg
If any step fails — wrong drone, damaged cargo, unauthorized operator — the handoff aborts and the escrow refunds. The package returns to the last verified custodian.
03 // Sensor Data Marketplace
Thousands of independent sensors — air quality monitors, traffic cameras, weather stations, soil moisture probes — sell their verified data streams to any buyer willing to pay. The data is ZK-proven authentic. The payments are automatic. The marketplace has no middleman.
The Scenario
An agricultural AI needs real-time soil moisture data across a 500-acre region. Instead of deploying its own sensors, it subscribes to 47 independent soil probes already registered on RS-Registry, each owned by different farmers. The AI pays per-reading in KAS. Each reading is RS-Verified.
SOIL PROBES (47 independent) RS-VERIFY DATA CONSUMER
============================ ========= =============
(Agri-AI)
[Probe-01] --+--> reading --+
[Probe-02] --+ |
[Probe-03] --+ +---> Tier 1: Origin sig ----+
[Probe-04] --+ | (each probe signs |
... | | with RS-ID key) |
[Probe-47] --+ | |
+---> Tier 2: Anomaly check -+--> ZK Proof
| (ML flags outliers, | of dataset
| cross-ref neighbors) | integrity
| |
+---> Tier 3: Cross-verify --+
(nearby probes must |
broadly agree) |
|
Settled on Kaspa L1
|
PAYMENT FLOW: v
============= Agri-AI receives
Agri-AI subscription covenant 47 verified readings
releases 0.0001 KAS per reading + single ZK proof
to each probe's wallet automatically of full dataset
Why ZK Matters Here
Without RS-Verify, the AI has to trust each sensor's raw data — any one could be spoofed, miscalibrated, or malicious. With ZK-proven data verification, the AI receives a single compact proof that attests: these 47 readings came from registered, authenticated devices, passed anomaly detection, and are cross-corroborated by neighbors. The AI can act on this data with cryptographic confidence.
Privacy bonus: Farmers selling soil data might not want to reveal their exact field locations or proprietary irrigation schedules. RS-Verify proofs can attest to data quality without exposing the underlying details — the buyer gets "verified moisture level for zone 7" without learning the farm's GPS coordinates.
04 // Machine-to-Machine Logistics
Autonomous ground robots, conveyor systems, and warehouse bots coordinate complex logistics chains — receiving shipments, sorting packages, staging deliveries — without a centralized warehouse management system. Each machine is an independent economic agent, earning KAS for the work it performs.
The Scenario
A shipment arrives at a distribution hub. From dock to delivery vehicle, five different autonomous machines handle it — each owned by a different operator, each paid per-task.
DOCK SORT STORE STAGE LOAD
==== ==== ===== ===== ====
+--------+ +----------+ +-----------+ +-----------+ +----------+
| Unload | | Sort-Bot | | Store-Bot | | Stage-Bot | | Load-Bot |
| Bot |---->| scans & |---->| places in |---->| retrieves |---->| loads to |
| (Op.A) | | routes | | rack slot | | for order | | vehicle |
| | | (Op.B) | | (Op.C) | | (Op.C) | | (Op.D) |
+---+----+ +----+-----+ +-----+-----+ +-----+-----+ +----+-----+
| | | | |
| | | | |
RS-Verify: RS-Verify: RS-Verify: RS-Verify: RS-Verify:
photo proof barcode + slot location retrieval + loaded +
of intact weight match + temp reading condition manifest
receipt check match
| | | | |
+-------+-------+---------+-------+--------+-------+-------+---------+
| | | |
0.02 KAS 0.03 KAS 0.01 KAS 0.02 KAS
to Op.A to Op.B to Op.C to Op.D
| | | |
+--------+--------+---------+-------+ |
| | |
v v v
All settled atomically on Kaspa L1 via RS-Pay covenant chain
Chain of Custody
Every handoff between machines generates an RS-Verify proof — a cryptographic receipt proving the package was in the right condition at the right place at the right time. The full chain of custody is an immutable, ZK-proven audit trail on Kaspa L1. If a package arrives damaged, the proofs pinpoint exactly which leg of the chain had the issue.
Composability in action: The entire five-step logistics chain — receiving, sorting, storing, staging, loading — settles as a batch on Kaspa L1 through a single vProg batch proof. Five operators, five machines, five payments, five verification proofs — one atomic settlement. This is only possible because vProgs provide synchronous composability on L1.
Why Kaspa, Not Another Chain?
Every use case above requires specific properties from the settlement layer. Here's why Kaspa with vProgs is the right foundation:
| Requirement | EVM L1s | L2 Rollups | Kaspa + vProgs |
|---|---|---|---|
| Sub-second finality | Minutes (12s blocks + confirmations) | Minutes to hours (challenge period) | Instant (DagKnight) |
| Micro-tx viable | $0.50-50+ gas kills IoT | $0.01-0.10, still adds up at scale | Fractions of a cent |
| Atomic cross-app tx | Yes (but congestion) | No (bridge delays, fragmentation) | Yes (synchronous composability) |
| Censorship resistance | PoS validator cartels | Centralized sequencers | Pure PoW, no capture |
| Scalability | Limited by block gas | Limited by DA layer | Horizontal (prover market) |
| Privacy | All state public | All state public | ZK proofs hide details |
| MEV protection | Rampant front-running | Sequencer can extract | DAG + deterministic ordering |
Machines can't afford to wait. They can't afford high fees. They can't afford to be censored. They can't afford fragmented liquidity across bridges. Kaspa with vProgs eliminates all of these constraints at the consensus layer.
