mars
specification

MARS
v1.0

MARS (Multi-Agentic Registry Service) defines a federated protocol for registering, resolving, discovering, and managing autonomous entities — agents, tools, skills, workflows, models, datasets, services, and organizations — within the Open Agent Specification (OAS) ecosystem.

§1

Introduction

MARS exists because the open web's package registries were never designed for software that acts. Agents are not libraries.

This specification defines a federated protocol for registering, resolving, and discovering autonomous entities. Every operation is cryptographically verifiable, every publisher is bonded, and every entry traces back to a verified human.

§2

Terminology

The key words MUST, SHOULD, and MAY in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174].

  • HMR · Human Master Record — root of every lineage chain.
  • MHR · Machine Holding Record — FROST t-of-n signing custodian.
  • ENR · Entity Namespace Record — namespace bound to an HMR/MHR.
  • Entry · A single registry record describing one autonomous entity.
  • Bond · MINTS collateral posted by a publisher and slashable on misuse.
  • Anchor · A 32-byte content-hash commitment recorded on Sigil.
§3

Architecture

MARS is a two-tier system. The Sigil chain stores immutable anchors — the smallest possible cryptographic commitment to an entry's content. The Weave DHT stores the full entry payload, indexed by content hash, replicated across regional shards.

This separation gives MARS the durability of a blockchain registry with the read latency of a CDN.

§4

Entity Types

MARS supports the eleven OAS entity kinds. Each kind has its own bond tier minimum and its own canonical schema for the data field of an entry.

  • agent · tool · skill · workflow
  • model · dataset · service · agent-instance
  • hmr · mhr · enr (identity records, immutable)
§5

Registry Entry

A registry entry is a JSON object containing an OAS DID, kind, version, publisher DID, content hash, signature, and (optionally) tags, attestations, relationships, and bond amount. All fields are canonicalized via JCS before signing.

§6

Registry Operations

Seven verbs define the protocol: register, resolve, discover, update, revoke, transfer, federate. Each maps to a single REST endpoint (see §12).

§7

Publisher Identity & Bonds

Every publish requires a MINTS bond proportional to the entry's risk tier. Bonds are slashable for proven misbehavior — supply-chain attacks, intentional malware, license fraud — and refundable on retirement.

§8

Attestation Integration

Attestations are detachable verifiable credentials issued against entries by independent auditors. Common types: build-reproducible, license-verified, no-malware-detected, eval-passed.

§9

Discovery Protocol

Discovery uses MARS-QL — a SQL superset with first-class graph traversal across lineage and attestation joins. See §11 of the protocol page.

§10

Two-Tier Storage

Sigil anchors prove what was published. The Weave DHT serves the bytes. Hash mismatch on resolution returns an explicit tamper-detected error.

§11

Federation Protocol

Any registry implementing this specification can federate with any other. Federation is unidirectional by default, mutual when both parties consent. Conflicts resolve via the lower sequence number.

§12

API Specification

REST over HTTP/2, JSON bodies, camelCase fields. WebSocket subscriptions for events. Optional gRPC mirror for tightly-coupled clients.

See /api for the full endpoint table.

§13

Notification Protocol

Subscribers receive a strongly-typed event stream over WebSocket. Event kinds: EntryCreated, EntryUpdated, EntryRevoked, AttestationAdded, BondSlashed.

§14

Security Considerations

MARS inherits the security model of OAS for identity and signing. Replay protection via monotonic sequence numbers. Rate limits at the API edge. Bond slashing as the economic deterrent against abuse. See §14 of the source spec for the full threat model.