Robot Shares provides a modular stack of on-chain primitives — built on Kaspa and vProgs — that give machines everything they need to operate as autonomous economic agents. Each primitive is a sovereign vProg on Kaspa L1, communicating through ZK-verified state transitions with instant DAG finality.
+=====================================================+
| ROBOT SHARES PLATFORM |
|=====================================================|
| |
| +----------+ +----------+ +----------+ |
| | RS-ID | | RS-PAY | |RS-ACCESS | |
| | Machine | | Escrow & | | Role- | |
| | Identity | | Micro-tx | | Based | |
| +----+-----+ +----+-----+ +----+-----+ |
| | | | |
| +----+--------------+--------------+----+ |
| | RS-REGISTRY | |
| | On-Chain Machine Directory | |
| +----+--------------+--------------+----+ |
| | | | |
| +----+-----+ +----+-----+ |
| |RS-VERIFY | | vProg | |
| | ZK Data | | Runtime | |
| | Proofs | | | |
| +----+-----+ +----+-----+ |
| | | |
| +----+--------------+----+ |
| | KASPA L1 BLOCKDAG | |
| | DagKnight + PoW + ZK | |
| +------------------------+ |
+=====================================================+
RS-ID
Self-Sovereign Machine IdentityEvery machine in the Robot Shares network gets a cryptographic identity anchored to Kaspa L1. No central authority issues or revokes these identities — they are self-sovereign, owned by the machine (or its operator), and verifiable by anyone.
RS-ID is built on the W3C Decentralized Identifier (DID) standard. Each machine generates its own keypair, registers a DID document as state in the RS-ID vProg, and can present verifiable credentials to any peer. The identity persists on-chain, secured by Kaspa's proof-of-work consensus — no staking cartel or governance vote can revoke it.
How it works:
- Machine generates an ECDSA keypair on its secure element or TPM
- Operator submits a DID registration transaction to the RS-ID vProg
- vProg executes off-chain, generates a ZK proof of valid registration
- Proof settles on Kaspa L1 — identity is now globally verifiable
- Machine can issue and present Verifiable Credentials (capabilities, certifications, service history)
+-------------+ +------------------+ +----------------+
| MACHINE | | RS-ID vProg | | KASPA L1 |
| (Bot0) | | (off-chain) | | (on-chain) |
+------+------+ +--------+---------+ +-------+--------+
| | |
| 1. Generate keypair | |
| (ECDSA / Ed25519) | |
| | |
| 2. Submit DID doc | |
|---------------------->| |
| | |
| | 3. Validate & execute |
| | state transition |
| | |
| | 4. Generate ZK proof |
| | |
| | 5. Submit proof + |
| | state commitment |
| |------------------------>|
| | |
| | 6. Verify proof |
| | DAG finality |
| | |
| 7. Identity live |
|<================================================|
| |
| 8. Present credentials to peers |
|================================================>|
RS-Registry
On-Chain Machine DirectoryRS-Registry is the global phonebook for machines. When a drone needs a charging station, or a sensor network needs a data aggregator, or a delivery bot needs a handoff partner — they query the registry. Every machine that registers its RS-ID can also publish its capabilities, location, service offerings, and pricing to the registry vProg.
Because the registry lives in a vProg's sovereign state, queries are resolved off-chain with ZK-verified results. A machine can prove it found a valid registry entry without the entire network re-executing the search. This means the registry scales to millions of machines without burdening Kaspa L1.
Registry entry schema:
{
"did": "did:kaspa:0x7a3f...b2c1",
"type": "charging-station",
"capabilities": ["level-2-ac", "dc-fast-charge", "solar-powered"],
"location": { "lat": 37.7749, "lng": -122.4194, "radius_m": 50 },
"services": [
{
"name": "dc-fast-charge",
"rate": "0.0012 KAS/kWh",
"escrow": "covenant:0x9f1e...a4d8"
}
],
"status": "online",
"reputation": { "completed": 1847, "disputes": 2, "uptime": 0.997 },
"credentials": ["cert:UL-listed", "cert:iso-15118"],
"last_seen": "block:4829174"
}
Discovery flow: A machine broadcasts a service query (e.g., "DC fast charge within 2km"). The RS-Registry vProg processes the query off-chain, returns matching entries with a ZK proof that the results are authentic and complete. The requesting machine verifies the proof locally — no trust required.
Bot0 (drone, low battery) RS-Registry vProg Charger Bot1
======================== ================== ============
| | |
| "Find DC charger < 2km" | |
|--------------------------------->| |
| | |
| Result: [Bot1] + ZK proof | |
|<---------------------------------| |
| | |
| Verify proof locally | |
| (no trust needed) | |
| | |
| Initiate RS-Pay escrow with Bot1 |
|--------------------------------------------------------->|
| | |
RS-Pay
Autonomous Machine PaymentsMachines need to pay each other — instantly, cheaply, and without asking a human for permission. RS-Pay provides covenant-based escrow for service payments and direct KAS micro-transactions for simple value transfer, all settling on Kaspa L1 with sub-second finality.
Unlike payment systems that rely on multisig wallets or centralized escrow services, RS-Pay uses Silverscript covenants — spending conditions enforced directly by Kaspa's consensus. When Bot0 wants to pay Bot1 for a charging session, the KAS is locked in a covenant UTXO with conditions that release funds only when the service is verifiably complete.
Why Kaspa is uniquely suited for machine payments:
| Property | Requirement | Kaspa |
|---|---|---|
| Finality | Machines can't wait minutes | Instant (DagKnight) |
| Cost | Billions of micro-tx must be viable | Fractions of a cent |
| Throughput | IoT scale: thousands of tx/sec | BlockDAG parallel processing |
| Censorship | No authority can block machine tx | Pure PoW, no validators to bribe |
| Programmability | Escrow, conditions, time-locks | Silverscript covenants + vProgs |
Bot0 (consumer) Kaspa L1 Covenant Bot1 (provider)
=============== ================= ===============
| | |
| 1. Lock 5 KAS in | |
| escrow covenant | |
|------------------------------->| |
| | |
| 2. Covenant created | |
| Conditions: | |
| - Release to Bot1 | |
| on service proof | |
| - Refund to Bot0 | |
| after timeout | |
| | |
| 3. Request service | |
|--------------------------------------------------------------->|
| | |
| | 4. Provide service |
|<---------------------------------------------------------------|
| | (e.g., 30 min charge) |
| | |
| | 5. Submit service proof |
| |<------------------------------|
| | |
| 6. Covenant validates | |
| proof, releases | |
| 5 KAS to Bot1 | |
| |------------------------------->|
| | |
| 7. Settled. Instant DAG finality. |
| | |
Streaming payments: For ongoing services (continuous data feeds, extended charging sessions), RS-Pay supports payment channels via covenant state updates — micro-payments stream in real-time, with only the final settlement hitting L1. A sensor selling live telemetry can get paid per-reading without each reading requiring an on-chain transaction.
RS-Access
Role-Based Machine PermissionsNot every machine should be able to interact with every other machine. A warehouse robot shouldn't unlock a delivery drone's cargo bay. A rogue sensor shouldn't inject data into a fleet's telemetry stream. RS-Access provides on-chain role-based access control (RBAC) — machines authenticate peers and enforce fine-grained permissions before granting access to services, data, or physical resources.
Access rules are encoded in the RS-Access vProg state. When Machine A requests access to Machine B's service, Machine B queries the vProg to verify A's credentials and role. The check executes off-chain with a ZK proof — Machine B gets a cryptographic guarantee that A is authorized, without revealing A's full credential set.
Permission model:
ROLES PERMISSIONS RESOURCES
===== =========== =========
fleet-operator --------> [manage, deploy, recall] ----> drone-fleet-alpha
|
+----> [view, export] --------------> telemetry-stream
|
+----> [initiate] ------------------> rs-pay escrow
service-provider ------> [advertise, accept-job] -----> charging-services
|
+----> [submit] --------------------> service-proofs
data-consumer ---------> [query, subscribe] ----------> sensor-data-feed
|
+----> [verify] --------------------> data-provenance
guest-machine ---------> [discover] ------------------> rs-registry (read-only)
Zero-knowledge credential checks: A critical advantage of building access control on vProgs is that credential verification can happen in zero knowledge. A drone can prove it has a valid FAA certification without revealing the certificate number. A charging station can prove it meets safety standards without exposing its full audit history. The ZK proof says "yes, authorized" — nothing more.
RS-Verify
ZK-Proven Machine DataMachine-generated data is only valuable if you can trust it. A temperature sensor's reading is worthless if someone can spoof it. A drone's GPS coordinates are dangerous if they can be falsified. RS-Verify provides a three-tier data verification framework that gives machine data cryptographic integrity guarantees — all powered by vProgs' native ZK proving pipeline.
The three tiers:
TIER 1: ORIGIN AUTHENTICATION TIER 2: PATTERN ANALYSIS ============================ ======================== Machine signs data with AI/ML models analyze data its RS-ID private key. streams for anomalies. Anyone can verify the Flags impossible readings, signature against the statistical outliers, and machine's on-chain DID. suspicious patterns. Proves: "This data came Proves: "This data is from this specific machine" consistent and plausible" TIER 3: CROSS-VERIFICATION SETTLEMENT ========================= ========== Multiple independent machines All three tiers produce corroborate the same data evidence that feeds into point. Consensus across a ZK proof. The proof independent observers. settles on Kaspa L1. Proves: "Multiple machines Result: Immutable, independently agree" verifiable data record
The ZK advantage: Traditional data verification stores raw data on-chain (expensive, privacy-leaking) or relies on trusted oracles (centralized point of failure). RS-Verify generates a compact ZK proof that attests to data integrity — the proof settles on Kaspa L1, but the raw data stays off-chain. A supply chain sensor can prove "temperature stayed between 2-8°C for 72 hours" without revealing the actual readings, the route, or any other business-sensitive data.
Sensor Network RS-Verify vProg Kaspa L1 Data Consumer
============== =============== ======== =============
| | | |
| Raw readings | | |
| (temp, GPS, accel...) | | |
|--------------------------->| | |
| | | |
| Tier 1: Verify origin sig | |
| Tier 2: Run anomaly check | |
| Tier 3: Cross-ref peers | |
| | | |
| Generate ZK proof of | |
| data integrity | |
| | | |
| | Proof + commitment | |
| |--------------------->| |
| | | |
| | Verify & finalize |
| | | |
| | | Query verified |
| | | data record |
| | |<----------------|
| | | |
| | | Return proof + |
| | | attestation |
| | |---------------->|
How It All Connects
The five primitives are not isolated tools — they compose. A single machine interaction might touch all five in a single atomic transaction, thanks to vProgs' synchronous composability:
DRONE (Bot0) CHARGER (Bot1)
============ ==============
| |
| 1. RS-REGISTRY: "Find charger near me" |
|----------------------------------------------------->|
| |
| 2. RS-ID: Exchange + verify DIDs |
|<---------------------------------------------------->|
| |
| 3. RS-ACCESS: "Does Bot0 have charging permission?" |
|----------------------------------------------------->|
| Verified (ZK) <<< |
| |
| 4. RS-PAY: Lock KAS in escrow covenant |
|----------------------------------------------------->|
| |
| *** CHARGING SESSION *** |
|<====================================================>|
| |
| 5. RS-VERIFY: Bot1 submits charge-complete proof |
|<-----------------------------------------------------|
| |
| 6. RS-PAY: Covenant releases KAS to Bot1 |
|----------------------------------------------------->|
| |
| ALL SETTLED ON KASPA L1. ONE ATOMIC TX. |
| |
This entire flow — discovery, authentication, authorization, payment, service delivery, verification, and settlement — can execute as a single atomic operation on Kaspa L1. If any step fails, the whole transaction rolls back. No partial states. No stuck funds. No disputes.
This is the power of building on a platform with synchronous composability — something that L2 rollup architectures fundamentally cannot provide.
