Builders
Everyone building on KYA-OS, in one registry. Conformance is measured against the pinned vector suite, never self-asserted, and every verified claim is a signed credential this site re-checks.
2 verified credentials, 7 projects.Each wave is drawn from its credential's signature: no two match, and a reissue draws a new one.
implementation - an independent build of the protocol itselfservice - something hosted that you can point at todayexample - a working demonstration to learn fromintegration - a product that uses KYA-OS inside
KYA-OS Demo Serverservice
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; the root URL shows its identity and how to check a proof.
L3 full✓ verified8d72565e
@kya-os/mcpimplementation
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.
L3 full✓ verified9e47cb59
Hobbsidianintegration 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. listedno claim yet
KnowThat.aiservice An agent-identity registry service operating KYA-OS attestation infrastructure. listedno claim yet
KYA-OS Schema Registryservice Hosts the canonical KYA-OS JSON Schemas at stable schema.kya-os.org URLs, byte-mirrored from the @kya-os/mcp npm package. listedno claim yet
KYA-OS Walkthroughexample A guided walkthrough that checks the hosted demo server live, every verdict from the reference verifier. /compare sets standard MCP beside the KYA-OS extension; /attack starts from a stolen token, a compromised sub-agent or an edited audit log and shows which layer refuses each. listedno claim yet
REVOKEDexample 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. listedno claim yet
Ordered by the ladder: verified first, then in verification, then self-reported, then everything listed. Each wave is drawn from its credential's signature; a flat line means no claim yet. Where an entry names a probe endpoint, the daily probe's dated result is in the expanded row.
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.