KYA-OS MCP

Multi-instance deployments

The in-memory defaults are single-process only. For a load-balanced / multi-instance deployment, inject a durable Redis / Durable Object / DB-backed implementation for every runtime-state seam — the nonce cache (NonceCacheProvider) together with the consent stores (GrantStore, PendingFlowStore, SessionStore) — so replay protection, grants, pending OAuth flows, and sessions are shared across instances and survive restarts.

---

Optional did:cheqd and DID-Linked Resources

did:cheqd support is additive and opt-in. Existing did:key and did:web flows remain unchanged, and operators can keep did:web as their canonical identifier while linking to a cheqd DID over time.

Resolver configuration

import { RuntimeFetchProvider, withKyaOs, NodeCryptoProvider } from '@kya-os/mcp';
import { cheqdResolver } from '@kya-os/mcp/cheqd';

const crypto = new NodeCryptoProvider();
const fetchProvider = new RuntimeFetchProvider();
const didResolvers = {
  cheqd: cheqdResolver({ resolverUrl: 'https://resolver.cheqd.net' }),
};

await withKyaOs(server, {
  crypto,
  delegation: {
    fetchProvider,
    didResolvers,
  },
});

did:cheqd is resolved only when a resolver for the cheqd DID method is explicitly supplied. The core middleware and fetch provider use the generic didResolvers registry; cheqd-specific URL/cache/header options live in the cheqdResolver() factory from @kya-os/mcp/cheqd. RuntimeFetchProvider accepts the same registry when it is used directly by a standalone verifier or operator script. Unsupported methods, malformed DIDs, fetch failures, invalid JSON, malformed DID Documents, and DID id mismatches fail closed by returning null. The resolver accepts both raw DID Documents and Universal Resolver-style DID Resolution Results ({ didDocument: ... }).