Hi everyone,
Onchain ID is designed as a programmable and interoperable identity layer, not a naming service alone. Each identity (e.g. unit-01.robot-id.eth) is an onchain reference that can be programmatically associated with permissions, roles, or behaviors via smart contracts, while remaining interoperable across different systems that already understand ENS and Ethereum. The goal is to enable robots, devices, and fleets to carry a consistent onchain identity that can be referenced by OEM software, infrastructure, or third-party services without tight coupling.
I wanted to sanity-check with the ROS community before taking it any further.
Problem I’m thinking about:
In multi-vendor, multi-fleet environments, robots are usually identified by hostnames, UUIDs, or vendor-specific IDs that don’t translate well across organizations, clouds, or lifecycles.
I’m experimenting with using ENS-style hierarchical names (e.g. unit-42.robot-id.eth) purely as an identity layer:
-
Not a wallet
-
Not custody
-
Not payments
-
Just a globally resolvable, programmable identifier anchored on Ethereum
The goal would be:
-
Stable robot / device / fleet identifiers
-
Verifiable ownership & delegation
-
Interoperability across vendors and tooling
-
Optional policy hooks (who can issue, rotate, revoke identities)
Key question for the community:
If something like this were to exist, where would it make sense (if at all) to integrate in the ROS ecosystem?
Examples I’m considering:
-
Configuration / discovery layers
-
Fleet management systems
-
Security / authorization contexts
-
Or nowhere at all (happy to hear “this doesn’t belong in ROS”)
I’m intentionally posting early to get feedback before building assumptions into tooling or workflows.
Appreciate any thoughts, critiques, or pointers to existing work I may have missed.
–Hector