Keryx: a paid tool registry for AI agents

Abstract

AI agents are becoming direct consumers of software, not just people using software through a chat window. Most tools an agent might want to call today are still gated behind human-shaped onboarding: create an account, generate an API key, attach a card, wait for approval. That flow assumes a human is present to complete it. An agent making one autonomous call to answer one question has no use for a monthly subscription and no way to click through a signup form.

Keryx is a registry where any developer publishes a tool at a price, and any agent calls that tool by paying for exactly the call it makes. Discovery, pricing, execution, and payment happen in a single request. Settlement runs in USDC on Arc, a stablecoin-native chain built by Circle, so a call priced at half a cent is not eaten alive by transaction fees.

The problem: software built for humans, not callers

Three assumptions are baked into almost every API on the internet today, and all three break when the caller is an agent instead of a person:

• Identity is assumed to be durable. APIs expect a long-lived account: an email, a password, a dashboard the owner returns to. An agent spun up to answer one question has no durable identity worth registering.
• Payment is assumed to be recurring. Subscriptions and metered billing exist because processing a card is expensive relative to a single API call. That math does not work below a cent, which is exactly the price band most agent tool calls fall into.
• Access is assumed to be pre-provisioned. A human reads docs, gets a key, and hardcodes it. An agent discovering a new capability mid-task cannot pause to fill out a form.

None of these are hard technical problems. They are defaults that made sense when the caller was always a person, and stopped making sense the moment the caller became a stateless process with a wallet.

Design principle: pay per call, not per account

Keryx has one design principle and everything else follows from it: the unit of access is the call, not the account. There is no signup for agents. There is no API key. A publisher lists a tool once; from then on, every agent on the internet can discover it via GET /api/tools and pay for it via POST /api/call in the same request that executes it.

This inverts the usual cost structure. Instead of a publisher absorbing infrastructure cost while hoping enough signups convert to paid plans, every single call is already paid before the response leaves the server. There is no free tier to abuse and no unpaid usage to write off.

Protocol mechanics

1. Publish

A developer registers an HTTP-callable tool: an id, a one-line summary an agent uses to decide whether to call it, a category, a price in USD, an argument schema, and the wallet that should receive payment. This is a POST /api/publishers/tools call. There is no review queue standing between listing and going live, so the tool is callable immediately (see Trust and verification for what that trade-off costs today).

The same tools are instantly available to agents through the Model Context Protocol (MCP). Cursor, Claude (via custom connectors), GitHub Copilot, and any MCP-compatible client can discover and call them natively with a one-line config.

2. Discover

GET /api/tools returns every published tool with its price, its argument schema, and a sample call. An agent needs no separate documentation lookup: the schema an agent uses to plan a call is the same schema Keryx uses to validate it.

3. Call, quote, execute, pay

POST /api/call does four things in one round trip. It looks up the tool, computes a quote (the listed price, split into a publisher share and a platform fee), executes the tool's handler with the caller's arguments, and writes the result to the public ledger, whether the call succeeded or failed. The response carries the tool's result and the ledger entry id together, so a caller can prove a specific call was paid for.

4. Settle

Onchain, transferWithAuthorization pays 100% of the call price to the publisher's payTo wallet. The 5% platform fee is recorded on the public ledger today; a separate treasury split transfer is roadmap. See Settlement.

Settlement: x402 on Arc, batched through Circle Gateway

Keryx settles on Arc, Circle's stablecoin-native L1 (testnet chain id 5042002, native gas denominated in USDC). Arc was chosen specifically because sub-cent pricing only works if the settlement layer does not itself cost more than the call. A registry that prices a search call at $0.004 cannot settle it on a chain where gas costs ten times that.

POST /api/call speaks the real x402 protocol. A first hit without an X-PAYMENT header returns HTTP 402 with a machine-readable acceptsarray carrying the exact amount, USDC asset address, seller wallet, and Arc network id. The caller signs an EIP-3009 USDC authorization against those requirements and retries with the base64-encoded signature in the header. The server decodes, verifies, executes the tool, and settles — all inside a single request.

Verification and settlement route through a swappable facilitator, preferred in this order: (1) local Arc facilitator when KERYX_FACILITATOR_PRIVATE_KEY is set — real transferWithAuthorization broadcasts with Arcscan hashes; (2) Circle Gateway when CIRCLE_GATEWAY_PREFERRED=true and CIRCLE_GATEWAY_API_URL are set (or when no local key exists); (3) demo facilitator that accepts well-formed payloads and records a synthetic demo_0x… hash. The /live ledger tags gateway / local / demo on every row. Production at keryxhq.xyz typically runs local (real testnet USDC).

The reason to batch through Circle Gateway rather than settle every call as its own onchain transaction is the same reason Arc exists in the first place: at sub-cent price points, the cost and latency of broadcasting one transaction per call would dominate the transaction itself. Batching lets Keryx settle many calls' worth of USDC movement in a single, periodic onchain transfer per publisher, while every individual call is still quoted, priced, and ledgered in real time.

Trust and verification

Publisher wallet ownership is enforced via EIP-191 signatures. Before a new tool can be registered, the client requests a nonce from POST /api/publishers/nonce, signs a canonical message with the wallet it claims to own, and submits the signature alongside the tool payload. The server rebuilds the exact message and verifies it via viem's verifyMessage. Nonces are consumed on first successful verification and expire after five minutes, so a signature cannot be replayed for a different tool or a different registration attempt.

Keryx distinguishes tools by a verified flag. Seeded tools (Keryx runs the handler against live public APIs) are verified and immediately executable. Community tools are listed right away; they become executable when the publisher provides a simple POST handler URL (Keryx forwards after payment). The seeded catalog focuses on everyday micro-tasks (weather, finance, geo, dns, web data, crypto, utilities).

A companion contract, KeryxRegistry.sol, mirrors the offchain registry on Arc. Publishing a tool onchain records the publisher wallet, price, and metadata URI in permanent storage keyed by keccak256(id). Only the wallet that first publishes an id can update its price, edit metadata, or transfer the listing. Keryx as owner can pause the registry or mark a listing verified; it cannot rewrite a publisher's state. The contract is deployed on Arc testnet at 0x7eA3…8bA7, owned by the Keryx treasury, and seeded tools are mirrored onchain (visible as On Arc badges on the /registry page).

Economics

Keryx quotes a flat 5% platform fee on every call. Today the onchain transfer pays 100% of the call price to the publisher payTo; the 5% is ledger accounting until split settlement ships. There is no listing fee, no minimum volume, and no subscription. A publisher earns from the first call. An agent pays for exactly the calls it makes and nothing else.

This only works economically because the calls themselves are priced in fractions of a cent and settle on a chain built for exactly that price band. A 5% fee on a $0.004 call is a fraction of a cent moving through a system where a fraction of a cent is still worth collecting, precisely because Arc and x402 make the collection itself nearly free.

Roadmap

Status as of July 2026:

• ✓ Clear handler contract for community publishers (publish a handlerUrl; Keryx forwards after payment). Seeded catalog at 20 practical tools (Solana onchain research, weather, finance/rates, geo, search, crypto market signals, utilities, time/uuid, etc.).
• ✓ Local Arc facilitator preferred on prod when KERYX_FACILITATOR_PRIVATE_KEY is set (real testnet USDC + Arcscan). Circle Gateway when CIRCLE_GATEWAY_PREFERRED=true + CIRCLE_GATEWAY_API_URL; otherwise demo.
• ✓ Agent discovery: /.well-known/x402, /llms.txt, free /api/demo, Bazaar-style extensions.bazaar on 402s, /api/receipt/verify, buyer quickstarts (/quickstart.ts, /quickstart.py).
• ✓ Basic OpenAPI spec at /keryx-openapi.json. @keryxhq/middleware on npm. First-party Python SDK — planned next.

The three bullets below are the original aspirational list; the checkmarks above reflect what actually shipped.

• Rich seeded catalog (20+ everyday tools) + clear handler contract for community publishers
• Provisioning a Circle Gateway account and flipping the default facilitator from demo to gateway in production.
• OpenAPI spec and first-party SDKs for Node and Python.

Known limitations

This is a v0.1 build, written to be honest rather than oversold. The x402 path (402 + signed X-PAYMENT + verify/execute/settle) is real end-to-end. Production settles via the local Arc facilitator when a facilitator key is present (real Arcscan txs). Circle Gateway is coded and flips on with CIRCLE_GATEWAY_PREFERRED=true + CIRCLE_GATEWAY_API_URL. Without either, cold clones run demo (synthetic hashes). Persistence is Redis when configured, otherwise in-memory. Onchain settlement pays 100% to payTo; the 5% platform fee is ledger accounting until split settlement ships. /ask and MCP are sponsored (not autonomous payers). Seeded tools hit live public APIs; community tools need a handlerUrl.