$ design --principles
Protocol-level philosophy for OpenKitx403. This page defines what the protocol is allowed to do – and what it must never try to do.
Protocol Philosophy
OpenKitx403 standardizes one thing: “prove you control this wallet over HTTP”. Everything else – payments, storage, roles, products – lives outside the protocol. This keeps the core small, auditable, and composable with any stack.
Auth Only, Nothing Else
OpenKitx403’s only job is to prove wallet control over HTTP. It does not handle payments, storage, profiles, or business logic.
- →No balances, swaps, transfers, or settlement logic.
- →No user profiles, social graphs, or identity scoring.
- →No storage or database abstractions.
- →No assumption about what your app actually does after auth.
No Bundled Token Logic
Tokens are treated as inputs to authorization, not dependencies of the protocol itself.
- →Protocol never hard-codes any SPL token, NFT collection, or mint.
- →Token / NFT checks live in app-level policy, not in the auth core.
- →$K403 is an ecosystem & infrastructure token, not a required auth primitive.
- →Token-gating is exposed as hooks, not enforced in the protocol.
No Business Logic
OpenKitx403 does not try to understand or enforce your product rules.
- →No assumptions about plans, roles, quotas, or billing tiers.
- →No embedded ACLs tied to specific products or data models.
- →App decides what 'allowed' means – protocol just proves who the caller is.
- →All domain logic stays in your backend, not in x403.
Composable, Not Monolithic
x403 is designed to stack cleanly with x402, existing auth systems, and any HTTP backend.
- →Plugs into standard HTTP stacks (FastAPI, Express/Fastify, etc.).
- →Easy to pair with x402 for payment-gated APIs.
- →Works alongside existing session systems while staying stateless itself.
- →You can add, swap, or remove x403 without rewriting your whole app.
App-Agnostic by Design
The protocol does not know, care, or guess what kind of app you’re building.
- →No dApp-specific assumptions (DEX, NFT, gaming, DeFi, etc.).
- →Only understands: wallet, challenge, signature, bindings, and time.
- →Everything beyond proving control of a wallet is intentionally left to the app.
- →Same protocol works for bots, dashboards, agents, mobile apps, and CLIs.
Contributor Alignment
All contributions should respect the 'auth-only' boundary and keep the core small, secure, and predictable.
- →Core repo stays focused on authentication, bindings, and replay protection.
- →New features should be added as optional surfaces (hooks, helpers, plugins).
- →Avoid introducing hidden state, global config, or app-specific shortcuts.
- →If it smells like product logic, it belongs in example apps – not the protocol.