Specifications

Wire-level specifications and white papers for the Maya 2030 stack. Each URI here is the canonical home for the named artifact.

A2A v1.0 extensions

Maya is wire-compatible with A2A v1.0. Two extensions carry the parts of the design that A2A doesn't opine on: authorization and audit.

• a2a — integration overview. Reader-oriented walkthrough of how UCAN and substrate-receipts compose with the A2A 8-state task lifecycle.
• a2a/ext/ucan/v1 — UcanSecurityScheme. UCAN delegation chains as an A2A authentication scheme. Capability-rooted instead of identity-rooted.
• a2a/ext/substrate-receipts/v1 — SubstrateReceiptEnvelope on Task responses. Substrate-signed, Bitcoin-anchorable receipts attached to completed actions.

Identity

• did/deos/v1 — the did:deos DID method. Ed25519 verification methods, agent derivation chains, anchored DID-document updates, federated resolution.
• identity/personhood/v1 — PersonhoodAssertion extension on DID documents. Pluggable VC-based personhood floor with a shared tier vocabulary (weak / moderate / strong); schemes (social-graph / Worldcoin / government VC / deposit-bond) are deployment policy, not protocol.

Discovery

• discovery/indexer/v1 — federated indexer protocol. A2A-native catalog discovery: any agent can stand up an indexer; relying agents query multiple indexers and reciprocal-rank-fuse the results; indexer receipts make ranking falsifiable and cartel collusion detectable.

Personal data

• data/vault/v1 — personal data vault primitives. DID-advertised vault endpoints, UCAN-gated reads with path-prefix attenuation, substrate-witnessed vault.access/read receipts for every read, and a selective-disclosure (ZK) proof envelope for proof-only reads. Vault implementation is deployment policy; the spec defines the wire.

Settlement

• settlement/conditional/v1 — receipt-rooted conditional escrow. Defines the wire shape for settlement.conditional/escrow receipts, the deterministic disposition algorithm any conforming escrow holder must implement (await / release / refund_timeout / refund_disputed / frozen), and the composition with payment rails (EVM stablecoins, FedNow, RTP, Lightning, internal).

Substrate internals

The cryptographic and protocol contracts an implementer needs to build a Maya-compatible trust substrate from scratch. Every spec listed above ultimately bottoms out into one of these.

• receipts/format/v1 — receipt wire format. JCS canonicalization, BLAKE3 content addressing, Ed25519 signing, action types, and field-by-field verifier contract. The keystone every other spec references.
• ucan/tokens/v1 — UCAN-shaped capability tokens. Inline-signature JSON shape, attenuation rules, chain-validity algorithm, and the wire-compatibility mapping to UCAN v1.0 JWTs.
• attestation/api/v1 — HTTP surface a substrate exposes: trust-root, log, receipt/{id}, proof/{id},append. Plus the normative verification flow and the tampering taxonomy.
• merkle/log/v1 — Merkle Mountain Range construction with domain-separated hash tags. Append algorithm, root computation, inclusion proofs, on-disk snapshot format.
• mmr/transparency/v1 — consistency proofs, witness-driven gossip, fork detection, log-of-logs cross-witnessing. The mechanisms that make substrate equivocation detectable.
• anchor/v1 — OpenTimestamps submission protocol, anchor record schema, anchor scheme registry for multi-rail timestamping.
• anchor/bitcoin/v1 — verifier-side Bitcoin block-header verification, OTS opcode walking, OP_RETURN matching, and effective-timestamp bounding via nTime and median-time-past.
• revocation/v1 — capability revocation. Separate MMR-backed revocation log, time-of-revocation semantics, offline-verifier tolerance window, non-membership proofs.
• key-rotation/v1 — substrate signing-key rotation. Dual-signed rotation events, trust-root history endpoint, compromise-recovery procedure that bounds the trust period of a leaked key.
• capability/caveats/v1 — caveat algebra. Hierarchical can matching, with-set membership, OR-composition, caveat-level revocation, ratchets, time-range composition.
• registry/v1 — central registry. Action types, caveat keys, anchor schemes, signature algorithms, hash functions, domain-separation tags, JSON schemas, revocation reasons.
• threat-model/v1 — consolidated STRIDE-style threat model across every substrate layer. Threat-actor profiles. Delta vs the SCITT architecture.

Interop / compatibility

Bridges to adjacent standards bodies. Optional for a Maya substrate; required if you want DEOS-issued receipts to flow through existing SCITT or W3C VC pipelines.

• interop/scitt/v1 — DEOS profile of IETF SCITT (transparency-service shape). How DEOS concepts (UCAN, did:deos, OTS, replay) ride inside a SCITT-conformant COSE_Sign1 envelope as profile-private CWT claims.
• interop/vc-jwt/v1 — receipt ↔ W3C Verifiable Credential bridge. Lossless projection to VC-JWT for existing VC stacks (Entra Verified ID, Trinsic, DIF Universal Resolver).

White papers

• papers/reputation — Receipt-Rooted Reputation. How a stream of signed, log-anchored substrate receipts forms a portable, verifiable, selectively disclosable reputation primitive that is structurally different from aggregator-controlled scores. Draft v1, May 2026.

Versioning

Each spec URI is immutable once published; breaking changes ship as a new URI (/a2a/ext/ucan/v2, /did/deos/v2, etc.). Compatible additions land in the same URI and bump the Status line on the spec page.

Reference implementation

The substrate that issues receipts, hosts DID documents, and accepts the UCAN auth scheme is implemented and running in DEOS Computing's working repository, access-controlled during the v1 alpha. The specifications above are normative and self-contained — an independent implementer can build a conformant substrate from the documents alone. Contact founders@deoscomputing.io for partner access to the reference code, conformance test vectors, or interop testing.