Cryptographic identity
The private key is generated inside the robot and never leaves it. The passport anchors only the public key, so possession can be tested at any time.
Identity infrastructure for civil robots and drones
Every robot and drone carries a passport.
The manufacturer issues it once at the end of the line. The machine proves it holds the matching private key. Anyone can then check what that machine is, what it may do, and whether it is under a recall — without trusting a sticker on the chassis.
MIRA 1.0Passport schema
Robots & dronesTwo classes, one record
Ed25519 / P-256Machine identity key
Hash-chainedLifecycle ledger
Capability transparency
Standard codes state what the machine can do, how close it works to people, and what happens when it fails safe.
Recalls that travel
Suspensions, recalls and decommissioning are signed events on the passport, so a grounded machine reads as grounded everywhere.
Two machine classes, one registry
Robots and dronesA ground robot and an aircraft are different machines with different failure modes, so they do not get asked the same questions. They do share one passport format, one identity key, one event ledger and one set of verification steps — which is the point. A site that already checks its floor robots does not learn a second system to check the drone that surveys its roof.
Robots
Ground and fixed machines: humanoids, arms, service and warehouse platforms, agricultural and construction equipment, inspection crawlers.
Declares in addition: whether it is statically stable or dynamically balanced, what it does when it loses balance, the terrain it is authorised for, and how close it may work to people. A legged machine that can fall over near a walkway is a different proposition from a bolted-down arm in a cage, and the passport says which it is.
Drones
Civil unmanned aircraft: multirotor and fixed-wing survey, inspection, delivery, agricultural, mapping and cinematography airframes.
Declares in addition: airframe type, take-off mass in grams, the manufacturer serial in ANSI/CTA-2063-A form, which Remote ID method it broadcasts, what it does when the control link drops, and whether it carries a recovery system. Mass and link-loss behaviour are what decide where an aircraft may legally fly.
What they share
Everything that makes the passport worth holding.
The same manufacturer signature, the same hashed serial, the same challenge-response proof of key possession, the same hash-linked event history, and the same recall behaviour. A grounding order on an aircraft and a recall on a robot are the same kind of signed record, so one verifier reads both.
How a passport is created and used
Sequence01
Enroll
The manufacturer submits the build record. Only its hash reaches the registry — the serial number is never published in the clear.
02
Bind key
The machine generates a key pair in its own secure hardware and exports only the public half. The private key never leaves it.
03
Publish
The genesis transaction is written to the chain, and the passport ID becomes that machine's permanent name.
04
Challenge
Any verifier sends a one-time nonce. Only the machine holding the matching private key can return a valid signature.
What this page does
Nothing is mockedReal key pairs
Enrollment generates a genuine Ed25519 or P-256 key pair in your browser using WebCrypto. The private half stays in the tab.
Real challenge-response
Verification signs a random nonce and checks it against the public key on the passport. Alter either and the check fails.
Real hash chain
Every lifecycle event is SHA-256 linked to the one before it. Break a link deliberately and the page reports which record was altered.
Manufacturer portal
Initial machine enrollment
Build a MIRA 1.0 genesis record. The passport preview on the right updates as you type.
Public verification
Verify a machine passport
Look up the passport, then challenge the machine to prove it holds the matching private key. The same two steps work for a warehouse robot and for a survey aircraft.
Public ledger
Passport registry
Every passport published to the public domain, robots and drones together, including ones you enroll.
| Passport ID | Class | Model | Manufacturer | Category | Hazard | Status |
|---|
Select a row to open the passport and its lifecycle ledger.
Signed event history
Lifecycle ledger
Ownership, firmware, inspections and recalls are appended as hash-linked events. Break one and every later link fails.
Protocol architecture
One schema. Two machine classes. Four security domains.
A civil registry for robots and drones. Weapons systems and military platforms are out of scope and rejected at enrollment.
Public
Civilian machines, revocations and safety status, readable by anyone.
Enterprise
Permissioned fleet, maintenance and ownership records on the same schema.
Civil government
Transit, utilities, postal and municipal fleets. Independently operated, own validators.
Restricted
Commercially sensitive civil fleets on isolated infrastructure. No public anchor.
MIRA 1.0 record fields
Two classes, one record
A passport carries machine_class, which is either robot or drone. The class decides which fields the enrollment form asks for and which ones a verifier should expect to find. It does not fork the schema.
Robots add: stability class, behaviour on loss of balance, terrain authority, mass in kilograms, and a human-contact class.
Drones add: airframe type, rotor count, maximum take-off mass in grams, maximum altitude, endurance, geofencing, behaviour on control-link loss, recovery system, Remote ID equipment and which identifier it broadcasts.
Everything else — identity key, hashed serial, capabilities, hazard level, fail-safe state, marking, disclosure, events — is common. One verifier implementation reads both classes, which is the whole reason for keeping them in one registry.
The aviation boundary
MIRA is not an aviation authority and does not act as one. A passport is the manufacturer's signed declaration of what an aircraft is. It is not a registration, not an airworthiness approval, and not evidence of Remote ID compliance.
Those remain with the civil aviation authority in the jurisdiction of operation. MIRA is deliberately placed upstream of them: under 14 CFR § 89.505 a producer of a standard Remote ID unmanned aircraft must already assign an ANSI/CTA-2063-A serial number, which means the manufacturer-issued identity MIRA depends on is an obligation that exists in law rather than a convention this registry invented.
What MIRA adds is testability. A registered serial identifies an aircraft on paper. A MIRA passport lets an inspector challenge the airframe in front of them and get a cryptographic answer.
How the serial is handled
Serial numbers are commercially sensitive — a run of them discloses production volume — so the registry stores a SHA-256 check value rather than the serial itself. Anyone holding the serial can confirm it matches; nobody can read it out of the record.
For aircraft there is one exception. The first four characters of a CTA-2063-A serial are the manufacturer code, which identifies the producer and discloses nothing about volume. MIRA keeps that in the clear, so an inspector with a serial off an airframe can establish who built it before querying anything.
About
Traceability for machines that move.
MIRA gives every civil robot and drone a verifiable identity and an audit trail that follows it for life, including after it changes hands.
The problem
Identifying a machine today means reading a nameplate and trusting it. Nameplates get swapped, damaged and cloned. The paperwork that should back them up — build records, inspection sign-offs, service history — sits in whatever system the current owner happens to use, if it survived the sale at all.
So when a manufacturer issues a field action, there is often no reliable way to reach the units affected. Nobody can say with confidence where they are, who runs them, or what has been changed on them since they shipped.
How it works
At the end of the line, the manufacturer registers the unit once. The machine holds a key inside its own hardware and never releases it. MIRA records only the matching public half, so there is nothing worth stealing in the registry.
To confirm a unit later, you send it a one-time challenge and it signs it. A correct signature can only come from the machine holding that key. A relabelled unit fails the check, and so does a copied record.
What you can verify
In the fieldUnit identity
Confirm the machine in front of you is the unit its passport describes, without relying on a nameplate, a barcode or anyone's word.
Approved envelope
Mass, speed, hazard classification, how close it may work to people, its fail-safe behaviour, and the tooling fitted to it at this moment.
Field actions and holds
Recalls, suspensions and failed inspections are recorded against the unit. A machine placed on hold reads as on hold to every party who checks it.
Who signed off
Every entry names the party that signed it and their role. Only the manufacturer that built a machine can create its passport — an owner or an inspector can add to the record but cannot originate it. So the first line of every passport comes from the factory.
An unbroken history
Entries are sealed to the entry before them. Editing any record invalidates every entry after it, and the check reports exactly which one was altered.
Document control
MIRA stores a check value for the full build record. Hand someone the document and they can confirm it is the revision the manufacturer signed, unmodified.
Design decisions
Why it is built this wayWorks with hardware already in the fleet
Most industrial controllers already contain a security chip designed to hold keys. MIRA accepts the key types those chips produce, so a manufacturer can adopt it without a board revision. A standard that requires new hardware does not get adopted.
Commercial detail is not published
Serial numbers, customer names and site details stay with the parties who hold them. The registry keeps only a check value for the record. That is sufficient to prove a document is genuine without exposing a customer list to competitors.
Keys are replaceable, and the difference is recorded
Security chips fail and controllers get replaced. Where the outgoing key still functions, it signs the handover to its replacement and the chain of custody stays intact and checkable. Where it has failed, the manufacturer authorises the replacement instead, and the passport carries that distinction permanently. Recording the difference is what keeps the clean case meaningful.
As-built is not as-configured
A chassis with an inspection camera and the same chassis with a manipulator arm present different risks. Tooling changes are recorded as events, so a verifier reads the current configuration rather than the one declared at build.
Robots and drones together
Why one registryThe questions differ. The identity does not.
A ground robot is asked whether it can fall over and what terrain it is approved for. An aircraft is asked its take-off mass in grams, what it does when the control link drops, and whether it carries a parachute. Those are different questions because they are different failure modes.
Underneath, both are the same problem: a machine that arrives on site and has to be identified by someone who did not build it. The key, the signature, the hashed serial and the event history are identical, so the site that already checks its floor robots checks the survey drone with the same procedure and the same reader.
For aircraft, the manufacturer serial is already law
Manufacturer-issued identity is not a convention MIRA invented. A producer of a standard Remote ID unmanned aircraft is already required to assign it a serial number in ANSI/CTA-2063-A form. MIRA records the manufacturer code from that serial in the clear and hashes the rest, which means an inspector can establish who built an airframe from the marking alone.
And MIRA stops where the authority starts
A passport is a manufacturer's declaration, not a registration or an airworthiness approval. Operating authority belongs to the civil aviation authority. What MIRA contributes is the step that paperwork cannot: challenging the aircraft in front of you and getting an answer only that aircraft could produce.
Civil equipment only
ScopeMIRA does not register weapons systems or military platforms. The restriction is enforced when a record is submitted and written into the network's founding record, so it is part of what this registry is rather than a policy that could be revised quietly.
This is a deliberate position, and a common one. Several leading robotics manufacturers have made the same public commitment regarding general-purpose machines.
What you can verify yourself
Worth knowingEvery check described above is one you can perform yourself. The signatures and seals are verifiable independently, using published methods and nothing supplied by us. You are not asked to take the registry's word for any of it.
The chain itself is operated by ROMbug. It is tamper-evident by construction — no record can be altered or removed without breaking the hash chain in a way anyone holding a copy would see. MIRA is built for manufacturers and regulators to run their own full copies alongside ROMbug's, and adding them changes nothing about how a passport is issued or checked.
MIRA is a registry of signed statements: who declared what, when, and under whose key. Ownership disputes are settled by contract and by law, and MIRA's job is to give both sides the same authenticated record to argue from.
Who runs it
ContactMIRA is a ROMbug standard. The specification, the reference software, the registry system and this interface are all ROMbug's work.
A registry that competing manufacturers depend on has to be verifiable by everyone who uses it. ROMbug operates the ROMbug MIRA Registry chain and publishes the specification openly, so adopting manufacturers and regulators can hold and audit their own full copies of the ledger — every passport checks out against the record, anywhere it's presented.
Get in touch
Manufacturers, operators and regulators evaluating MIRA for a fleet.
contact@miraregistry.com
Security reports to the same address, marked in the subject line.
MIRA 1.0. The version number is a compatibility guarantee, not a changelog. Anything built against MIRA 1.0 keeps working; the number moves only when the wire format itself changes.