K-Squire helmet mark K‑Squire Gateway
Self-hosted · x402-native · sovereign settlement

Charge AI agents for your API.
Without handing your paywall to anyone.

One small service in front of — or beside — your existing API or MCP server. One pricing rule. Agents pay per call over the open x402 standard, settling straight to your wallet — stablecoins out of the box, any rail you choose. Receipts on your disk, no code changes, no merchant of record.

Get early access →
Cloudflare just showed the world that agents will pay per request. K‑Squire is that capability for everyone who isn't behind Cloudflare — and doesn't want to be.
k-squire
$ docker compose up -d k-squire

# rules.yaml
upstream: http://localhost:8080
routes:
  - match: { method: GET, path: /api/report }
    price: $0.02
  - match: { mcp_tool: summarize }
    price: $0.005

$ curl -i localhost:3402/api/report
HTTP/1.1 402 Payment Required
{ "accepts": [ { "scheme": "exact", "network": "base",
    "amount": "20000", "payTo": "0xYourWallet…",
    "resource": "GET /api/report" } ] }
# agent pays → retries → 200 + receipt logged

Illustrative — field names track the x402 spec; assets and networks depend on your facilitator.

Zero code changes

Run it inline as a reverse proxy, or in forward-auth mode beside the Caddy/Traefik/nginx you already trust. Your app never knows payments exist.

MCP-native

MCP speaks JSON-RPC to a single endpoint — the tool name lives in the request body, where path-based paywalls can't see it. K‑Squire prices individual tool calls and pipes SSE streams through untouched.

Sovereign by default

Self-hosted, facilitator-agnostic (Coinbase, thirdweb, or your own), peer-to-peer settlement straight to your wallet. No middleman in your money path.

Two ways to deploy

Inline proxy

for MCP servers & metered pricing

docker compose up. K‑Squire fronts your service, reads pricing rules, and passes everything unpaid straight through. The only mode that can price MCP tools — and, later, meter responses per token or per byte.

$ docker compose up

# rules.yaml
routes:
  - match: { mcp_tool: summarize }
    price: $0.005

Forward-auth

for your existing proxy

Keep Caddy, Traefik, or nginx exactly where it is. It asks K‑Squire to authorize each request; K‑Squire answers pass or 402-with-terms. Decision path, not data path — three lines of config:

example.com {
    forward_auth k-squire:3402 {
        uri /authz
        copy_headers X-Payment-Response
    }
    reverse_proxy backend:8080
}

Caddyfile shown; Traefik ForwardAuth works the same way. Path/method pricing in this mode — MCP tool pricing needs inline.

Agents hit your endpoint, get an HTTP 402 quote, pay, and retry — automatically. You get the revenue and an auditable receipt log.

Who it's for

API operators

Want agent revenue without a platform standing between you and your money.

MCP server authors

Monetize tools in minutes. Price per individual tool call.

Sovereignty-minded teams

Can't or won't route traffic through a third-party edge — compliance, data-sovereignty, crypto-native, or self-hosters on principle.

How it compares

Compared to Cloudflare's Monetization Gateway and per-route x402 SDKs:

Cloudflare Gatewayx402 SDKsK‑Squire
Code changesnonerequirednone
Self-hostablenoyesyes
MCP tool-level pricingnonoyes
Works beside your existing proxynon/ayes (forward-auth)
Metered pricing (per-token/byte)nonoroadmap (inline mode)
Merchant of recordCloudflareyouyou
Facilitator choicetheirsanyany

FAQ

Why not just use Cloudflare's Monetization Gateway?

If you're happy behind Cloudflare with Cloudflare as merchant of record, use it — it's good. K‑Squire is for everyone else: self-hosted infra, MCP servers, compliance constraints, or principle.

Why not just use an x402 SDK?

SDKs mean touching your codebase per route and per app. K‑Squire is one proxy for all of them, with receipts, webhooks, and a dashboard included.

So your beta project becomes my single point of failure?

No — that's what forward-auth mode is for: your battle-tested proxy keeps handling bytes and TLS while K‑Squire only answers paid/not-paid. Running inline instead? There's a fail_open flag — if the payment layer is unreachable, traffic passes free and gets logged. Your call, per route.

What does this add to latency?

On free routes: effectively nothing — requests pass straight through (deploy as a sidecar and it's microseconds, not a network hop). On paid requests, the real cost is the facilitator verification round-trip — and that's inherent to x402 in every architecture, SDK or proxy alike. We just refuse to add more on top.

What about streaming?

SSE passes through untouched — MCP requires it, so it was never optional. v1 is HTTP/1.1 + SSE; WebSockets and gRPC aren't supported yet, and we'd rather say so here than surprise you in prod.

How does a 402 work mid-MCP-session?

Both channels: the HTTP-level 402 for transports that surface it, and an in-band JSON-RPC error carrying the same payment terms for clients that don't. x402-aware clients use whichever they understand.

Do I have to touch crypto?

You set prices in dollars. Buyers pay in stablecoins today — that's what agent wallets hold — or any rail your facilitator supports; it lands in a wallet you control. Off-ramping is your choice; we'll document the easy paths.

Is this custodial?

No. Settlement is peer-to-peer to your wallet. K‑Squire never holds funds.

What chains?

Whatever your facilitator supports — Base and Solana out of the box via existing facilitators. Exotic rails, including fully sovereign proof-of-work settlement on Kaspa, are available for those who want zero intermediaries.

Get early access

Self-hosted or hosted — tell us what you'd paywall and we'll bring you in. Design partners get free setup help.

Self-hosted is free and open source. Hosted starts around $29/mo when the beta opens — design partners get it free.

Preference