DEV Community

Cover image for A Robot Dog Just Paid for Its Own Electricity. That's Why I Built a Payment Protocol for Robots.
Mr Hamlin
Mr Hamlin

Posted on

A Robot Dog Just Paid for Its Own Electricity. That's Why I Built a Payment Protocol for Robots.

#depin #robotics #ai #x402

In February 2026, a robot dog named Bits found a charging station, plugged itself in, and paid for electricity with USDC. No human touched anything.

OpenMind and Circle built a custom integration for this demo — real-time perception, autonomous decision-making, physical manipulation, smart contract execution. It was impressive. Jeremy Allaire called it "a glimpse into a future where machines and AI agents can transact with each other without human intervention."

I watched that demo and thought: that's exactly right, but it shouldn't require a custom integration every time.

The Problem Nobody's Solving

The robot economy is heating up. Peaq has 6 million machine addresses on its L1. Frodobots is deploying delivery robots worldwide through DePIN. Hivemapper drivers are mapping roads for autonomous vehicles. GEODNET has 20,000 stations providing centimeter-level GPS correction for drones and self-driving cars. McKinsey projects up to $1 trillion in agentic commerce by 2030 in the US alone.

But here's what I kept running into: every project is building its own payment plumbing from scratch.

If a warehouse robot needs to pay for a charging session, someone writes a custom smart contract. If a drone fleet wants to buy real-time weather data from a sensor network, someone builds a bespoke API integration. If an AI agent wants to hire a physical robot to pick an item off a shelf, there's no standard way to do it.

We have DePIN for infrastructure. We have AI agent frameworks for reasoning. We have x402 for machine payments. But there's no protocol that connects an AI agent's intent — "I need a robot to do this task" — to a physical robot's execution and payment settlement.

That gap is what I've been building into.

What I Actually Built

I created the Robot Task Protocol (RTP) — an open standard for AI agents to discover, commission, and pay for physical robot tasks using x402 micropayments.

It lives inside Spraay's x402 gateway, which already has 70 pay-per-call endpoints for things like AI inference, batch payments, and token swaps. RTP adds 6 live endpoints specifically for robotics:

Register — A robot operator registers their device with capabilities (pick, place, scan, deliver), pricing in USDC, and a connection method (webhook, XMTP, WebSocket). Registration is free.

Discover — An AI agent searches for available robots filtered by capability, location, price, and status. Costs $0.005.

Dispatch — The agent pays x402 to send a task. Payment goes into escrow automatically. Costs $0.05.

Complete — The robot reports back. If successful, escrow releases to the operator. If failed, it refunds to the agent. Free to call.

Status — Poll the task lifecycle: PENDING → DISPATCHED → IN_PROGRESS → COMPLETED → FAILED → TIMEOUT. Costs $0.002.

Profile — Pull a robot's full capability sheet, pricing, and connection details. Costs $0.002.

The whole thing runs on the same x402 flow as every other Spraay endpoint: send a request, get a 402 with pricing, pay USDC on Base, get your result. An AI agent that already knows how to call an x402 API can hire a robot without learning anything new.

Why x402 and Not a Custom Token

This was a deliberate choice. The DePIN space is full of projects that launch a token before they launch a product. I went the other direction.

RTP settles in USDC on Base. Here's why:

Robots don't speculate. A warehouse robot doesn't care about token price appreciation. It needs to know that the $0.05 it charges per task will still be worth $0.05 when the operator withdraws it. Stablecoins solve this.

Agents are already on x402. With Stripe, Cloudflare, and Google all backing x402, AI agents are going to have x402 wallets. If a robot operator wants to tap into that demand, they should accept the same payment rail those agents already use.

Micropayments need cheap gas. A $0.05 robot task doesn't work if gas costs $2. Base gives you sub-cent transactions. The math works.

Interoperability over lock-in. If I built an RTP token, every robot operator would need to acquire that token before they could participate. With USDC on x402, any agent with a wallet can hire any robot immediately. The network effect compounds faster without a token gate.

The Scenario I Keep Coming Back To

Here's the use case that motivated everything:

A logistics company runs a warehouse with 20 robotic arms from three different manufacturers. An AI operations agent monitors incoming orders. When a pick-and-pack task comes in, the agent:

  1. Queries RTP to discover which robots are online and capable of "pick"
  2. Compares pricing across available robots (some charge $0.03, others $0.08 for heavier items)
  3. Dispatches the task to the cheapest qualified robot
  4. Monitors the task status
  5. On completion, escrow releases payment to the robot operator

No integration between manufacturers needed. No centralized dispatch system. The AI agent is the coordinator, and RTP is the protocol it coordinates through.

Now scale that across facilities. Across companies. Across countries. A robot operator in Shenzhen can register their fleet on RTP tonight and start receiving tasks from AI agents anywhere in the world tomorrow.

Where This Intersects With DePIN

The DePIN ecosystem is building the physical infrastructure layer — sensors, compute nodes, wireless hotspots, GPS stations. RTP sits on top of that layer as the task and payment coordination protocol for machines that do physical work.

Think of it this way:

  • Peaq provides machine identity (who is this robot?)
  • Auki provides spatial computing (where is this robot?)
  • RTP provides task coordination and payment (what should this robot do, and how does it get paid?)

These aren't competing layers. They're complementary. A robot registered on Peaq with spatial awareness from Auki can receive and settle tasks through RTP. The payment happens in USDC via x402, settling on Base in seconds.

I proposed RTP as a formal x402 extension in issue #1569 on the Coinbase x402 repo. The full spec is open source at github.com/plagtech/rtp-spec.

What's Working, What's Not

I'll be honest about where things stand.

Working:

  • All 6 RTP endpoints are live on Spraay's gateway
  • TypeScript SDK and Python SDK are published
  • A Raspberry Pi demo exists for prototyping hardware integration
  • XMTP mesh implementation works for robot-to-robot communication
  • The community registry is live for discovering robots

Not there yet:

  • Real robots haven't registered on the protocol in production. The endpoints are live, the spec is published, but I'm a solo developer — I don't have a warehouse full of robotic arms. This needs hardware partners.
  • The escrow is functional but hasn't been battle-tested at scale with real device failures and timeout edge cases.
  • Connection methods beyond webhooks (XMTP, WebSocket, direct WiFi) need more real-world testing.

I built the protocol. Now it needs robots.

If You're Building in DePIN or Robotics

RTP is designed to be picked up and used. The spec is open. The endpoints are live. Registration is free.

If you operate robots, drones, or any DePIN device that performs physical tasks, you can register on RTP today and start receiving paid tasks from AI agents. The bar is intentionally low — a webhook endpoint and a USDC wallet on Base.

If you're building AI agents that need to interact with the physical world, RTP gives you a standard discovery and dispatch interface that works across any registered device, regardless of manufacturer.

The robot economy doesn't need another token. It needs a payment protocol. That's what I'm building.

Links:

This is post 8 in a series about building x402 infrastructure. Previous posts cover the Spraay gateway, XMTP robot mesh networking, and RTP fundamentals.

Top comments (0)