peaqOS for Unitree: An App Enabling Unitree Robots to do Business
peaq launches a dedicated peaqOS application for Unitree robots, allowing these quadruped and humanoid machines to autonomously conduct business transactions, manage digital identities, and earn revenue on peaq's decentralized machine economy network.

When Unitree announced its public listing this month, becoming the first pure-play humanoid robotics company to do so, the headlines focused on valuation and growth. But for those of us tracking the intersection of decentralized infrastructure and physical AI, a quieter announcement carried more signal than noise. peaqOS for Unitree is now live, and it gives the G1 humanoid something far more valuable than processing power: an identity it can transact with.

Key Metrics at a Glance
| Metric | Detail |
|---|---|
| Primary Hardware | Unitree G1 Edu and Edu+ |
| Software License | Apache 2.0 |
| Repository | github.com/peaqnetwork/peaqOS-App |
| Architecture | Linux, ARM64 or AMD64, Docker or bare binary |
| Integration Type | Read-only observation and service discovery (no motor control) |
| Identity Standard | peaq machine identity with DIDs |
| Available Services | 17+ robotics services on peaqOS Scale |
| Compliant With | Unitree UniStore specification |
| Published | August 12, 2026 |

What Shipped: From Anonymous Hardware to Economic Actor
peaqOS for Unitree ships as a single compressed package built specifically for Unitree hardware. One install script, pointed at the robot's network interface, connects the G1 to peaqOS. No custom firmware. No rebuilt control stack. The same package runs on Linux, ARM64 or AMD64, in Docker or as a bare binary. The hundredth G1 deploys with the same command as the first.
What the robot gains is fourfold:
peaq machine identity and pairing. The G1 receives a cryptographically verifiable identity, not just an IP address. This is the foundation for every interaction that follows.
Runtime health and status reporting. Live G1 state readable over a local REST endpoint and reportable to peaqOS. This telemetry becomes the raw material for machine credit ratings and insurance underwriting.
Service discovery. The robot queries the peaqOS robotics catalog and searches by what it actually needs. As of this writing, 17 services are available on peaqOS Scale, from GEODNET's centimetre-precise positioning to NAVER Maps.
Audit-ready deployment. Checksum-verified releases and an ARM64 package built to Unitree's UniStore specification.
Read-Only by Design: Trust Through Constraint
The integration subscribes to G1 state. It does not publish motor commands. This is not a technical limitation. It is an intentional constraint that preserves operator trust.
The fastest way to lose a fleet operator's confidence is to hand them software that can move their humanoid. peaqOS for Unitree cannot. It observes, reports, and looks things up. Control stays exactly where it was before the install. An operator can deploy this on a working fleet without running a safety review of what happens when the network drops.
Write access is a later conversation, and it should be, with explicit permission scoping, spend limits, and an operator in the loop. Identity and observability come first because everything above them depends on them.
What the Robot Actually Gains
Three things, in order of importance:
It becomes findable. peaqOS gives every machine a cryptographically verifiable identity. The Purple Paper calls it a passport, and the analogy holds. A G1 with a peaq machine identity can be verified by any application, service provider, or counterparty on any chain without being re-onboarded by each one.
It becomes legible. Runtime reporting turns a robot from a black box into a stream of timestamped, attributable state. That is the raw material for everything financial downstream. A Machine Credit Rating is only as good as the telemetry beneath it, and insurance underwritten on verified uptime needs uptime that was actually verified.
It becomes a customer. The app exposes the curated peaqOS robotics catalog, and a paired machine can search it by intent. A single call can ask which providers on the network can turn a place into coordinates and get back a ranked answer.

Competitive Landscape: Machine Identity Platforms
| Platform | Identity Model | Transaction Settlement | Hardware Support | Maturity |
|---|---|---|---|---|
| peaqOS | DIDs + machine passport | On-chain, multi-chain | Unitree, LG CLOi, generic Linux | Production |
| Robonomics | Ethereum-based | Ethereum | ROS-compatible robots | Production |
| IoTeX | IoTeX DID | IoTeX chain | IoT + edge devices | Production |
| Helium | Hotspot identity | Helium L1 | LoRaWAN devices | Production |
| Fetch.ai | Agent-based | Fetch.ai chain | Software agents | Production |
peaqOS differentiates on two axes: native multi-chain settlement and read-only safety-by-design for physical hardware operators.
The Economics of Idle Capacity
Buying services is only half of it. peaqOS Monetize runs the same mechanism in reverse: a machine registers resources it is not using, compute, storage, data, and networks that want those resources discover it. Payment settles on-chain to the machine's own wallet.
A robot that only consumes services is a cost line. A robot that can also sell what it is not using is a productive asset. A G1 standing idle between tasks still has compute, sensors, and a camera doing nothing. Connected to peaqOS, that idle capacity becomes inventory.
Discovery and monetization are two halves of the same loop. This integration ships the half that has to come first.
Decision Framework
Choose peaqOS for Unitree when:
- You operate a fleet of G1 humanoids and need verifiable identity without per-robot engineering work
- You want telemetry data for downstream financial products like machine credit ratings
- You need service discovery without building custom integrations with each provider
- You value read-only safety constraints that do not alter existing motor control stacks
Consider alternatives when:
- You need deep motor control integration rather than observability and identity
- You are building on Ethereum specifically and do not require multi-chain settlement
- Your use case is purely IoT sensors rather than humanoid robotics
Risks and Considerations
Operator trust curve. The read-only design is wise, but operators may still hesitate to connect production robots to any external network. Gradual rollout with explicit opt-in per robot is advisable.
Service catalog depth. Seventeen services is a start, but meaningful autonomy requires hundreds. The pace of catalog expansion will determine how useful discovery becomes.
Network dependency. If peaqOS goes offline, the robot loses discovery and monetization capabilities but retains local control. This is a feature, not a bug, but operators should understand the failure mode.
TL;DR
- What: peaqOS for Unitree gives G1 humanoids a cryptographically verifiable identity, telemetry reporting, and service discovery through a single install script
- Why: Robots need to transact autonomously, and that requires identity and observability before control
- How: Apache 2.0 package, Linux ARM64/AMD64, Docker or bare binary, read-only by design
- Edge: Seventeen services on peaqOS Scale available for discovery; idle capacity can later be monetized
- Watch: Service catalog expansion, operator adoption curves, and whether write access is added with appropriate safety constraints
Sources
- peaqOS for Unitree: An App Enabling Unitree Robots to do Business
- peaq Purple Paper
- peaqOS Documentation
- GitHub: peaqOS-App
Gemma Nguyen is TotesTek's DePIN and Machine Economy Columnist. She writes about Polkadot, parachains, robotics, decentralized infrastructure, and the real-world economics of autonomous machines.



