In my last piece I followed the power bill of physical AI. Energy is what it costs to give a model a body. Identity is the next cost, and it is quieter. Once bodies are everywhere, someone will ask a simple question: which robot was that, who built it, and who answers for it?
The scale of the question is already visible. China’s industry ministry said in July that the country has developed more than 400 humanoid robot models, over half of the global total. In the US, the FCC added foreign-produced advanced robotic devices (defined as mobile robots, such as humanoids and quadrupeds) to its Covered List on July 28, which blocks new models from equipment authorization unless they get conditional approval. Two large markets, two regimes, and both will eventually need a way to say which machine is which.
This is a design proposal, not a finished system. I have tried to separate what is documented from what is my own judgment, and I flag where a source is secondary or a standard is still in draft.
What ERC-8004 gives a robot, and what it does not
The obvious starting point is ERC-8004, the “Trustless Agents” proposal authored by people from MetaMask, the Ethereum Foundation, Google and Coinbase. It defines three registries: identity, reputation and validation. The identity registry is an ERC-721 token whose URI points to a registration file listing the agent’s endpoints (MCP, A2A, ENS names, DIDs). Whoever owns the token owns the agent and can transfer it. Explorers such as 8004scan.io already index these agents.
A status check matters here. The spec is still marked Draft on the EIP site, even though registries are deployed on mainnet and other networks. Draft means it can still change.
For robots, three limits stand out
First, it was written for software agents. The text is built around MCP and A2A endpoints, nothing in it addresses physical hardware, and its own security section says it cannot prove that advertised capabilities work or are safe.
Second, registration is open. The spec describes no admission control, and it lists Sybil attacks among its known risks.
Third, a token shows who controls a key, not which body that key is attached to. If anyone can mint a token for any robot, or move it to another one, the token tells you little about the metal.
My earlier work on NFT valuation offers a useful lens here. I co-authored a 2022 paper on scoring NFTs and revisited it this year. It split value into liquidity, utility and rarity. In that revisit I proposed a fourth axis: how dependent the token’s utility is on one company staying alive. Apply that to a robot token. Liquidity and rarity hardly matter. Utility is everything, and the fourth axis bites hard: if a token’s meaning depends on one manufacturer’s server, it is a promise, not an identity.
ERC-8217, an early, single-author Draft created in April 2026, tries to bind ERC-8004 agents to external NFTs, so that the owner of a master NFT controls the bound registration. That is a useful pattern for ownership. It still does not bind anything to a body.
Robots are not tokensThe attacker owns the hardware
Robots differ from cloud agents in one way that matters for security: the person holding the device may be the adversary.
Hardware roots of trust are the standard answer, so look at how they are holding up. A poster at IEEE S&P 2026 reports extracting attestation keys from SGX and TDX machines that still showed a fully trusted, up-to-date attestation status. A separate research agenda argues that current TEEs are not secure against physical attacks and that their attestation rests on trust in the chip manufacturer.
I am not claiming that robot secure elements have been broken the same way. Those are server-class chips, and a robot would use different hardware. The point is structural: when the attacker can touch the device, “the key is in hardware” is a cost barrier, not a guarantee.
Research is exploring alternatives. One proposal, Janus, adds a physically unclonable function as a second, intrinsic root of trust to reduce reliance on the chip manufacturer. Another paper pairs DIDs with PUFs for delivery robots, and its authors report a formal security proof.
The design consequence is simple. Hardware keys are necessary and not sufficient. Assume some keys will eventually be extracted, and build revocation, multi-party attestation and behavioral reputation around that assumption.
Robots can be openedPrior art: people are already building this
None of this starts from zero.
OpenMind’s FABRIC is a protocol that lets robots verify identity and share context. A BlockEden review of its design describes a secure hardware element holding a private key, with the public key stored on-chain next to the manufacturer, and a challenge-response check on top. The same review calls the integration early-stage. In a post with Symbiotic, collateral from a manufacturer’s vault can be slashed when a robot is found at fault. That post also concedes that today the system works like a security camera recording what a robot claims it did, and you still have to trust that the robot is not lying.
IoTeX’s ioID offers a registry for machines with a smart wallet per machine. RoboComm uses DIDs and verifiable credentials for robot-to-robot authentication, with state channels to cope with blockchain throughput, and it keeps private data in the robot’s hardware instead of on-chain. A workshop at the 2026 Protocol Symposium teaches registering a robot’s on-chain identity with ERC-8004 and driving it over MCP.
What most of these lack is a governance answer: who may write to the registry, and what happens on transfer, repair and bankruptcy. That is the gap my proposal tries to fill.
A proposal: layers, not a token
Here is the design in one table. The structure is my own proposal, assembled from the pieces above.
|
Layer |
Job |
Who writes |
What is public |
|---|---|---|---|
|
0. Hardware root |
Key generated and kept inside the device (secure element or PUF-derived) |
Manufacturer at build time |
Public key only |
|
1. Issuer ledger |
Attestation that this key belongs to a robot built by this manufacturer; status and revocation |
Vetted manufacturers only (permissioned) |
Minimal fields: ID, issuer, status |
|
2. Ownership and transfer |
Links a robot to an owner; transfers need the owner’s signature plus an issuer co-signature |
Owner and issuer |
Commitments or credentials, not names |
|
3. Accountability |
Collateral held by issuers; slashing on proven faults; revocation |
Issuers and auditors |
Events |
|
4. Discovery and reputation |
An ERC-8004 entry pointing to the root; feedback and validation signals |
Anyone, filtered by reviewer |
Public |
An NFT view can sit on top through a pattern like ERC-8217. It is a receipt for ownership, not the identity itself.
Why a permissioned ledger. If anyone can write, you inherit the Sybil problem. If only vetted manufacturers write, each record has an accountable author. Reading stays public so that anyone, from an inspector to another robot, can check a claim.
Why not just certificates? The closest precedent is Certificate Transparency. Its append-only logs do not prevent misissuance, but they let interested parties detect it, which is the property I want for robots. RFC 9162 is still labeled Experimental. So a CT-style log with consortium signing might be enough for layer 1, and “blockchain” is a label rather than a requirement. My argument for consensus among manufacturers is that no single operator should hold the pen and that ownership states need an agreed order. That is an argument, not a proven necessity.
Privacy. Public read has to stay small: robot ID, issuer, status. Who owns the robot is a different matter. The W3C Verifiable Credentials data model lets a holder show a claim to a verifier without publishing it, and it includes examples with privacy-enhancing techniques such as zero-knowledge proofs. It also reminds readers that a verifiable credential proves authenticity, not that its claims are true.
Transfers and small makers. A sale, a repair that swaps the main board, a robot rebuilt from parts: each needs a rule. Owner signature plus a co-signature from any admitted issuer, not necessarily the original manufacturer, covers a sale. For independent and DIY builders, a self-registered tier with lower, clearly stated trust keeps the system from becoming a manufacturers’ club.
What can still go wrong
- A compromised issuer. One breached manufacturer can attest to fake robots. Mitigations are audits, fast revocation and collateral, and none of them is free.
- Capture. Whoever decides which manufacturers are admitted holds real power. Admission rules would have to be public and contestable.
- The oracle gap. The ledger can record a claim. It cannot, by itself, verify what a robot did in a room. FABRIC’s own partners say as much.
- Bankruptcy. Records must outlive the manufacturer. That needs succession rules, which is my fourth NFT axis again.
- Physical extraction. Treat it as a matter of when, not whether, and plan revocation accordingly.
- Regulation. Europe is raising the bar regardless. The EU Machinery Regulation applies from January 20, 2027. The Cyber Resilience Act’s reporting duties for actively exploited vulnerabilities and severe incidents began on September 11, 2026, with full application on December 11, 2027. The new Product Liability Directive covers products placed on the market or put into service after December 9, 2026. An identity layer does not discharge these obligations. It can support the traceability they imply: which unit, which build, which software state.
The part nobody controls: who runs the roots?
Technology is the easy half. Someone has to decide whose manufacturers sit on the ledger.
The two largest robot markets are already diverging. The FCC action covers advanced robotic devices produced in foreign countries. The agency says it does not affect devices already purchased or models it authorized earlier, and that the restrictions apply to new device models. China released its first standards framework for humanoids and embodied AI on February 28, and its ministry has floated at least 100 standards by 2028.
Can two such powers share a single robot identity ledger? In my view, not in the near term. A realistic model is federated, and the working precedent is passports. Each state issues its own ePassports and signs them with its own keys. ICAO’s Public Key Directory is a neutral place, hosted at ICAO headquarters and funded by participants, where those public keys are published so border officials can verify them.
The lesson is encouraging and sobering. Joining is voluntary: ICAO’s guidance says states “should” join, and at its 40th Assembly the directory had 66 participants and ICAO was still urging more states to join. Mutual recognition can work without a world government, but only where participants gain from being checkable.
For robots, the shared interests might be tracing incidents, running recalls and moving machines across borders. Whether the US and China would see those interests as aligned is an open question. A binding human-rights-style baseline that every country must accept would be the stronger tool on paper, but enforcement is its weak point, and even the passport directory depends on voluntary uptake. A minimal federated layer, exchanging public keys and revocation lists and leaving everything else to each jurisdiction, looks more survivable.
Robots need shared rootsLimits of this article
ERC-8004 and ERC-8217 are Drafts. The Machinery Regulation date comes from EUR-Lex. The Cyber Resilience Act and Product Liability Directive dates come from a legal reading aid and a law-firm summary, so check them against EUR-Lex before relying on them. FABRIC’s design is described through third-party analysis. I have not built or tested this proposal, and the layered design is my own synthesis.
What would change my mind: evidence that issuer attestations cannot resist key extraction at realistic cost, a manufacturers’ group that cannot agree on admission rules, or a CT-style log that proves sufficient with no chain at all.
Conclusion
An NFT is a receipt, not a passport. In my last article I argued that making a body is the hard part. Proving which body it is turns out to be the next hard part: a key in hardware, a vetted author for every record, an owner who can move the robot without asking permission from a single company, and roots that countries can recognize without trusting each other completely.
The standards for software agents are a good start. Physical machines will need more, and the interesting work is in the layers between the chip and the registry.
