DEV Community: Mr Hamlin

I Ship Paid APIs in a Weekend. Here's the Exact Stack I Use Every Time.

Mr Hamlin — Sat, 20 Jun 2026 00:10:11 +0000

I've shipped three paid API products in the past six months. Each one took a weekend to reach a working, billable state — users signing up, generating API keys, making authenticated requests, and paying me through Stripe.

Not because I'm fast. Because the infrastructure is the same every time.

Auth is the same. API key management is the same. Stripe billing is the same. Rate limiting, usage tracking, the dashboard — all the same. The only thing that changes is the business logic behind the endpoints.

After the third time wiring Stripe webhooks to Supabase to API key validation, I wrote down the pattern. Here it is.

The Stack

Layer	Tool	Cost
Runtime	Node.js + Express	Free
Auth & Database	Supabase	Free tier
Billing	Stripe	2.9% + 30¢ per txn
Rate Limiting	Redis (Upstash)	Free tier
Dashboard	React + Vite	Free
Deployment	Railway	$5/month

Total cost at launch: $5/month. Everything else is free until you have paying customers.

Why these specific tools? I've tried the alternatives. Supabase beats Firebase for API businesses because relational data (users → keys → usage logs) is natural in Postgres and painful in document stores. Express beats Next.js for API servers because you don't need SSR, file-based routing, or React Server Components — you need a fast request-response pipeline. Upstash Redis beats Postgres for rate limiting because checking a counter needs to be sub-millisecond, not 5-20ms.

The Middleware Chain

This is the architecture pattern that makes everything work. Every API request passes through a chain of middleware before it hits your business logic:

Request arrives
  → validateApiKey    (reject if invalid)
  → rateLimit         (reject if over per-minute limit)
  → trackUsage        (reject if monthly quota exceeded)
  → YOUR LOGIC        (do the actual work)
Response sent

By the time your route handler runs, you know three things: the key is valid, the request is within rate limits, and the monthly quota hasn't been exceeded. Your business logic never checks any of this. The middleware guarantees it.

API Keys: The Pattern Everyone Skips

Most tutorials use Bearer tokens for API auth and move on. That doesn't work for a business. Your customers need to generate keys from a dashboard, name them, revoke them, and see when they were last used.

The security model matters:

Never store raw keys. Store a SHA-256 hash. When a request comes in, hash the provided key and look up the hash.
Show the key once. After generation, you only show a masked preview like sk_live_abc...xyz. Lost key? Generate a new one.
Use a recognizable prefix. sk_live_ tells GitHub's secret scanning that this is a credential. A leaked prefixed key gets caught before it causes damage.

import crypto from 'crypto';

const PREFIX = 'sk_live_';

function generateApiKey() {
  const random = crypto.randomBytes(32).toString('hex');
  const raw = `${PREFIX}${random}`;
  const hash = crypto.createHash('sha256')
    .update(raw).digest('hex');
  return { raw, hash };
}

256 bits of entropy. The same pattern Stripe and OpenAI use.

Rate Limiting: The Sliding Window

A fixed window rate limiter resets at the top of every minute, which means a customer can send their full quota at 0:59 and again at 1:01 — effectively doubling their rate. The sliding window counts the actual last 60 seconds from right now.

Four Redis commands, one pipeline, one network round-trip:

async function checkRateLimit(apiKeyId, maxPerMinute) {
  const key = `ratelimit:${apiKeyId}`;
  const now = Date.now();
  const windowStart = now - 60000;

  const pipe = redis.pipeline();
  pipe.zremrangebyscore(key, 0, windowStart); // remove old
  pipe.zadd(key, now, `${now}`);              // add current
  pipe.zcard(key);                            // count window
  pipe.expire(key, 60);                       // auto-cleanup

  const results = await pipe.exec();
  const count = results[2][1];
  return {
    allowed: count <= maxPerMinute,
    remaining: Math.max(0, maxPerMinute - count),
  };
}

Then set the standard headers on every response — not just 429s:

X-RateLimit-Limit — max per minute for this tier
X-RateLimit-Remaining — requests left in window
X-RateLimit-Reset — when the window resets

Your API consumers use these headers to implement client-side backoff. The good ones slow down before they hit the wall.

Stripe Billing: The Four Webhooks That Matter

Stripe sends dozens of event types. You need four:

checkout.session.completed — customer paid. Create the subscription record, upgrade their tier, update all their API keys to the new limits.
customer.subscription.updated — plan change or renewal. Look up the new price, determine the tier, update the database.
customer.subscription.deleted — cancellation. Downgrade to free tier.
invoice.payment_failed — card declined. Flag the account, notify the user.

The critical gotcha: Stripe signs webhooks against the raw request body. If Express parses the body into JSON first, the signature verification fails. Mount your webhook route with express.raw() before express.json():

// This line MUST come before express.json()
app.use('/billing/webhook',
  express.raw({ type: 'application/json' }));
app.use(express.json());

I lost two hours to this bug on my first API. You don't have to.

The Weekend Timeline

Here's how I actually spend the weekend:

Friday evening: Set up the project, install deps, create Supabase project, get a health check endpoint running. 1 hour.

Saturday morning: Auth routes, API key system, validation middleware, first authenticated API call. 3 hours.

Saturday afternoon: Rate limiting in Redis, Stripe billing with all four webhook handlers. 3 hours.

Sunday morning: Usage tracking, React dashboard with five pages (login, overview, keys, usage, billing). 2 hours.

Sunday afternoon: Deploy to Railway, custom domain, write docs, post about it. 2 hours.

Nine hours of building. A live, paid API on the internet.

What I Learned

Price higher than you think. At $9/month you need 111 customers to make $1,000. At $29/month you need 35. At $79/month you need 13. Fewer customers = less support = more time building.

The free tier is a conversion mechanism. A developer integrates your API, their project succeeds, they hit the limit, they upgrade. By then they've written code against your endpoints. Switching costs are real.

Good docs beat good marketing. A developer who can integrate in five minutes becomes a customer. A developer who has to email you a question probably doesn't.

I wrote the full process — all twelve chapters, every code file, the complete middleware chain, the dashboard, deployment, and launch strategy — into a book:

The Solo Developer's Guide to Shipping a Paid API in a Weekend — 82 pages, $29, every line of code is production code.

If you've been sitting on an API idea waiting for the right time to build the billing infrastructure, the right time is this weekend.

I'm Brent Hamlin. I build paid APIs and write about the stack behind them. Find me at dev.to/mr_hamlin.

I Added x402 Payments to Base's Agent Skills — Here's How

Mr Hamlin — Tue, 09 Jun 2026 21:09:24 +0000

If you build agents on Base, two things landed recently that are worth connecting.

First: Base shipped its own Agent Skills. There's now a base/skills repo with consolidated skills that teach an AI agent to connect to Base, deploy contracts, authenticate wallets, and run nodes — installed with one command via Vercel's npx skills CLI.

Second: that CLI is part of a fast-growing, cross-agent ecosystem most crypto devs haven't clocked yet. So this post does two things — explains how npx skills and skills.sh actually work, and shows where the payment layer in Base's skills stops and how to extend it with x402 pay-per-call and batch disbursement.

What `npx skills` actually is

npx skills is an open CLI from Vercel Labs for installing "skills" — modular SKILL.md files that teach an agent a specific capability without stuffing everything into its context window. A few things make it different from what crypto devs usually expect:

GitHub is the registry. There's no central package server. Any public GitHub repo with a SKILL.md at its root is a valid, installable skill. Install with npx skills add owner/repo.
It's cross-agent. The same skill installs into Claude Code, Cursor, Codex, GitHub Copilot, Goose, Windsurf, Gemini, and dozens more. You write once; it works across the agent you (or your users) actually run.
skills.sh is the directory + leaderboard. It ranks skills by real install counts pulled from telemetry, with all-time, trending, and hot lists. There's no editorial submission step — you publish by putting a skill in a repo, and installs surface it.

The format underneath — SKILL.md — is an open spec, which is why Base, Vercel, Anthropic, and a long tail of independent devs all use the same files.

Here's Base's install, for reference:

# Base's official agent skills
npx skills add base/skills --skill build-on-base
npx skills add base/skills --skill base-mcp

build-on-base is a consolidated Base dev playbook; base-mcp wires up a Base MCP server that gives an agent a wallet — sending, swapping, signing, batched calls, balances.

Where Base's skills stop

This is the interesting gap. Base's skills give an agent a wallet and the ability to transact: send a payment, swap a token, sign, batch several calls into one transaction. That's the on-chain action layer, and it's well covered.

What that layer doesn't do is two distinct things the agent economy actually runs on:

Pay-per-call consumption. When an agent needs to buy data or compute — a price feed, a web search, an LLM completion — it needs to pay for that call, per call, without an API key or a billing account. That's x402: the HTTP 402 "Payment Required" status code turned into a machine-readable micropayment handshake. The agent hits an endpoint, gets a 402 with a price, signs a USDC authorization, retries, and gets the data. No signup.
Batch disbursement. "Batched calls" (bundling operations into one tx) is not the same as paying many different recipients in one transaction — payroll, airdrops, contributor payouts, refunds. That's a disbursement primitive, and it's what the Batch Payments for Agents (BPA 1.0) spec standardizes.

Both settle in USDC on Base. Neither is something a wallet-only skill handles. So they're a clean, complementary layer to drop on top of what Base ships.

Adding the payment layer

I published three skills that fill exactly that gap, each its own repo so you install only what you need:

defi-intelligence-x402 — pay-per-call data + market intelligence on Base (prices, oracles, swap quotes, wallet analytics, ENS/Basename)
ai-compute-x402 — pay-per-call AI inference (200+ LLMs, Bittensor, image gen, embeddings, GPU)
agent-payments-x402 — batch payments, payroll, invoicing, escrow (BPA 1.0)

# Pay-per-call data + market intelligence on Base
npx skills add plagtech/defi-intelligence-x402

# Pay-per-call AI inference (200+ LLMs, Bittensor, GPU)
npx skills add plagtech/ai-compute-x402

# Batch payments, payroll, invoicing, escrow (BPA 1.0)
npx skills add plagtech/agent-payments-x402

All three call the Spraay x402 Gateway, which is x402-native end to end — no API keys, no accounts. You fund a wallet with USDC on Base, set one env var, and the x402 client signs and retries payments automatically.

npm install x402-client
export EVM_PRIVATE_KEY=0x...   # wallet holding USDC on Base

Worked example: an agent that prices before it acts

A read call costs a fraction of a cent and needs no key:

import { createClient } from "x402-client";

const client = createClient({
  baseUrl: "https://gateway.spraay.app",
  privateKey: process.env.EVM_PRIVATE_KEY,
});

// Live oracle prices — pays ~$0.008 USDC, automatically
const prices = await client.get("/api/v1/oracle/prices");
// { ETH: 2847.50, BTC: ... }

// Profile a wallet before interacting with it
const profile = await client.get("/api/v1/analytics/wallet?address=0xabc...");

Worked example: pay 50 people in one transaction

This is the disbursement primitive a wallet-only skill can't express:

// Batch-send USDC to many recipients in a single tx
const tx = await client.post("/api/v1/batch/execute", {
  chain: "base",
  token: "USDC",
  recipients: [
    { address: "0xabc...", amount: "10.00" },
    { address: "0xdef...", amount: "25.50" },
    // ...up to your full roster
  ],
});

Estimate first with /api/v1/batch/estimate (≈$0.001) if you want a gas/fee preview before sending.

Why this matters for agents on Base

The mental model is two layers:

Base's skills = the agent has a wallet and can transact.
x402 skills = the agent can pay for each call it makes, and pay many parties at once.

Put them together and you have an agent that can read on-chain state, buy the data and compute it needs per call, and disburse funds — all in USDC on Base, all without a single API key or account. That's most of what an autonomous economic agent actually needs to do a job end to end.

If you're building on Base, the install lines above are the fastest way to try the payment layer. Skills are just SKILL.md files — open them before you install (it takes 30 seconds) and you'll see exactly which endpoints get called and what they cost.

Skills: agent-payments-x402 · defi-intelligence-x402 · ai-compute-x402

Links: Spraay Gateway · Docs / full endpoint catalog · Live gateway traffic · BPA 1.0 spec

📚 Why Every AI Agent Needs a Research Library

Mr Hamlin — Fri, 05 Jun 2026 02:39:03 +0000

Your AI agent just hit a wall.

It needs to look up a chemical compound for a drug interaction check. Or find the latest papers on transformer architectures. Or pull US Census demographics for a market analysis. What does it do?

It hallucinates.

Training data is months or years old. Web searches return noisy HTML, not structured data. And the agent has no way to verify what it "knows" against the actual source of record. For any task that requires factual accuracy — scientific, medical, legal, demographic — the agent is guessing.

This is a solvable problem.

The Research Gap in Agent Infrastructure

Look at what the agent ecosystem has built so far: payment rails, wallet provisioning, DeFi integrations, compute access, communication protocols. These are all critical. But there's a missing layer that nobody's talking about.

Knowledge access.

When a human researcher needs to verify a claim, they check PubMed. When they need a chemical structure, they check PubChem. When they need citation data, they check Crossref. When they need demographic trends, they check the Census Bureau.

AI agents have no equivalent. They're making consequential decisions — medical summaries, investment research, compliance checks, scientific literature reviews — without access to the same authoritative sources that human experts rely on.

That's the gap we just filled.

What We Built

We added a full Research & Reference category to the Spraay x402 gateway — 23 endpoints spanning 7 research domains, all accessible via micropayment (USDC on Base or Solana).

Here's what an agent can now look up on demand:

Language & Definitions — word definitions, synonyms, antonyms, phonetics, and pronunciation audio across 9 languages. The foundation for any agent that processes or generates natural language.

Academic Papers — search across 250 million scholarly works spanning every discipline: physics, biology, computer science, economics, social sciences, humanities, engineering, medicine, law, education. Filter by field, year, author, or ORCID. Pull citation graphs. Track what's trending.

Preprints — the bleeding edge of science. 2.4 million preprints across physics, mathematics, computer science, quantitative biology, quantitative finance, statistics, and economics. These are the papers that haven't been published yet — the ones that move markets and shift research directions.

Scholarly Metadata — 150 million published works with full metadata: journal articles, books, conference papers, and datasets. Citation counts, reference lists, journal info by ISSN. When an agent needs to verify a source exists and check its impact, this is the endpoint.

Chemistry — 110 million chemical compounds with molecular structures, physical properties, safety and toxicity data, and biological assay results. Structural similarity search for finding related compounds. This is the same database that pharmaceutical researchers and chemists use daily.

Biomedical Literature — 36 million papers covering medicine, pharmacology, genomics, neuroscience, public health, and more. Related article discovery for any given paper. When your agent is summarizing medical research or checking drug interactions, this is the authoritative source.

Demographics & Government Data — US Census data by state, county, and zip code: population, income, housing, education, employment. Plus the entire federal open data catalog — transportation, climate, health, agriculture, energy, and crime statistics.

The Endpoint Map

# Dictionary & Language
GET /api/v1/research/dictionary/define        $0.001
GET /api/v1/research/dictionary/synonyms      $0.001
GET /api/v1/research/dictionary/phonetics     $0.001

# Academic Papers (250M+ works)
GET /api/v1/research/papers/search            $0.002
GET /api/v1/research/papers/by-doi            $0.001
GET /api/v1/research/papers/by-author         $0.002
GET /api/v1/research/papers/citations         $0.002
GET /api/v1/research/papers/trending          $0.002

# Preprints (2.4M+ papers)
GET /api/v1/research/preprints/search         $0.002
GET /api/v1/research/preprints/by-id          $0.001
GET /api/v1/research/preprints/recent         $0.002

# Scholarly Metadata (150M+ works)
GET /api/v1/research/scholarly/search         $0.002
GET /api/v1/research/scholarly/by-doi         $0.001
GET /api/v1/research/scholarly/citations-count $0.001
GET /api/v1/research/scholarly/journal-info   $0.001

# Chemistry (110M+ compounds)
GET /api/v1/research/chemistry/compound       $0.002
GET /api/v1/research/chemistry/similarity     $0.002
GET /api/v1/research/chemistry/bioactivity    $0.002

# Biomedical (36M+ papers)
GET /api/v1/research/biomedical/search        $0.002
GET /api/v1/research/biomedical/by-pmid       $0.001
GET /api/v1/research/biomedical/related       $0.002

# Demographics & Government Data
GET /api/v1/research/demographics/census      $0.001
GET /api/v1/research/demographics/datasets    $0.001

Every response returns a unified JSON envelope with the source, license info, attribution, and a consistent result structure — regardless of which domain the query hits. One integration, every domain.

Where the Demand Is

These aren't hypothetical use cases. This is what agents are already trying to do, badly, with web scraping and hallucination:

Pharmaceutical & biotech agents — compound lookup, drug interaction screening, literature review across 36M biomedical papers. An agent advising on drug safety needs PubChem and PubMed, not a Google search.

Academic writing assistants — paper discovery, citation graph traversal, related work identification. Every grad student's AI assistant needs structured access to the scholarly record.

Market research agents — Census demographics for TAM sizing, government datasets for industry analysis, trend tracking across academic publications for emerging technology identification.

Fact-checking and verification — DOI lookup confirms a source actually exists. Citation counts indicate impact. Cross-referencing preprints against published papers catches retractions and updates.

Scientific monitoring — agents that watch arXiv daily for new preprints in specific categories, track citation velocity on key papers, and flag when a trending paper crosses a threshold.

Compliance and regulatory — biomedical literature search for adverse event signals, chemical safety data for REACH/GHS compliance, demographic data for fair lending analysis.

The pattern is the same in every case: the agent needs structured, authoritative, verifiable data — not a web search result. And it needs it on demand, per call, without managing API keys and parsing 7 different response formats.

One Gateway, Every Domain

The value proposition for agent builders is simple: integrate once with Spraay, and your agent gets access to the same research infrastructure that universities and pharmaceutical companies use. Pay per call. No subscriptions, no rate limit negotiations, no format wrangling.

The research endpoints sit alongside 115 existing endpoints on the gateway covering payments, DeFi, oracle, compute, communication, and more — 138 total across 34 categories. If your agent needs to look something up and take action on what it finds, the entire stack is already wired together.

The gateway is live at gateway.spraay.app. The MCP server on Smithery has all the tools pre-wired for Claude, GPT, and any MCP-compatible agent framework.

Docs: docs.spraay.app
GitHub: plagtech/spraay-x402-gateway
Twitter: @Spraay_app

Agents that know things make better decisions than agents that guess. Give yours a library card.

Batch Payments for Agents (BPA) 1.0: an open standard for how AI agents pay many recipients at once

Mr Hamlin — Tue, 02 Jun 2026 20:22:14 +0000

Agents can now act. They book, they buy, they call tools, they spend. But ask a simple question — how does an autonomous agent pay 500 people in one go? — and there's no clean answer. There's a pile of one-off integrations and a lot of hand-waving.

So we wrote the spec. Batch Payments for Agents (BPA) 1.0 is a framework-neutral, open standard for how an agent disburses funds to many recipients in a single, governed, verifiable batch. It's live and citable here:

👉 docs.spraay.app/bpa/1.0 · source: github.com/plagtech/bpa-spec

This post is the why and the what.

The payments agents actually need are the ones the old rails punish

Card and bank networks are optimized for a human clicking checkout once. Agent payouts are the opposite shape, and they break the cost model in three specific ways:

Micro-amounts. Paying a crowd of data labelers $0.50 a task dies on fixed fees.
Machine-initiated. No human at checkout, no card-present flow, no chargeback dance.
One-to-many, global. Pay 200 contributors at once, many cross-border or unbanked, and settle in seconds.

Stablecoins on fast chains solve the rail. What's missing is the contract — the agreed-upon shape of "an agent safely pays many recipients at once." Without it, every team rebuilds the same fragile logic: how do you make a batch idempotent? what happens when line 347 of 500 fails? how do you prove it settled? how do you stop a misbehaving agent from draining a treasury?

BPA answers those questions once, so nobody has to answer them again.

What BPA 1.0 actually defines

The spec is deliberately boring in the way good infrastructure is boring. It nails down:

A request format — one Disbursement Request object, with a JSON Schema you can validate against.
Idempotency — replay-safe by construction, because batch disbursement is irreversible.
Partial-failure semantics — atomic by default; if a rail can't be atomic, per-recipient results and a retry token scoped to only the failed lines.
Settlement confirmation — verifiable on-chain, per-chain finality rules, no "trust me, it sent."
A governance model — spend caps, recipient allowlists, approval gating, and tamper-evident audit, all evaluated before settlement and failing closed.
Transparent fees, transport bindings (x402 / MPP), and an MCP tool shape.

Here's the core object an agent constructs:

{
  "bpa_version": "1.0",
  "idempotency_key": "payout-2026-06-02-001",
  "chain": "eip155:8453",
  "asset": "USDC",
  "recipients": [
    { "address": "0xAbc...", "amount": "5000000", "ref": "worker-001" },
    { "address": "0xDef...", "amount": "5000000", "ref": "worker-002" }
  ]
}

Amounts are integer base units (no float drift). Validate it against the published JSON Schema before you send.

Three design choices worth calling out

Non-custodial end to end. The facilitator only builds the transaction; the agent's own signature authorizes the spend. The gateway never holds funds. That single property collapses a whole class of security concerns — a forged request just produces an unsigned transaction nobody can submit.

Governed before execution, not after. BPA treats every disbursement as a high-risk action. The goal isn't to ask an agent to behave — it's to make an out-of-policy payout structurally impossible. Caps, allowlists, and approvals are deterministic checks the request must pass before a single token moves. If policy can't be evaluated, the answer is "denied."

Three chains, on purpose. BPA 1.0 is normatively defined for Base, Ethereum, and Solana — where agent payment activity actually concentrates, plus institutional reach. We run the reference contract on more chains, but a spec's credibility is its weakest claim. Everything in the normative body is mainnet and source-verified (the settlement contracts are verified, exact-match, on BaseScan and Etherscan). Breadth that isn't load-bearing is just surface area for doubt.

Try it

Spraay is the reference implementation (full disclosure: it's ours, and writing the spec forced us to make it airtight). You can hit it two ways:

HTTP / x402: POST https://gateway.spraay.app/api/v1/batch/execute — returns an unsigned transaction for your agent to sign.
MCP: the spraay_batch_execute tool, published on Smithery as @plagtech/spraay-x402-mcp, described by intent so your agent matches it at runtime.

The on-chain protocol fee is 0.30%, with a 200-recipient cap per call (chunk larger batches under one idempotency key).

It's an open standard — build on it

BPA is published under CC-BY-4.0. Implementations are unrestricted and need no permission. There's a conformance checklist (§14) and a self-attestation format for any facilitator — not just ours — to claim conformance. If you're building agent infrastructure and you touch payouts, this is meant to be the reference you point your own tooling at.

If the attestation model for task-gated payments (pay-on-approval) is something you have strong opinions about, that's the one piece explicitly scoped for 1.1 — open an issue.

Spec: docs.spraay.app/bpa/1.0
Repo: github.com/plagtech/bpa-spec
Reference gateway: gateway.spraay.app

Agents are going to move a lot of money in small pieces to a lot of people. Let's at least agree on how.

Compute Futures for AI Agents: Prepaid GPU and Inference Credits over x402

Mr Hamlin — Tue, 02 Jun 2026 01:04:03 +0000

There's a growing conversation about treating compute like a tradable commodity — something you can price, prepay, and hold, not just rent by the second. It's an interesting macro idea for data centers and GPU clusters. But there's a much more immediate version of it that nobody talks about: what does an AI agent do when it needs to buy compute, over and over, without a credit card or an API key?

That's the gap I built Spraay Compute & Futures to close.

The problem with paying retail for every inference call

Pay-per-call micropayments are great for one-off jobs. An agent hits an endpoint, gets a 402 Payment Required, signs a USDC authorization, retries, gets its result. Clean. This is exactly what x402 was built for, and it works.

But agents don't run one job. They run workloads — a research agent fires off hundreds of inference calls, a content pipeline generates dozens of images, a RAG system embeds thousands of chunks. Two things break down at that volume:

No budget predictability. Every call is a fresh signature and a fresh settlement. There's no way to say "this agent has $50 to spend on compute this week" and have the rails enforce it.
No volume pricing. You pay the same per-call rate whether it's your first request or your ten-thousandth. In every other market, buying in bulk gets you a discount. Agentic compute had no equivalent.

The usual fix is accounts and API keys with prepaid balances — exactly the thing x402 was supposed to kill. So the question became: can you get prepaid, discounted compute without reintroducing accounts?

Compute futures: prepay once, draw down per job

The answer is a prepaid compute-credit account that lives entirely on x402 rails. You deposit USDC once, get a credit balance with a tier discount baked in, and then run jobs against that balance. No per-call payment for the compute itself — each job just deducts from your credits at the discounted rate. Refund whatever you don't use.

The tiers are simple:

$10+ → 5% off
$50+ → 10% off
$200+ → 15% off

The whole lifecycle is three calls:

import { wrapFetchWithPayment } from "@x402/fetch";
const fetchPay = wrapFetchWithPayment(fetch, wallet);
const BASE = "https://gateway.spraay.app";

// 1. Open a $50 account — lands in the 10% tier ($0.01 to set up)
const acct = await fetchPay(`${BASE}/api/v1/compute-futures/deposit`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ depositor: "0xYourAgentWallet", amount: "50" }),
}).then(r => r.json());

const futuresId = acct.computeFuture.id; // "CFE-ABC12345"

// 2. Run jobs against the balance — $0.001 settlement, discount applied
const job = await fetchPay(`${BASE}/api/v1/compute-futures/execute`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    futuresId,
    type: "text-inference",
    messages: [{ role: "user", content: "Summarize this filing: ..." }],
  }),
}).then(r => r.json());
// → { billing: { charged: "$0.027", balanceRemaining: "$42.473 USDC" },
//     compute: { model: "Llama 3.3 70B" } }

// 3. Refund the unused balance anytime (depositor-only)
await fetchPay(`${BASE}/api/v1/compute-futures/refund`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ futuresId, caller: "0xYourAgentWallet" }),
});

That execute call is the key move. The agent isn't signing and settling a payment for the inference — it already paid, in bulk, at a discount. It's just spending credits. You get budget predictability (the balance is the budget) and volume pricing, without a single API key.

What you can actually run

The same account works across the whole compute surface — text, images, video, audio, embeddings:

Capability	Models
LLM inference	11 models, 3B–405B (Chutes AI / Bittensor SN64, OpenRouter)
Image generation	FLUX Schnell/Dev/Pro, SDXL
Video generation	MiniMax Video 01, Wan 2.1
Speech-to-text	Whisper Large V3, 100+ languages
Text-to-speech	voice synthesis
Embeddings	for RAG and semantic search

And if you'd rather just pay per call — no prepayment — every one of those is also a direct x402 endpoint (LLM inference at $0.03, GPU run at $0.06, embeddings at $0.005, and so on). There's a free /compute/estimate to price a job before you commit, and a free /compute/models to list what's available.

Why x402 makes this work

The reason prepaid compute credits don't require accounts is that the wallet is the account. Settlement is USDC on Base mainnet and Solana mainnet, verified through the x402 facilitator. The depositor address owns the credit balance; only that address can spend it or refund it. No login, no key rotation, no dashboard — the same primitives that make per-call x402 work also make prepaid balances work, just with the payment moved up front.

It's a small idea with a real consequence: an autonomous agent can now hold a compute budget the way a team holds a cloud-credit balance, except it's permissionless, refundable, and settles in two seconds.

Drop it into your agent

It's packaged as a skill, so any agent can install it:

# OpenClaw / ClawHub
npx clawhub install spraay-compute

# Claude Code, Cursor, Codex, Gemini CLI (Vercel Skills CLI)
npx skills add plagtech/spraay-compute

The skill ships the full endpoint reference and runnable examples, so the agent knows exactly which endpoint to call, what it costs, and how to handle async jobs.

Repo: https://github.com/plagtech/spraay-compute
Gateway: https://gateway.spraay.app
Discovery manifest: https://gateway.spraay.app/.well-known/x402.json

If you're building agents that run real compute workloads, prepaying for a discount beats paying retail on every call. Open an account, run your jobs, refund the rest.

BlackRock's CEO just called compute one of the next major markets. Here's why Spraay Protocol is already there.

Mr Hamlin — Wed, 27 May 2026 23:11:09 +0000

The Signal No One Should Ignore

When Larry Fink — the man who oversees $10 trillion in assets — tells the world that compute is becoming a financial instrument on par with equities and bonds, that's not speculation. That's a roadmap.

And it's a roadmap we've been building on for months.

At Spraay Protocol, we didn't wait for BlackRock to validate the thesis. We've been operating at the intersection of AI compute, machine-to-machine payments, and on-chain settlement since before the phrase "compute economy" entered the mainstream vocabulary. What Fink described as the future is, for us, already in production.

The Problem Everyone Sees but Nobody Has Solved

Here's the reality of AI compute right now: it's bought in bulk, priced opaquely, walled behind platform lock-in, and completely disconnected from the financial rails that every other commodity trades on.

If you're an AI agent — and there will be millions of them — you can't call up a cloud provider and negotiate a rate. You can't hedge against a price spike during peak inference demand. You don't have a treasury function. You don't have a credit line.

You just pay whatever you're charged, whenever you're charged, and hope for the best.

That's not how real markets work. Real markets have price discovery. Real markets have futures. Real markets have settlement infrastructure.

Spraay is that infrastructure.

What We Actually Built

Spraay Protocol is a multi-chain x402 payment gateway — the protocol Coinbase introduced that lets machines pay other machines at the HTTP layer. Every API call, every inference request, every data retrieval can carry a payment natively. No invoices. No subscriptions. No human in the loop.

We took that foundation and built what the compute economy actually needs:

Compute Futures and Escrow. Prepaid credit systems with tiered pricing that let agents and developers lock in compute costs ahead of time. When inference demand spikes — and it will — our users have already secured their capacity at yesterday's price.

115 live paid endpoints across 33 categories. This isn't a whitepaper. This is production infrastructure spanning AI inference, on-chain data, oracles, messaging, storage, and more — all payable via x402 on 13+ chains.

Batch payment infrastructure. Enterprise-grade payroll and multi-recipient disbursement, because the compute economy doesn't run on one-to-one transactions. It runs on networks paying networks.

An MCP server with 120 tools. Direct integration into the AI agent ecosystem — LangChain, CrewAI, AutoGPT, and beyond. Agents don't just use Spraay. They think with it.

Why x402 Is the Payment Rail for Compute

The genius of x402 is its simplicity. An HTTP 402 status code has always meant "payment required." Coinbase's protocol made it machine-readable. Spraay made it machine-complete.

Think about what this means for the compute market Fink is describing. Every inference endpoint becomes a tradeable unit. Every API call carries provable settlement. Every agent has a native way to pay for the resources it consumes — across any chain, at any scale, without a single human approving a transaction.

This isn't DeFi trying to reinvent finance. This is finance's existing logic — futures, escrow, settlement, clearing — implemented natively for the first commodity that was born digital.

Compute didn't need to be tokenized. It needed to be transactable. That's what we provide.

The Landscape Is Moving Our Way

Look at the signals beyond Fink's statement:

AI agent frameworks are proliferating. Every major tech company is building autonomous systems that need to procure their own resources. The conversation has shifted from "will agents handle money?" to "how do we make agent payments safe and efficient?"

The x402 ecosystem is growing. Coinbase shipped the protocol. Developers are building on it. And Spraay has been in the room since day one — not observing, but operating. We have the most comprehensive x402 gateway in production. That's not a claim we make lightly. Count the endpoints. Count the chains. Count the categories.

On-chain settlement is being taken seriously by institutions that dismissed it two years ago. When the world's largest asset manager starts drawing parallels between compute and traditional commodities, the infrastructure question becomes urgent. Who settles these transactions? On what rails? With what guarantees?

We have answers. Live ones.

What Comes Next

We're not slowing down. The Spraay roadmap is built around a simple conviction: the compute economy will be the largest machine-to-machine market in history, and it will need payment infrastructure that's as fast, programmable, and autonomous as the agents that run on it.

That means deeper futures and hedging primitives. More chains. More endpoints. Tighter integrations into every major agent framework. And continued leadership in the x402 space — not because we want the title, but because we've earned it by building while others were still debating.

The capital is coming. Fink said so. The infrastructure has to be ready.

It already is.

💧 Spraay Protocol — Multi-chain x402 payment gateway and compute settlement infrastructure.

🌐 spraay.app · ⚡ Live Gateway · 🐦 @Spraay_app · 📡 MCP Server on Smithery

If you're building AI agents that need to pay for compute, we should talk.

Spraay Brings Batch Payments to Canton Network Amid Wall Street Tokenization Push

Mr Hamlin — Mon, 25 May 2026 00:38:46 +0000

Spent the last few days adding Canton Network support to Spraay Protocol's batch payment infrastructure. It's chain 16 for Spraay, and the most interesting one we've integrated to date — for reasons that have less to do with us and more to do with where Canton is going.

The Canton context

If you've been heads-down in crypto Twitter, Canton is easy to miss. While most of the EVM ecosystem has been arguing about L2 fragmentation, Canton has quietly become the rail of choice for serious institutional tokenization. The numbers are real:

DTCC — which clears the vast majority of U.S. securities and custodies $114T in assets — partnered with Digital Asset in December 2025 to tokenize DTC-custodied U.S. Treasuries on Canton, with broader rollout through 2H 2026
JPMorgan's Kinexys is deploying JPM Coin natively on Canton in phases throughout 2026
Broadridge's distributed ledger repo platform, running on Canton rails, already processes $4 trillion monthly in overnight Treasury financing
Goldman Sachs, BNY Mellon, BNP Paribas, HSBC, Euroclear, S&P Global, Nasdaq are all participants
Network-wide: ~$6T in tokenized real-world assets across 600+ institutions, ~500K daily transactions

This is a network built for the financial plumbing layer most crypto-native builders don't think about every day. And it's already running.

Where batch payments fit

Most of Spraay's chains are payment-rail-first: send USDC to N recipients, take a 0.3% protocol fee, optimize gas. That story translates cleanly to retail and to agent-driven commerce (we've leaned hard into x402-style agent payments).

Canton is different. Holdings are UTXO-style. Transfers go through Splice's Token Standard via a TransferFactory_Transfer choice on the global synchronizer. Instruments are admin-scoped — the DSO party admins Canton Coin, but any institution issuing on Canton (a tokenized Treasury, a deposit token, a fund share) can be its own instrument admin.

So a batch payment primitive that works against Token Standard isn't "competing with DTCC." It's a small piece of utility infra that any app building on Canton can compose with — programmatic disbursements, fund flows between sub-accounts, payroll, agent-driven micropayments — whether the instrument is Canton Coin today or a tokenized money-market fund share tomorrow.

What's live

github.com/plagtech/spraay-canton runs against the cn-quickstart LocalNet. It exposes a REST API for batch payments, queries holdings via the Token Standard Holding interface, fetches the TransferFactory from the Scan-hosted registry, executes one TransferFactory_Transfer per recipient, and collects the protocol fee through a second transfer to the operator party. Same shape as every other Spraay chain — just spoken in Daml.

The repo is open, the integration is small, and the door's open if anyone building on Canton wants payment primitives or just wants to compare notes.

Spraay now spans 16 chains. The interesting part isn't the count — it's that the span now goes from retail-facing chains all the way to the network where institutional tokenization is being built. That's a different kind of map than it was last year.

Spraay just introduced new endpoints for Solana Agents.

Mr Hamlin — Sat, 16 May 2026 00:34:34 +0000

If you've built a Solana DeFi agent recently, you know the shape of the work.

You write a quote function. It calls Jupiter directly because that's where the liquidity is. Then you need wallet holdings, so you sign up for Helius and stick a key in .env. Then you need price feeds, so you wire up Pyth Hermes. Three providers, three rate limits, three sets of error semantics, three keys to rotate. Your agent does six interesting things and you're managing eight pieces of infrastructure.

I've been building Spraay — an x402 gateway — for several months, and as of today it speaks Solana DeFi natively. Six new endpoints, one gateway, payable per call in USDC. If you're somewhere in the middle of writing the agent I just described, this might save you a weekend.

What's new

GET  /api/v1/solana/jupiter/quote         $0.005
POST /api/v1/solana/jupiter/swap-tx       $0.01
GET  /api/v1/solana/helius/assets-by-owner $0.003
GET  /api/v1/solana/helius/asset          $0.002
GET  /api/v1/solana/pyth/price            $0.005
GET  /api/v1/solana/pyth/prices           $0.008

All six are pure proxies to the real upstream — Jupiter v6, Helius DAS, Pyth Hermes. No synthetic data, no mock responses. Spraay does payment, validation, error normalization, and Bazaar discovery. Your agent does everything else.

What you don't deal with

No accounts. No signup, no email confirmation, no dashboard. Your agent's wallet is its identity.
No API keys. Payment is the auth. You pay $0.005, you get the response.
No bridging. Pay in either Solana USDC (SPL) or Base USDC (ERC-20). Spraay accepts both on every endpoint. Useful when your agent already has USDC on Base from doing other things.
No upstream rate-limit babysitting. Spraay holds the paid tier with Helius and Jupiter. You see clean 402s on success, 429 with retryAfter if upstream rate-limits us.
No custody risk on swaps. Jupiter swap-tx returns an unsigned VersionedTransaction. Your wallet signs and submits. The gateway never touches keys.

Working code

The integration that took me three days to do raw, ported to Spraay in about twenty minutes. The example below uses pseudocode for the payment client — drop in whatever x402 client you're already using:

import { VersionedTransaction, Connection } from "@solana/web3.js";

// Your x402 client of choice — handles the 402 → pay → retry flow
const client = makeX402Client({
  baseUrl: "https://gateway.spraay.app",
  // Pay in Solana USDC, Base USDC, or both — your call
  solanaPrivateKey: process.env.SOLANA_PRIVATE_KEY,
});

const connection = new Connection(process.env.SOLANA_RPC_URL!);

// 1. Read the agent's wallet — SPL tokens, NFTs, native SOL balance, paginated
const holdings = await client.get(
  "/api/v1/solana/helius/assets-by-owner" +
  `?owner=${myWallet.publicKey.toBase58()}&limit=100`
);
console.log(`Wallet holds ${holdings.total} assets, ${holdings.nativeBalance.lamports / 1e9} SOL`);

// 2. Pull live prices for the agent's watchlist in one call
const prices = await client.get(
  "/api/v1/solana/pyth/prices?feedIds=SOL,BTC,ETH,JUP,BONK"
);
const solPrice = prices.prices.SOL.price;  // e.g. 142.37
const solConfidence = prices.prices.SOL.confidence;  // ± confidence interval

// 3. Quote a swap
const quote = await client.get(
  "/api/v1/solana/jupiter/quote" +
  "?inputMint=USDC&outputMint=SOL&amount=10000000&slippageBps=50"
);
console.log(`10 USDC → ${Number(quote.outAmount) / 1e9} SOL via ${quote.routeHops}-hop route`);

// 4. Build the unsigned transaction
const swap = await client.post("/api/v1/solana/jupiter/swap-tx", {
  quoteResponse: quote.raw,
  userPublicKey: myWallet.publicKey.toBase58(),
  prioritizationFeeLamports: "auto",
});

// 5. Sign and submit yourself — gateway never sees the key
const tx = VersionedTransaction.deserialize(
  Buffer.from(swap.swapTransaction, "base64")
);
tx.sign([myWallet]);
const sig = await connection.sendTransaction(tx);
console.log(`Swap submitted: https://solscan.io/tx/${sig}`);

Five operations, four endpoints, one payment rail. The agent pays the per-call cost out of its own wallet, gas-of-the-API-economy style.

Endpoint details, quickly

Jupiter

/quote wraps quote-api.jup.ag/v6/quote (or api.jup.ag/swap/v1/quote on the paid tier — Spraay holds the key). Returns route plan, slippage, output amount, price impact. Accepts symbol aliases (USDC, SOL, BONK, WIF, JUP, etc.) or raw base58 mints.

/swap-tx wraps the /swap endpoint. Returns a base64-encoded VersionedTransaction. Pass the raw quoteResponse from /quote and your userPublicKey. Optional: wrapAndUnwrapSol, prioritizationFeeLamports. Gateway never signs.

Helius DAS

/assets-by-owner wraps getAssetsByOwner. Returns SPL tokens, regular NFTs, compressed NFTs, and native SOL balance in one paginated response. Default limit=100, max 1000. showFungible and showNativeBalance both default true.

/asset wraps getAsset. Returns full metadata for a single asset by mint or compressed NFT ID — image, attributes, royalty info, compression details, ownership.

Pyth

/price wraps Hermes /v2/updates/price/latest for one feed. Returns the human-readable price (already scaled by expo), confidence interval, publish time, and EMA price. Symbol aliases for the obvious ones (SOL, BTC, ETH, USDC, USDT, JUP, PYTH, BONK, WIF, JTO) or pass the 64-char hex feed ID.

/prices is the batch version. Up to 50 feeds, comma-separated. Returns a { symbol: priceObject } map keyed by uppercase symbol.

Trying it before you integrate

Every endpoint returns a clean 402 Payment Required with full x402 payment requirements when you call without paying. You can see the schema, pricing, and accepts arrays directly:

curl -i "https://gateway.spraay.app/api/v1/solana/pyth/price?feedId=SOL"

The 402 body includes both EVM and Solana payment options. Your x402 client picks the rail.

If you want to see all six (plus the rest of Spraay's catalog) in Bazaar-discoverable form:

curl -s "https://gateway.spraay.app/.well-known/x402.json" | jq '.resources[] | select(.resource | contains("/solana/"))'

Error handling notes worth knowing

A few things that will save debugging time:

429 rate_limit means we're being rate-limited by an upstream provider. Response includes retryAfter in seconds. Backoff and retry.
502 upstream_error from any endpoint means the upstream returned a non-2xx. The body contains the actual upstream error in detail. Useful for debugging slippage tolerance, missing feeds, etc.
400 invalid_input_mint etc. are pre-flight validation failures. Spraay never charges you if validation fails before the upstream call.
Pyth feed IDs are case-sensitive hex. If you're not using aliases, lowercase everything or use the alias map.

The First Batch Payment Skill for Vercel Agents (skills.sh)

Mr Hamlin — Fri, 15 May 2026 20:59:21 +0000

Spraay Protocol just shipped as a Vercel-compatible agent skill. One command gives any AI coding agent the ability to batch-send crypto to hundreds of recipients in a single transaction — across 15 blockchains.

npx skills add plagtech/spraay-agent-skills

That's it. Claude Code, Cursor, GitHub Copilot, Codex, Gemini CLI, and 12+ other agents can now build batch payment workflows using Spraay.

What problem does this solve?

Sending crypto to multiple people is painful. Whether it's payroll for a remote team, an airdrop for a token community, bounty payouts for contributors, or a DAO treasury distribution — the standard approach is sending individual transactions one at a time.

That means paying gas on every single transfer, manually entering each address, and hoping you don't make a mistake on transaction 47 of 200.

Spraay bundles all of those into one on-chain transaction. Up to 200+ recipients, ~80% gas savings, 0.3% protocol fee.

Why an agent skill?

AI agents are increasingly handling real workflows — not just answering questions, but taking actions. An agent managing a DAO treasury should be able to say "distribute 10,000 USDC across these 50 contributors" and execute it.

Vercel recently launched their Skills CLI and skills.sh directory — an open ecosystem for packaging capabilities that any AI agent can install and use. Skills are simple: a SKILL.md file teaches the agent what the tool does, when to use it, and how to call it. No SDKs to integrate, no code to write.

When an agent reads the Spraay skill, it knows:

How to call the batch payment gateway
Which 15 chains are supported
What the request format looks like
How the 0.3% fee works
That it should always confirm with the user before signing

The agent becomes payment-capable in one install.

What's covered

The skill focuses on one thing: batch payments. Five types:

Native token batches — ETH, SOL, MATIC, BNB, AVAX, XLM, XRP, BTC, TAO, STX
ERC-20 / SPL token batches — USDC, DAI, WETH, or any token contract
Equal-amount batches — same amount to every recipient
Variable-amount batches — different amounts per recipient
CSV import batches — upload a spreadsheet of addresses and amounts

15 chains, real contracts

Every EVM chain has a verified, deployed batch contract:

Chain	Contract
Base	`0x1646452F98E36A3c9Cfc3eDD8868221E207B5eEC`
Ethereum	`0x15E7aEDa45094DD2E9E746FcA1C726cAd7aE58b3`
Arbitrum	`0x5be43aA67804aD84fcb890d0AE5F257fb1674302`
Polygon	`0x6d2453ab7416c99aeDCA47CF552695be5789D7ff`
BNB Chain	`0x3093a2951FB77b3beDfB8BA20De645F7413432C1`
Avalanche	`0x6A41Fb5F5CfE632f9446b548980dA6cE2d75afcC`
Unichain	`0x08fA5D1c16CD6E2a16FC0E4839f262429959E073`
Plasma	`0x08fA5D1c16CD6E2a16FC0E4839f262429959E073`
BOB	`0xEc8599026AE70898391a71c96AA82d4840C2e973`

Plus non-EVM chains with chain-native implementations: Solana (SPL batch), Stellar (multi-operation), Bitcoin (PSBT), XRP Ledger (sequential payments), Bittensor (utility.batchAll), and Stacks (Clarity contract).

These aren't testnet demos. They're live, verified contracts handling real value.

How the gateway works

The Spraay gateway at gateway.spraay.app uses the x402 payment protocol — the HTTP 402 standard that Coinbase helped pioneer for machine-to-machine payments.

The flow is simple:

Agent sends a batch request to the gateway
Gateway returns unsigned transaction data bundling all transfers
User reviews and signs in their wallet
All recipients get paid in one on-chain transaction

Gateway access costs $0.02 USDC per call, paid automatically via x402 on Base. No API keys, no accounts, no subscriptions.

Quick integration

import { createClient } from "x402-client";

const client = createClient({
  baseUrl: "https://gateway.spraay.app",
  privateKey: process.env.EVM_PRIVATE_KEY
});

const tx = await client.post("/api/v1/batch/execute", {
  token: "USDC",
  recipients: [
    { address: "0xAlice", amount: "100.00" },
    { address: "0xBob", amount: "50.00" },
    { address: "0xCarol", amount: "25.00" }
  ]
});

Or skip the code entirely — users can batch-send at spraay.app by connecting their wallet and adding recipients or uploading a CSV.

Where this fits in the Vercel ecosystem

Vercel's agent skills ecosystem is growing fast. There are skills for React best practices, deployment automation, and web design guidelines. Crypto is starting to show up — Crypto.com published a trading skill, and community repos are covering DeFi yield and sentiment analysis.

But nobody had batch payments. It's a gap that matters because every on-chain organization eventually needs to pay multiple people, and doing it manually doesn't scale.

Spraay fills that gap with deployed infrastructure across 15 chains, not a wrapper around someone else's API.

Try it

Install the skill:

npx skills add plagtech/spraay-agent-skills

Or use the dApp directly: spraay.app

Full gateway docs: docs.spraay.app

The MCP server is also on Smithery if you're building with MCP-compatible agents: @plagtech/spraay-x402-mcp

Spraay Protocol is built by @plagtech. Follow @Spraay_app for updates.

💧 Spraay x402 Gateway Now Accepts Solana USDC — Dual-Chain AI Agent Payments Are Live

Mr Hamlin — Wed, 13 May 2026 04:27:37 +0000

Your AI agent holds USDC on Solana. The API it needs to call takes payment on Base. Until today, that meant bridging, swapping, or just not making the call.

Not anymore.

What We Shipped

The Spraay x402 Gateway — 93+ paid endpoints covering AI inference, batch payments, DeFi, oracle data, escrow, payroll, robotics, supply chain, and more — now accepts USDC on both Base and Solana mainnet through the official x402 protocol.

Every gated endpoint returns a 402 challenge with two accepts entries. The agent picks whichever chain it holds funds on. No bridging, no extra steps.

{
  "accepts": [
    {
      "scheme": "exact",
      "price": "$0.008",
      "network": "eip155:8453",
      "payTo": "0xAd62f03C7514bb8c51f1eA70C2b75C37404695c8"
    },
    {
      "scheme": "exact",
      "price": "$0.008",
      "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
      "payTo": "8WhWE8YgY5QBWyLowEHuaZiWdwDM3SrgDk36xYBNvYNS"
    }
  ]
}

Three Payment Rails, One Gateway

The gateway now supports three concurrent payment methods on every route:

1. x402 EVM (Base) — The original rail. Coinbase CDP facilitator handles verification and settlement. Sub-cent gas on Base.

2. x402 SVM (Solana) — New. Uses the official @x402/svm SDK with ExactSvmScheme. Same Coinbase facilitator. 400ms finality, ~$0.00025 tx fees. Fully compatible with pay.sh, xpay, and every x402 client.

3. Custom Solana (X-Solana-Tx header) — A direct SPL USDC transfer fallback. Agent sends USDC to the receive address, retries with the tx signature in a header, gateway verifies on-chain via @solana/web3.js. Works for agents that don't speak x402.

All three are active simultaneously. None interfere with each other.

How It Works (Agent Perspective)

Agent calls GET /api/v1/oracle/prices
  → Gateway returns 402 with accepts[] (Base + Solana)

Agent inspects accepts[], picks solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp
  → Signs USDC transfer authorization

Agent retries with X-PAYMENT header containing signed payload
  → Coinbase facilitator verifies + settles on Solana
  → Gateway returns 200 with oracle data

The entire flow is one round-trip after the initial 402. No accounts, no API keys, no subscriptions.

Discovery Endpoints

Agents can auto-discover payment options at:

/.well-known/x402.json — Full resource catalog with pricing
/.well-known/solana.json — Solana-specific payment config
/.well-known/agent-registration.json — Agent framework metadata
/.well-known/mpp.json — MPP/Stripe support (also active)

What's Covered

93+ paid endpoints across 21 categories:

AI Inference — 200+ models via OpenRouter + 43 Bittensor models (SN64)
Batch Payments — Base, Stellar, XRP, up to 200 recipients
DeFi — Swaps, bridge quotes, position tracking
Oracle — Prices, gas, FX rates
Payroll — Crypto payroll execution and estimation
Escrow — Create, fund, release, cancel with milestones
Infrastructure — RPC, IPFS, cron, logging, webhooks
Robotics (RTP) — Dispatch physical tasks to robots via x402
Supply Chain (SCTP) — Suppliers, POs, invoices, AI verification
Agent Wallets — Provision smart contract wallets on Base
And more — KYC, auth, audit, tax, GPU compute, search/RAG, XMTP messaging

All of these now accept payment on Base or Solana.

Technical Implementation

For anyone building a similar dual-chain x402 server, the key pieces are:

import { ExactSvmScheme } from "@x402/svm/exact/server";

// Register both schemes
const server = new x402ResourceServer(facilitatorClient)
  .register("eip155:8453", new ExactEvmScheme());
server.register("solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp", new ExactSvmScheme());

// Each route gets dual accepts
"GET /api/v1/oracle/prices": {
  accepts: [
    { scheme: "exact", price: "$0.008", network: "eip155:8453", payTo: evmAddress },
    { scheme: "exact", price: "$0.008", network: "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp", payTo: solanaAddress },
  ],
}

The Coinbase CDP facilitator handles both EVM and SVM verification — no need to run your own.

Try It

# See the dual-chain 402 challenge
curl https://gateway.spraay.app/api/v1/oracle/prices

# Solana discovery
curl https://gateway.spraay.app/.well-known/solana.json

# With pay.sh (Solana wallet)
pay curl https://gateway.spraay.app/api/v1/oracle/prices?tokens=ETH

Spraay Gateway Now Accepts Credit Cards — 80+ API Endpoints, No Crypto Wallet Required

Mr Hamlin — Fri, 08 May 2026 02:54:47 +0000

I've been building Spraay — a multi-chain payment gateway where AI agents pay per API call using the x402 protocol and USDC on Base. 88 endpoints across AI inference, batch payments, DeFi, oracle data, escrow, robotics, and more.

The x402 model works great for crypto-native developers and autonomous agents. But I kept hearing the same thing from traditional devs:

"This looks useful, but I don't want to set up a wallet and buy USDC just to test your API."

Fair point. So today I'm launching a traditional subscription tier alongside x402 — pay with a credit card, get an API key, start building.

Two Ways to Use Spraay

Pay-per-call (x402) — No signup. Your agent pays USDC per request on Base. This is how autonomous agents use it. Prices range from $0.001 to $0.10 per call depending on the endpoint.

Monthly subscription (Stripe) — Sign up with your email, pay with a card, get an API key emailed to you. Add X-API-Key to your requests and you're in.

Plan	Price	Daily Calls	Endpoints
Pay-per-call	USDC per request	Unlimited	All 80+
Starter	$29/month	1,000/day	All 80+
Pro	$99/month	10,000/day	All 80+

Both paths hit the same endpoints. Same data, same infrastructure, same uptime.

What You Get Access To

Here's a sample of what's behind the gateway:

AI Inference — 200+ models via OpenRouter + 43 models on Bittensor (OpenAI-compatible drop-in)
Batch Payments — Send tokens to 200 recipients in one transaction across 15 chains
DeFi — Swap quotes and execution via Uniswap V3, cross-chain bridge quotes
Oracle — Real-time token prices, gas prices, FX rates
Search/RAG — Web search, content extraction, Q&A with sources
GPU Compute — Image generation, video, audio via Replicate
Agent Wallets — Provision ERC-4337 smart wallets for AI agents
Escrow — Milestone-based conditional escrow contracts
Robot Task Protocol — Dispatch tasks to physical robots via x402
Plus: Payroll, invoicing, KYC, audit trails, XMTP messaging, IPFS storage, cron scheduling, and more Full docs at docs.spraay.app.

How Subscriptions Work

Pick a plan at spraay.app/pricing
Enter your email → redirected to Stripe Checkout
Pay → API key emailed to you instantly
Add X-API-Key: spry_your_key header to any request
That's it — no 402 payment flow, no wallet, no USDC Check your usage anytime:

curl -H "X-API-Key: spry_your_key" https://gateway.spraay.app/v1/auth/usage

Rotate your key if compromised:

curl -X POST -H "X-API-Key: spry_your_key" https://gateway.spraay.app/v1/auth/rotate

Manage billing through Stripe's customer portal — update card, change plans, cancel.

Why Both Models?

x402 is the future for agent-to-agent payments. An AI agent with a USDC balance can autonomously discover and pay for API calls without any human in the loop. That's powerful.

But not every developer is building autonomous agents. Some just want to hit an oracle endpoint for price data, or run a batch payment from their backend. For them, a traditional API key is the fastest path.

Spraay supports both — and the gateway doesn't care which one you use. If your request has an API key, it's validated and served. If it doesn't, the x402 payment flow kicks in. Same endpoints, same responses.

Built on Base

Everything runs on Base mainnet. The batch payment contract is verified at 0x1646452F98E36A3c9Cfc3eDD8868221E207B5eEC. Part of the Base Build program.

Recently merged into Google Agent Development Kit as an integration, and live on Smithery as an MCP server with 60+ tools.

Get Started

Pricing & signup: spraay.app/#pricing
Docs: docs.spraay.app
Gateway: gateway.spraay.app
GitHub: github.com/plagtech
Twitter: @Spraay_app If you have questions, drop a comment or reach out on Twitter. Happy to walk through integration.

How to pay 100 agents in a single x402 call

Mr Hamlin — Sat, 25 Apr 2026 04:51:15 +0000

You're building an agent that pays for things. It pulls market data, hits an inference endpoint, fans out USDC to 50 freelancers, and writes a row to your database. Four steps.

Three of those steps are one HTTP call each. The fourth — paying 50 people — is 50 transactions, 50 nonces to track, 50 places where something can fail halfway. Your "agent" spends 90% of its runtime managing payment loops.

This is the part of the agent stack that nobody talks about. The x402 marketplace today is full of read-side services: Anthropic, OpenAI, CoinGecko, Exa, Perplexity. They give your agent inputs. None of them help your agent fan money outward.

That's the gap I've been building into for the last few months. This post is a quick tour of why batch settlement matters, why it's the right primitive for the agent economy, and how to actually use it in your code right now.

The cost of doing it wrong

Let's get specific. Say your agent needs to pay 50 USDC recipients on Base. Doing it the obvious way — one ERC-20 transfer per recipient — looks like this:

Approach	Transactions	Total Gas	Wall-Clock Time	Failure Modes
50 sequential transfers	50	~3,300,000	60-120 seconds	Per-tx revert, nonce gaps, RPC drops
50 parallel transfers	50	~3,300,000	5-15 seconds	Nonce conflicts, replacement underpriced
1 batch call	1	~280,000	2-3 seconds	Atomic — all or none

The batch path saves ~92% of the gas and roughly an order of magnitude on wall-clock time. More importantly, it's atomic: either all 50 transfers land in the same block, or none do. Your agent never has to reconcile partial state.

If you've ever built a payroll system, an airdrop tool, a marketplace payout, or an AI agent that distributes rewards, you know exactly why this matters. Partial state is where bugs live.

Why x402 needs this primitive

The x402 protocol is beautifully simple: a server responds with 402 Payment Required, the client attaches a payment proof, the server returns the resource. It works because each request is a single payment unit.

But the agent economy isn't single-recipient. Real workflows look like this:

A research agent buys 10 different data sources for one report, then pays the user a share back.
A trading agent settles fees to multiple liquidity providers in a single decision cycle.
A supply chain agent pays a supplier, the carrier, and the inspector when an invoice clears.
A DAO treasury agent distributes monthly payments to 200 contributors.

Each of those workflows works through x402, but the payment leg currently has to fall back to a non-x402 path — ethers, viem, custom batch contracts, or a centralized service. That's friction. And friction is where adoption dies.

So I built the missing piece: an x402 endpoint that takes a list of recipients and amounts, and settles all of them in a single on-chain transaction.

The endpoint

The Spraay gateway exposes batch settlement as a paid x402 resource. One call in, one transaction out, atomic across all recipients.

POST https://gateway.spraay.app/api/v1/batch/execute

Request shape:

{
  "token": "USDC",
  "sender": "0xYourAgentWallet",
  "recipients": [
    "0xRecipient1",
    "0xRecipient2",
    "0xRecipient3"
  ],
  "amounts": [
    "1000000",
    "2500000",
    "750000"
  ]
}

Amounts are in token-base units (USDC has 6 decimals, so 1000000 = 1 USDC). The cost is $0.02 in USDC paid via x402, regardless of recipient count — economics get better the more recipients you have.

The endpoint hits a batch contract on Base (0x1646452F98E36A3c9Cfc3eDD8868221E207B5eEC), which loops the transfers in a single transaction. Either every recipient gets paid in the same block, or the whole call reverts.

Calling it from an agent

Any HTTP client that speaks x402 can hit this endpoint. The simplest path is the official x402-fetch wrapper — it handles the 402 challenge automatically:

import { wrapFetchWithPayment } from "x402-fetch";
import { createWalletClient, http } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { base } from "viem/chains";

const account = privateKeyToAccount(process.env.AGENT_PRIVATE_KEY!);
const wallet = createWalletClient({
  account,
  chain: base,
  transport: http(),
});

const fetchWithPayment = wrapFetchWithPayment(fetch, wallet);

const response = await fetchWithPayment(
  "https://gateway.spraay.app/api/v1/batch/execute",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      token: "USDC",
      sender: account.address,
      recipients: [
        "0xRecipient1...",
        "0xRecipient2...",
        "0xRecipient3...",
      ],
      amounts: ["1000000", "2500000", "750000"],
    }),
  }
);

const result = await response.json();
console.log("Batch tx hash:", result.txHash);

That's the whole integration. Three recipients, fifty recipients, two hundred recipients — same code shape, same gas profile per call.

If you're not using x402-fetch, the manual flow is:

POST to the endpoint with no payment header. You get back 402 Payment Required with a JSON body describing the price and the facilitator.
Sign a USDC transfer authorization for the price ($0.02) to the payTo address from the response.
Re-POST with the signature in the X-PAYMENT header.
Get back your batch result with the on-chain tx hash.

Where this fits in a larger agent

Batch settlement is most useful as a primitive that other things compose on top of. A few patterns I've seen agents use:

Periodic distribution. A cron-driven agent that pulls revenue, splits it across stakeholders, and pays them out weekly. One batch call per cycle.

Marketplace payouts. A listing platform agent that resolves orders end-of-day and pays sellers atomically.

Multi-hop settlement. An agent that pays an LLM provider, a search provider, and a vector DB provider all from the same workflow's budget — batched so the user is charged once, atomically.

Agent-to-agent commerce. When agents subcontract work to other agents, the paying agent can settle the entire delegation tree in one call rather than chaining individual payments.

The Spraay gateway has 90+ other x402 endpoints — agent wallet provisioning, on-chain DeFi positions, contract reads/writes, multi-chain RPC, AI inference (including a Bittensor drop-in at /bittensor/v1), oracle data, and more — but batch settlement is the one that nothing else on the x402 marketplace currently offers. Everything else is competitive; this one is structurally unique.

Try it

The simplest sanity test: hit the endpoint without payment and watch the 402 challenge come back.

curl -i -X POST https://gateway.spraay.app/api/v1/batch/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"USDC","sender":"0x...","recipients":["0x..."],"amounts":["1000000"]}'

You'll get a 402 Payment Required response with the payment requirements. That confirms the endpoint is live and gated. From there, drop in x402-fetch (or your favorite x402 client) and you're paying batch in five minutes.

The endpoint works on Base mainnet today. If you're building anything that fans money outward — payroll, airdrops, multi-recipient agent workflows, marketplace payouts — give it a try and let me know what breaks. I read every reply.

Discovery doc with the full endpoint catalog: https://gateway.spraay.app/.well-known/x402.json

Build something. Pay everyone. In one call.

— @mr_hamlin

DEV Community: Mr Hamlin

I Ship Paid APIs in a Weekend. Here's the Exact Stack I Use Every Time.

The Stack

The Middleware Chain

API Keys: The Pattern Everyone Skips

Rate Limiting: The Sliding Window

Stripe Billing: The Four Webhooks That Matter

The Weekend Timeline

What I Learned

I Added x402 Payments to Base's Agent Skills — Here's How

What npx skills actually is

Where Base's skills stop

Adding the payment layer

Worked example: an agent that prices before it acts

Worked example: pay 50 people in one transaction

Why this matters for agents on Base

📚 Why Every AI Agent Needs a Research Library

The Research Gap in Agent Infrastructure

What We Built

The Endpoint Map

Where the Demand Is

One Gateway, Every Domain

Batch Payments for Agents (BPA) 1.0: an open standard for how AI agents pay many recipients at once

The payments agents actually need are the ones the old rails punish

What BPA 1.0 actually defines

Three design choices worth calling out

Try it

It's an open standard — build on it

Compute Futures for AI Agents: Prepaid GPU and Inference Credits over x402

The problem with paying retail for every inference call

Compute futures: prepay once, draw down per job

What you can actually run

Why x402 makes this work

Drop it into your agent

BlackRock's CEO just called compute one of the next major markets. Here's why Spraay Protocol is already there.

The Signal No One Should Ignore

The Problem Everyone Sees but Nobody Has Solved

What We Actually Built

Why x402 Is the Payment Rail for Compute

The Landscape Is Moving Our Way

What Comes Next

Spraay Brings Batch Payments to Canton Network Amid Wall Street Tokenization Push

The Canton context

Where batch payments fit

What's live

Spraay just introduced new endpoints for Solana Agents.

What's new

What you don't deal with

Working code

Endpoint details, quickly

Jupiter

Helius DAS

Pyth

Trying it before you integrate

Error handling notes worth knowing

Links

The First Batch Payment Skill for Vercel Agents (skills.sh)

What problem does this solve?

Why an agent skill?

What's covered

15 chains, real contracts

How the gateway works

Quick integration

Where this fits in the Vercel ecosystem

Try it

💧 Spraay x402 Gateway Now Accepts Solana USDC — Dual-Chain AI Agent Payments Are Live

What We Shipped

Three Payment Rails, One Gateway

How It Works (Agent Perspective)

Discovery Endpoints

What's Covered

Technical Implementation

Try It

Links

Spraay Gateway Now Accepts Credit Cards — 80+ API Endpoints, No Crypto Wallet Required

Two Ways to Use Spraay

What You Get Access To

How Subscriptions Work

Why Both Models?

Built on Base

What `npx skills` actually is