BUILDERS
Everyone building on KYA-OS, in one registry. Verified implementations lead the list, and every listing is one pull request away. 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. ✓ verified 2026-08-19
@kya-os/mcp 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. ✓ verified 2026-08-20
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
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
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; ships as a runnable example in the reference implementation. · listed 2026-08-19
Ordered by the ladder: verified first, then in verification, then self-reported, then everything listed. A ● next to the name marks a hosted service endpoint you can point at today; where the entry names a probe endpoint, the daily probe classifies it in the expanded row - dated, from the wire, independent of any claim.
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 48 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 ->Build your entry
Fill in the fields and watch registry/builders/<your-slug>.json take shape. The checks that run here as you type are the checks CI runs on your pull request - same rules, same messages - and the pull-request button opens the GitHub editor with the finished file already in it.
or copy the template file manually
{
"name": "Your Project",
"slug": "your-project",
"description": "One or two sentences on what you ship on KYA-OS.",
"homepage": "https://example.com",
"repo": "https://github.com/your-org/your-project",
"kind": "implementation",
"buildsOn": [
"kya-os-mcp"
],
"contact": {
"github": "your-github-username"
},
"listedAt": "YYYY-MM-DD"
}
Save it as registry/builders/<your-slug>.json in a fork of kya-os/kya-os-usergroup, keep slug equal to the filename, set listedAt to today, run npm test (no dependencies to install), and open a pull request signed off with git commit -s. The field reference is in CONTRIBUTING.md.
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. Services can additionally prove live enforcement via the daily probe - the wire is the witness: a bare request must be refused.
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 48-vector suite (suite 1.1.0, vectorSetHash sha256:38f34222fd91e75a162b01a81f83aa40907674f9c1bed72c46f1861cb49ceef5), 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.