BUILDERS
Everyone building on KYA-OS, in one registry — ordered by how much has been proven. Conformance here is measured against the pinned vector suite, never self-asserted.
implementation — an independent build of the protocol itselfservice — something hosted that you can point at todaytemplate — a starting point to forkexample — a working demonstration to learn fromintegration — a product that uses KYA-OS insidemarketplace — a directory or store that lists KYA-OS agents
KYA-OS Demo Server service A live hosted MCP server speaking KYA-OS: handshake, signed proofs, and delegation against a real endpoint, for anyone who wants to poke the protocol before running their own. Speak MCP to POST /mcp (GET /health for liveness); the root URL serves no landing page yet. ◌ in verification 2026-08-19
@kya-os/mcp (reference implementation) implementation The reference implementation of KYA-OS for MCP servers: DID identity, scoped delegation with consent gating, and detached-JWS proofs in two added lines. The conformance vectors derive from this codebase, so its full-suite pass is self-reported, not independent evidence. ◌ in verification 2026-08-20
Mycelium Trails implementation Independent Ed25519 implementation (action_ref / argentum-core, pynacl) cross-checked against the KYA-OS signed-proof conformance vectors; ran the upstream verify.py unmodified at 10/10 and filed a vector finding upstream. ◌ in verification 2026-08-19
KnowThat.ai service An agent-identity registry service operating KYA-OS attestation infrastructure. · listed 2026-08-20
KYA-OS Schema Registry service Hosts the canonical KYA-OS JSON Schemas at stable schema.kya-os.org URLs, byte-mirrored from the @kya-os/mcp npm package. · listed 2026-08-20
Conformance Starter template Copyable template that takes an existing KYA-OS implementation to a submission-ready conformance claim in under an hour: fetches the pinned vector suite hash-verified, runs all 44 vectors through your adapter (or any-language harness), and emits claim.json. · listed 2026-08-19
Hobbsidian integration Vault sharing for humans and AI agents: per-file access control, passkey-bound DIDs, and an MCP server where agent access is a capability- and path-scoped delegation verified with the @kya-os stack - the server never holds the minting key. · listed 2026-08-20
REVOKED example An on-chain kill switch for AI agents with wallet access: agents spend under scoped, verifiable delegations, and that authority is revocable on a public chain (cheqd testnet). Built at DEF CON 34; now the flagship example of the reference implementation. · listed 2026-08-19
Ordered by verification: claims under measurement first, then hosted service endpoints, then everything listed. A ● next to the name marks a hosted service endpoint you can point at today.
Start here
Speak MCP to a real KYA-OS endpoint before running your own — inspect the signed proof in every response.
raw endpoint: POST https://demo-mcp.kya-os.ai/mcp
From existing implementation to submission-ready conformance claim in under an hour — all 44 vectors, any language.
conformance-starter ->REVOKED: an on-chain kill switch for wallet agents. A genuinely revoked credential is anchored on-chain right now.
use-cases ->Join the registry
Getting listed and claiming conformance are not separate acts — they are rungs of one ladder, and the same registry entry climbs it in public. Corrections count too: every standards-matrix row is one file in registry/interop/ — use the row's edit link on the standards page, or PR the file directly.
Listed in five minutes. Self-reported the same hour. Verified when the program re-runs your bytes.
Hand the prompt to your coding agent and it walks the ladder with you: your entry, an optional self-reported conformance run against the pinned suite, one pull request, and the submission issue if you want verification. Or take the one-click path — the button opens the GitHub editor on registry/builders/ with the entry template prefilled: rename to <your-slug>.json, edit the fields, propose the change.
or copy manually
Join the KYA-OS builders registry end to end: (1) read https://github.com/kya-os/kya-os-usergroup/blob/main/registry/builders/example-builder.json and CONTRIBUTING.md, ask me for my project's name, slug (lowercase repo-name style, 2-40 chars of a-z 0-9 hyphen; unique across registry/), homepage, repo, kind, what it builds on, and a contact GitHub handle, and create registry/builders/<my-slug>.json; (2) if my project implements KYA-OS verification, also clone the repo, follow conformance/starter/README.md to run the pinned 44-vector suite (suite 1.0.0, vectorSetHash sha256:81d537d4574d3f66d651a03ca41c0b18493b67ea6f3e61aba47d1bda4f3cf49b), and embed a self-reported conformance object in my entry with the level and scope the run actually supports; (3) validate with npm test; (4) open ONE pull request to kya-os/kya-os-usergroup titled 'registry: add <my-slug>'; (5) if I want verification, also open a conformance submission issue on kya-os/kya-os-usergroup with my claim JSON and set my entry's status to in-verification with the issue as evidenceUrl - all in the same session.
Two fields CI will not forgive: set listedAt to today's real date, and keep slug equal to your filename.
Prefer a local workflow? Copy example-builder.json to registry/builders/<your-slug>.json, run npm test (no dependencies to install), and open a PR — the field reference is in CONTRIBUTING.md.