Concepts

Zeyon separates physical truth from blockchain state. We do this by tracking the origin of every claim.

The Robot Record

The Robot Record is the core registry entry for a physical robot. It holds two types of information.

Onchain fields store the permanent rules and references. They include:

• The Zeyon asset ID
• Record creator and controller addresses
• Hashes of the serial number and manufacturer
• The metadata URI
• The current status

Offchain metadata stores human-readable information. We store this as a JSON document referenced by the onchain URI. It includes:

• Display name and category
• Manufacturer and model names
• Approximate operating region
• Images and capability descriptions

The planned explorer uses an index for fast search. The index is a read model, not the source of record control or event history.

Record lifecycle

1. Created: A wallet creates a record and assigns its controller. The record receives a permanent numeric ID and starts as active.
2. Updated: The controller can update the metadata reference and append events. Existing events are not overwritten.
3. Transferred: The controller proposes a new controller. The proposed address must accept before control changes.
4. Suspended: The registry administrator can suspend an active record with a public reason reference. A suspended record cannot be updated or transferred.
5. Restored: The administrator can return a suspended record to active status with a public reason reference.
6. Retired: The controller can permanently retire an active record. Retirement is terminal.

Creating a Robot Record does not establish legal ownership of the physical machine.

Event types

Controllers submit timestamped event references to describe machine activity. The contract stores an event type, occurrence time, payload hash, and payload URI. Initial event meanings are planned to include:

• Deployment started or ended
• Work metric reported
• Maintenance completed
• Fault reported or resolved
• Inspection completed

The verification model

Blockchain state proves that a specific address submitted data at a particular time. It does not prove that a physical event occurred. Zeyon's product model uses four labels to communicate the origin and review state of a claim.

1. Self-reported: The record controller submitted the claim. Nobody else checked it.
2. Evidence-backed: The submission includes files, signatures, or external references.
3. Third-party attested: An approved service provider reviewed and signed the claim.
4. Manufacturer attested: The manufacturer or an authorized representative signed the claim.

The planned interface will show a label beside every important claim. One attested event will not mark an entire profile as verified.

Trust boundaries

• The registry can prove: record IDs, controller changes, status changes, timestamps, submitted hashes, event order, and attestation history.
• The registry cannot prove by itself: physical possession, legal title, machine condition, revenue, location, or whether submitted evidence is truthful.
• Controllers are responsible for: the claims and references they submit.
• Attesters are responsible for: the exact event and evidence scope they sign. Attestations can be revoked, and revocation remains visible.
• Registry administrators can: pause new record creation, manage approved attesters, and suspend or restore records. These powers will be disclosed with the public deployment.