Zeyon

System design ​

Zeyon separates the public record, human-readable metadata, evidence, and legal reality. Each layer answers a different question.

Core layers ​

Robot Record ​

The Robot Record is the public identity and history anchor. It is designed to store a permanent ID, creator, current controller, lifecycle status, metadata reference, and append-only event references.

Metadata and evidence ​

Human-readable metadata describes the machine. Evidence supports a specific claim. Both remain offchain and are referenced by a URI and content hash where appropriate.

A content hash can show whether a referenced file changed. It does not show that the file was accurate when submitted.

Attestations ​

An attestation records that an approved party checked a defined claim or event. Its scope must remain visible. A service provider signing one maintenance event does not verify ownership, revenue, location, or every other event in the record.

Attestations may later be revoked. The revocation should remain part of the public history rather than deleting the original statement.

Read model ​

The planned indexer projects contract events into a searchable read model for the explorer and API. It improves access but is not authoritative. If the index disagrees with the contract, the contract state and event log take priority.

Roles and authority ​

  • Creator: Creates the Robot Record and assigns its initial controller.
  • Controller: Updates the metadata reference, appends events, proposes control transfers, and may retire an eligible record.
  • Proposed controller: Must accept before a control transfer completes.
  • Attester: Signs only the claims and evidence types it is approved to review.
  • Registry administrator: May pause creation, manage approved attesters, and suspend or restore records under disclosed rules.

Record control does not establish ownership of the physical robot. Zeyon also does not control robot navigation, perception, physical safety, or emergency systems.

Claim progression ​

Claims are designed to move through explicit states without rewriting their origin:

  1. Self-reported: The controller submitted the claim.
  2. Evidence-backed: A file, signature, or external reference supports it.
  3. Third-party attested: An approved service party reviewed the defined claim.
  4. Manufacturer attested: The manufacturer or an authorized representative signed the defined field or event.

Higher-value uses will require task-specific evidence rules. Two data points produced by the same controller should not be treated as independent confirmation merely because they are stored separately.

Privacy boundary ​

The public layer should contain the minimum information needed to inspect state and provenance. It should not contain:

  • Raw serial numbers
  • Customer identities
  • Facility maps or precise private locations
  • Raw video or proprietary telemetry
  • Detailed commercial contracts
  • Secrets, credentials, or unrestricted machine-control data

Private material may be referenced through commitments and disclosed only to authorized parties when a review requires it.

Product sequence ​

The public Registry demonstration and ZEY token now exist as separate tracks. The integration sequence is:

  1. Keep the public Registry demo inspectable and clearly labeled as demonstration data.
  2. Test the Robot Registry contract and indexer on Robinhood Chain testnet.
  3. Connect the public explorer and a read-only API to canonical testnet events.
  4. Add evidence submission and qualified attestation workflows.
  5. Integrate ZEY Registry credits, staking, and challenge bonds with bounded claim types.
  6. Release each utility with its public contract, controls, interface, and operating rules.
  7. Explore settlement, reporting, and financing integrations with appropriate counterparties.

ZEY is live as an ERC-20 and will provide the coordination and verification-security layer for these product flows. Commercial payments will support ZEY, stablecoins, and existing payment rails.

Failure assumptions ​

The design assumes that controllers may submit incorrect data, evidence may be incomplete, indexers may lag or fail, attesters may make mistakes, and administrative keys may be misused. Public state, scoped authority, revocation history, two-step control transfer, pause controls, and clear interface labels are intended to make those failures visible and contain their effect.