Developer API Keys for Decentralized Infrastructure

The Access Problem

Decentralized infrastructure faces a paradox: the system is open by design, but programmatic access still needs authentication. Without API keys, you can't rate-limit abusive clients, track usage for billing, or distinguish between a developer building an integration and a bot scraping your registry.

When KnowYourModel (a trust registry) and NANDA (a discovery protocol) needed developer programs, we faced an additional challenge: two platforms with overlapping audiences but distinct capabilities. A developer querying KYM's trust scores doesn't necessarily need NANDA discovery access, and vice versa. The solution: parallel key systems with a shared security architecture.

Two Prefixes, One Architecture

Both platforms issue keys with distinct prefixes — kym_ for KnowYourModel and nanda_ for NANDA — making it immediately obvious which platform a key belongs to. Under the hood, the architecture is identical:

The key insight: these programs complement rather than duplicate. A KYM key can search NANDA data through KYM's proxy routes (/api/nanda/search, /api/nanda/list), while a NANDA key accesses the discovery layer directly. Developers choose based on their use case — trust evaluation, agent discovery, or both.

Security: SHA-256 + Bearer Auth

Both platforms follow the same security model, designed for zero-trust infrastructure running on Cloudflare Workers:

• Generation — Keys are generated as cryptographically random tokens (32 bytes), prefixed with the platform identifier, and shown to the developer exactly once
• Storage — Only the SHA-256 hash of the key is persisted in D1. If the database is compromised, raw keys cannot be recovered
• Authentication — Keys are sent as Bearer tokens in the Authorization header. SvelteKit's hooks.server.ts middleware intercepts every request to API routes, hashes the provided token, and looks up the hash in the database
• Revocation — Keys can be revoked instantly via the management dashboard. The key's status is set to revoked in D1, and subsequent requests with that key fail immediately

This pattern means neither platform ever stores a recoverable key — even Nexartis engineers cannot see a developer's raw API key after initial generation.

Tiered Rate Limiting

Both platforms implement three-tier rate limiting with D1-backed per-key counters that reset monthly:

Rate limit state is stored in D1 alongside the key record. Each key tracks a monthly usage counter and a reset timestamp set to the first of the next month, so limits reset automatically without a cleanup job.

Developer Experience

Both platforms provide session-authenticated dashboards for key management — no API key required to manage your API keys. The flow is deliberately simple:

1. Sign in to the Developer Portal (NANDA) or Developer Page (KYM)
2. Navigate to the Key Management Dashboard
3. Generate a key — it's shown once, with a copy-to-clipboard button
4. Use the key as a Bearer token in API requests

Both dashboards also display key metadata: creation date, tier, last used timestamp, and total request count. Revocation is a single click with immediate effect.

Design Principles

Several principles guided the design of both API key systems:

• Zero recoverable secrets — SHA-256 hashing means compromised databases don't leak keys
• Prefix-based routing — kym_ vs nanda_ makes misconfigurations immediately visible
• Edge-native rate limiting — D1-backed monthly counters enforced at the edge with automatic resets
• Complementary not competitive — Cross-platform proxy routes mean one key can serve multi-platform workflows
• Progressive access — Free tier is generous enough for real prototyping, not just "hello world" demos

The result is a developer experience that feels like a single platform, even though it's built on two independent infrastructure stacks. Authentication patterns, dashboard conventions, and rate limit structures are all intentionally harmonized.