DEV Community: Mr Hamlin

I wrote the book I wish existed when I started shipping solo with AI

Mr Hamlin — Mon, 06 Jul 2026 20:50:03 +0000

For the past year-plus I've been running multiple live products completely solo — a crypto payment gateway processing transactions across 16 chains, an LLM API proxy with Stripe billing, a DEX on Base mainnet, packages on npm and PyPI, and integration PRs merged into Google's, AWS's, and Coinbase's agent framework ecosystems.

No team. No funding. One laptop and a set of AI tools that didn't exist a few years ago.

People kept asking how the workflow actually works — not "what's your favorite AI tool" but the whole system: how you go from idea to deployed product to paying users when you're the entire engineering, marketing, and support department. So I wrote it down. All of it. The result is Build in Public with AI: The Solo Developer's Guide to Shipping Fast — 268 pages, 13 chapters, and it just went live on Amazon.

What's actually in it

This is not a prompt engineering guide and not a listicle of tools. It's the operating system:

Part I — The Solo AI Stack. How to pick the two AI tools that actually matter and ignore the rest, structure your day around a Think → Prompt → Scaffold → Refine → Ship loop, and manage context across multiple projects without losing your mind.

Part II — Shipping Product. The Minimum Deployable Product framework (zero to deployed in a day), building fast without building fragile, running 3–5 products at once with a tiering system that prevents burnout, and a full chapter on AI-assisted smart contract development.

Part III — Distribution. The part most technical books skip. The PR Blitz strategy for getting your tool integrated into every major AI framework ecosystem, README-driven distribution, the awesome-list strategy, and building in public without it becoming a second job.

Part IV — The Operating System. Revenue models that work for one person, wiring up Stripe in a weekend, the emotional reality of solo building, what AI still can't do, and a 30-day playbook you can start tomorrow.

Plus appendices: the complete tool stack reference, 15 copy-paste prompt templates, and a printable Ship It checklist.

One idea from the book, free

Here's the concept that changed how I ship more than any tool did: the Minimum Deployable Product.

An MVP is defined by features. An MDP is defined by a state: deployed, reachable, and doing its one job in production. The difference sounds subtle but it inverts your priorities. You don't build features and then figure out deployment — you deploy a skeleton on day one (a single endpoint, a single page, whatever) and then every feature lands in a production context from the start.

Why it matters for solo devs specifically: deployment problems are the ones AI helps you with least — they're environmental, specific to your accounts and configs, and full of gotchas AI can't see. Feature code is what AI helps with most. So you front-load the part AI can't do while your motivation is highest, and spend the rest of the build in AI's strongest territory. Every hour after day one compounds.

Also, honestly: nothing sustains momentum like a live URL. Even an ugly one.

Who it's for

Developers. You can read a stack trace and make architecture decisions — you don't need to be senior, but this isn't a learn-to-code book. If you've been watching the AI-assisted-shipping wave and wondering how people actually run the full loop solo, this is the manual.

Build in Public with AI: The Solo Developer's Guide to Shipping Fast — $4.99 on Amazon

I'll be posting build logs and revenue numbers as this launches — that's kind of the whole point of the title. If you read it and something's unclear, wrong, or missing, tell me. Solo also means the errata department is me.

What's the biggest bottleneck in your own shipping loop — building, deploying, or distributing? Genuinely curious where people get stuck.

I Built a Batch Payment Plugin for AI Agents in 48 Hours (and It Made Its First Cent On-Chain)

Mr Hamlin — Fri, 03 Jul 2026 19:34:44 +0000

Yesterday I had an idea about where value accrues in the AI agent ecosystem. Today the plugin is live on ClawHub, published on npm, and has already processed a real USDC payout on Base mainnet — with the protocol's first fee, all $0.009 of it, sitting on-chain.

Here's the whole thing: the insight, the build, the receipts, and the pricing math.

The insight: plugins own execution paths, skills get invoked

I've been building in the x402 / agent-payments ecosystem for months — my main project is an x402 payment gateway with ~190 endpoints. Watching which projects in this space actually generate revenue, one pattern kept jumping out:

The projects making money don't sell capabilities. They own a step in a loop.

A skill is something an agent invokes occasionally, when a task happens to call for it. A plugin that sits on a recurring execution path gets exercised every single time the loop runs. Same amount of code. Wildly different revenue curves.

Most of the plugin activity in the agent economy clusters around the money-in layer — routing model calls, metering inference, charging for API access. That path is getting crowded.

But agents don't just consume — increasingly, they pay out. Revenue splits to contributors. Settlements with other agents. Payroll-shaped flows. Refunds. And the money-out layer was, as far as I could tell, unclaimed.

So I claimed it.

What SpraayBatch does

SpraayBatch is an OpenClaw plugin (plus a standalone CLI) that gives an AI agent a treasury:

Batch USDC payouts — up to 200 recipients in one atomic transaction on Base. One tx, one gas fee, everyone paid or nobody is.
Non-custodial auto-wallet — generated locally on first run, key saved to ~/.spraay/.session, never transmitted anywhere.
Per-agent budget caps — a hard block, not a warning. An agent cannot spend past its cap.
Append-only ledger — every payout gets a receipt with a Basescan link.
Optional gasless mode — via ERC-4337 and a CDP Paymaster you configure. Agents holding only USDC, with zero ETH, can pay. No more topping up gas dust across a fleet of agent wallets.
Safe by default — installs pointed at Base Sepolia. Mainnet is opt-in, behind an explicit confirmation gate.

Six tools, one manifest. An agent gets spraay_wallet_info, spraay_balance, spraay_budget_set, spraay_budget_status, spraay_batch_pay, and spraay_receipts.

The 48 hours

Day 1: built the entire plugin in one Claude Code session — contract interaction, wallet management, the budget system, the ledger, the OpenClaw manifest. Deployed a test contract to Base Sepolia, proved the gasless path with a real sponsored payout (sender held zero ETH), pushed to GitHub, published to npm.

Day 2 (today): renamed the project (naming is hard; batch payments is the product, so the name now says so), added full fee disclosure to every user-facing surface, ran the first real mainnet payout, passed ClawHub's security review, and launched.

The rename alone touched 130 references across 18 files — package name, manifest, six tool IDs, CLI binary, docs, the GitHub repo itself. Claude Code planned it, grepped every occurrence first, and executed with hard stops before anything irreversible. The whole build-rename-launch cycle is the most concrete case I've had yet for AI-assisted solo development: not because the AI did it alone, but because one person plus an agent covered ground that used to need a team.

The receipt

Talk is cheap. Here's the first real mainnet payout:

basescan.org/tx/0xb96e8e42829c482998015353fba44dbed1b3611031bd7dbf41acbb78e1268964

One sprayEqual call. Three recipients, 1 USDC each. Total gas: $0.0014. The 0.30% protocol fee — 0.009 USDC — visible right there in the transfer list, flowing to the fee collector. Five USDC transfers, one atomic transaction, complete transparency.

That fee is the protocol's first revenue. It's less than a cent. I screenshotted it anyway, because every fee curve starts at its first data point.

The pricing math

SpraayBatch charges 0.30% on mainnet batches. Testnet is free. No subscription, no seats, no API key tiers.

Here's why that's a good deal from the payer's side: a 1,000 USDC payout to 200 recipients costs 3 USDC in protocol fees — and lands in one transaction. The alternative is 200 separate transfers: 200 signatures, 200 gas fees, 200 chances for one to fail and leave your payout half-done. Even on a cheap chain like Base, the operational cost of 200 individual sends dwarfs 3 USDC.

And the fee isn't hiding anywhere. It's in the README, in the tool descriptions agents read before calling, in the dry-run output, and broken out explicitly in the mainnet confirmation gate:

Mainnet payout: 1.5 USDC to 3 recipient(s) + 0.0045 USDC protocol fee = 1.5045 USDC total.
Mainnet requires explicit confirmation. Add --confirm to send on mainnet.

The gate reads its numbers live from the contract, not from a hardcoded string — so it stays honest even if the fee ever changes.

Design decisions worth stealing

Testnet-default, mainnet-gated. A treasury plugin that can accidentally spend real money is a liability. SpraayBatch installs pointing at Sepolia; switching to mainnet is a deliberate config change, and even then, every real payout demands explicit confirmation. During my own demo recording, I ran the mainnet pay command without the confirm flag — and the gate refused, on camera. That refusal is the best frame in the demo GIF.

Bring-your-own paymaster. Gasless is genuinely useful — agents that never need ETH are operationally simpler — but subsidizing gas for strangers is a great way to get drained by dust spam. So sponsorship runs through your CDP account and your policy caps. The plugin never subsidizes anything.

Fees as pricing, not fine print. The 0.30% appears everywhere a user or agent could encounter it before money moves. A fee someone discovers in a transaction trace reads as sneaky. A fee stated in the tool description reads as a business model. Same number, opposite trust outcomes.

Try it

As an OpenClaw plugin:

openclaw plugins install clawhub:spraay-batch

As a CLI:

npm install -g spraay-batch
spraay-batch info

You get a wallet on first run, pointed at testnet. Fund it with Sepolia USDC and batch away for free. When you're ready for mainnet, the config flip and the confirmation gate are waiting.

GitHub: github.com/plagtech/SpraayBatch
npm: npmjs.com/package/spraay-batch
Part of the Spraay ecosystem — batch payments infrastructure for the agent economy

I'll be running a real batch payout through it every week and posting the receipts — dogfooding in public. Week one is already on-chain.

If you're building agents that need to pay out — or you think the money-out layer needs something this doesn't cover — I want to hear it. Comments open, DMs open (@Spraay_app on X).

You're Running a GPU Rig and Waiting 2 Weeks to Get Paid. Why?

Mr Hamlin — Fri, 26 Jun 2026 18:56:43 +0000

Let me paint a picture most GPU operators know too well.

You spent $2,000 on a used RTX 4090. You set it up, got verified on Vast.ai, dialed in your thermals, and started earning. The dashboard says you've made $180 this pay period. Nice.

Now you wait.

Vast.ai pays hosts every two weeks through PayPal or Wise. Your money sits in their system for 14 days before it moves. And when it does land, PayPal takes their cut. If you're international, Wise takes a currency conversion fee on top of that. By the time that $180 reaches your bank account, you're looking at maybe $155 and three weeks since the jobs actually ran.

RunPod? They pay in platform credits. You earn compute hours, not dollars. Want to cash out? You're spending those credits back on RunPod's own infrastructure. It's store credit, not income.

Salad pays in "Salad Balance" that you redeem for gift cards. Gift cards. You're running a $2,000 GPU and getting paid in Amazon gift cards.

This is the state of GPU operator payouts in 2026.

The question nobody is asking

Here's what's strange about this whole situation. The AI compute rental market is worth over $8 billion this year. It's growing at 44% annually. There are over 120,000 developers on Vast.ai alone looking for GPU time. Demand is through the roof.

And yet the people actually providing the compute — the operators running the rigs, paying the electricity, managing the hardware — are getting paid like it's 2015. Biweekly PayPal transfers. Platform credits. Gift cards.

Meanwhile, USDC settles on Base in two seconds. Two seconds. Around the clock. No minimums. No platform holding your funds. No conversion fees. The infrastructure for instant payouts already exists. Nobody was using it for GPU operators.

Until now.

What Spraay Direct actually does

Spraay Direct is the first instant USDC payout system built specifically for GPU operators.

You connect your GPU — whether you're running vLLM, Ollama, or ComfyUI — to the Spraay network. When an AI agent sends a job to your GPU, you get paid in USDC on Base the moment that job completes. Not in two weeks. Not in platform credits. Not in gift cards. In USDC, in your wallet, in about two seconds.

There's no platform fee in the traditional sense. Vast.ai takes 15-25% of what renters pay. Spraay charges a flat $0.03 per job. That's it. The rest goes directly to your wallet.

And if you're running a multi-GPU operation with a partner, or you want to automatically set aside a percentage for taxes or savings, Spraay's batch payment system lets you split every payout across multiple wallets in a single transaction. 70% to your operating wallet, 20% to savings, 10% to your partner — all settled atomically on-chain. Try doing that with a PayPal payout.

How this compares to what you're using now

Let's be specific because vague claims don't help anyone.

Vast.ai pays hosts via PayPal or Wise every two weeks. There's a minimum threshold before you can withdraw. The platform takes 15-25% as commission. Payout currency is USD through traditional banking rails. No split payments. Your earnings sit in Vast's system until their next payout cycle.

RunPod operates on platform credits. Their revenue sharing program for Hub publishers pays 3-7% of compute hours — in RunPod credits, not cash. If you're a Community Cloud host, payouts depend on the specific arrangement, but you're generally locked into the RunPod ecosystem.

Salad pays in Salad Balance. You can redeem it for gift cards, games, or crypto. The conversion rates vary. It's designed for gamers monetizing idle hardware, not serious operators.

Spraay Direct pays in USDC on Base within seconds of job completion. No minimum payout. No platform commission beyond the per-job fee. No waiting period. No PayPal. No gift cards. Every payment is on-chain, meaning you have a permanent, auditable record of every dollar earned on Basescan.

Who this is for

If you're running one or more GPUs with at least 16GB of VRAM and you're already doing AI inference work — or thinking about starting — this is for you.

If you're a Vast.ai host who's tired of the two-week payout cycle and the PayPal fees eating your margins, this is for you.

If you're a crypto-native builder who wants earnings in USDC rather than fiat, this is for you.

If you're running a small GPU farm with a partner and you're manually splitting PayPal payments or Venmo-ing each other after every payout cycle, the automatic batch splits alone might be worth the switch.

And if you're someone who's been mining crypto and looking at the AI compute market as the next opportunity — this is how you get started without handing 20% of your earnings to a middleman.

The part where I'm honest about what this isn't

Spraay Direct isn't a marketplace. We're not replacing Vast.ai's marketplace or RunPod's infrastructure. We're a payment and settlement layer.

Right now, when you connect to Spraay Direct, your GPU serves inference jobs from AI agents that discover Spraay through the x402 protocol and MCP ecosystem. This is a growing but still early network. You won't see the same volume of jobs you'd get on Vast.ai's marketplace with 120,000 developers on day one.

What you will get is instant payouts, lower fees, USDC settlement, and batch splits from day one. And as the x402 agent economy grows — which it is, rapidly — the job volume follows.

Some operators are running Spraay Direct alongside their Vast.ai listing. GPU idle on Spraay? Vast.ai picks it up. Job comes through Spraay? Instant USDC. Best of both worlds while the network scales.

What happens next

You can check out the Spraay Direct proxy on GitHub. The setup takes about 30 minutes. You run a lightweight proxy on your machine that connects your inference engine to the Spraay gateway. When jobs come in, your GPU does the work. USDC lands in your wallet. That's the whole pitch.

The GPU compute market is massive and growing. The operators powering it deserve to get paid like it's 2026, not 2015. That's what we're building.

If you're running a rig and you're tired of waiting for your money, come try it.

Spraay Direct is open source and built on Base. USDC settlement via the x402 protocol.

GitHub: github.com/plagtech/spraay-direct-proxy
Gateway: gateway.spraay.app
Twitter: @Spraay_app

We Made Our x402 Payment Gateway Loop-Native — Here's How (and Why Your Agent Needs It)

Mr Hamlin — Wed, 24 Jun 2026 01:24:02 +0000

Two weeks ago, Boris Cherny — head of Claude Code at Anthropic — said something on stage that changed how I think about building infrastructure:

"I don't prompt Claude anymore. I have loops running. They're the ones prompting Claude."

Then Peter Steinberger dropped a post that put a name on it: loop engineering. The idea is simple but the implications are massive. You stop writing prompts. You start designing the systems that prompt agents for you. The agent enters a cycle — reason, act, observe, repeat — and it doesn't stop until the goal is met or the budget is hit.

That immediately raised a question for me: if agents are going to run autonomously in loops, what happens when the "act" step involves money?

I run Spraay — an x402 payment gateway with 170+ endpoints across 16 chains. Agents already call our batch payment, escrow, and payroll endpoints through an MCP server. But every one of those calls was fire-and-forget. The agent sends a request, gets a response, and has no way to know when the payment actually settles unless it polls. Polling burns tokens. Burned tokens cost money. And in a loop, that cost compounds on every cycle.

So we made the gateway loop-native. Here's what that means and how we built it.

The Core Problem: Loops Need Callbacks, Not Polling

A loop-engineered agent doing batch payroll looks like this:

1. Observe: "10 employees need to be paid"
2. Reason: "I should batch these through Spraay"
3. Act: POST /api/v1/payroll/execute
4. Observe: ??? (How does the agent know it settled?)
5. Reason: ??? (Should I retry? Move on? Something failed?)

Without callbacks, step 4 becomes a polling loop inside the main loop. The agent hammers GET /status every few seconds, burning inference tokens while it waits. That's wasteful for one payment. For an agent running continuous operations — processing invoices, releasing escrow milestones, executing weekly payroll — it's unsustainable.

The fix: let agents pass a callback_url on any request. When the operation resolves, the gateway POSTs a signed payload to that URL. The agent's loop receives the event, processes it, and decides its next action. No polling. No wasted tokens.

The Implementation: Three Layers

Layer 1: Webhook Infrastructure

The core system is a Supabase-backed event queue with a background dispatch worker. When an agent includes callback_url in a request body, the gateway:

Generates a per-event HMAC signing secret
Queues the webhook event in a webhook_events table
Returns the normal response plus a webhook object containing the webhook_id and webhook_secret
A background worker polls for pending events and delivers them

Here's what an agent sees when it includes callback_url:

POST /api/v1/batch/execute
{
  "token": "USDC",
  "recipients": [
    { "address": "0xAlice", "amount": "1000.00" },
    { "address": "0xBob", "amount": "2500.00" }
  ],
  "sender": "0xEmployer",
  "callback_url": "https://agent.example.com/hooks/spraay"
}

Response:

{
  "success": true,
  "contract": "0x1646452F98E36A3c9Cfc3eDD8868221E207B5eEC",
  "batch": {
    "recipientCount": 2,
    "totalAmount": "3500.00",
    "fee": "10.50",
    "totalWithFee": "3510.50"
  },
  "transaction": { ... },
  "webhook": {
    "webhook_id": "afe9c56e-8074-4f5e-ae22-2eabd8cdcec0",
    "webhook_secret": "whsec_b8559497b5cf43...",
    "subscribed_events": ["batch.created"]
  }
}

When the batch settles, the gateway POSTs to the agent's URL with HMAC-SHA256 signed headers:

POST https://agent.example.com/hooks/spraay
X-Spraay-Signature: sha256=abc123...
X-Spraay-Event: batch.settled
X-Spraay-Delivery-Id: afe9c56e-...
X-Spraay-Timestamp: 2026-06-23T12:00:00.000Z
User-Agent: Spraay-Webhooks/1.0

{
  "id": "afe9c56e-...",
  "event_type": "batch.settled",
  "timestamp": "2026-06-23T12:00:00.000Z",
  "attempt": 1,
  "data": {
    "recipient_count": 2,
    "token": "USDC",
    "total_amount": "3500.00",
    "total_with_fee": "3510.50"
  }
}

The agent verifies the signature with the webhook_secret from the original response, processes the event, and moves to the next step in its loop. If delivery fails, the worker retries with exponential backoff — 30s, 60s, 120s — up to 3 attempts before marking the event as exhausted.

The key design decision: the callback system is entirely optional. Agents that don't pass callback_url see zero changes in the response. Every existing integration keeps working exactly as before.

Layer 2: Safety Guards

This is the part that kept me up the night before shipping. If agents are running autonomous payment loops, what happens when a loop has a bug?

Picture this: an agent receives a batch.settled callback, and its loop logic says "great, now pay the next batch." It fires another payment. Gets another callback. Fires again. The loop has no exit condition, and the wallet drains in minutes.

That's not a Spraay bug — it's an agent design bug. But users will blame the gateway. So we built three safety layers that protect wallets regardless of how the agent is designed:

Per-key rate limiting on payment endpoints. Every API key gets a budget of 10 payment-moving calls per minute. A legitimate batch operation (even 200 recipients) is a single API call. You'd need to fire 10 completely separate operations within 60 seconds to hit the limit. A runaway loop hits it in seconds. Responses include X-RateLimit-Remaining headers so well-built agents can self-regulate.

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests to /api/v1/batch/execute. Limit: 10 per 60s.",
  "hint": "If this is a loop-engineered agent, ensure your loop has proper termination conditions."
}

Duplicate payment detection. If the same API key sends an identical payload (same recipients, amounts, token) within 60 seconds, the gateway returns a 409 instead of processing a duplicate payment. The response tells the agent how to override this if the duplicate is intentional (add a unique idempotency_key field).

Webhook delivery cooldown. No callback URL receives deliveries faster than every 5 seconds. This caps the maximum possible loop cycle speed. A legitimate agent processing results never needs sub-5-second callbacks. A runaway loop would.

All three guards are per-API-key, so a large company with heavy legitimate usage gets their own rate budget. And all three are additive — they sit in the middleware chain without touching any existing endpoint logic.

Layer 3: Wiring Endpoints

Making an endpoint callback-aware takes about 8 lines of code. The webhook middleware attaches a webhookCallback helper to every request that includes callback_url. Endpoint handlers just check if it's there:

// Existing handler code builds the response...

// Add webhook callback (only fires if agent passed callback_url)
if (req.webhookCallback) {
  response.webhook = await req.webhookCallback('batch.created', {
    recipient_count: recipients.length,
    token: token.symbol,
    chain: 'base',
    total_amount: totalAmount,
  });
}

return res.json(response);

We wired up 6 handlers across 3 endpoint families:

Batch payments — batch.created on execute
Escrow — escrow.created, escrow.funded, escrow.released, escrow.disputed across all state transitions
Payroll — batch.created with type: 'payroll' in the payload

Escrow is the most interesting case because it's inherently a state machine. An agent loop managing a freelance contract can now receive callbacks at every stage: escrow created → funded → work completed → released. Each callback gives the agent the information it needs to decide its next action without polling.

What This Enables

With loop-native callbacks, an agent can now do things like:

Automated payroll processing: Observe invoice queue → batch employees → receive settlement callback → update books → repeat next pay period.

Escrow milestone management: Create escrow → fund on approval → receive work → release on delivery → handle disputes. All event-driven, no polling.

Multi-chain treasury operations: Monitor balances across chains → batch rebalancing payments → confirm settlements → repeat.

The x402 per-call pricing model actually works in our favor here. Loop-engineered agents make more calls per task (that's the nature of the cycle), which means more microtransactions flowing through the gateway. Making the integration smoother via callbacks means agents are more likely to use Spraay as their payment layer — which means more volume, not less.

What We Didn't Build (and Why)

We deliberately chose not to build a loop orchestration framework. The agent ecosystem already has plenty of those — Claude Code, OpenClaw, LangGraph, CrewAI. What it doesn't have is payment infrastructure designed for autonomous agent loops.

Spraay's position is the settlement layer. We don't tell agents what to do or how to loop. We make sure that when the "act" step in any loop involves moving money, the infrastructure is fast, secure, signed, and event-driven.

Try It

Spraay's loop-native webhooks are live today across batch, escrow, and payroll endpoints. Add callback_url to any request body and you'll get signed callbacks when the operation resolves.

Gateway: gateway.spraay.app
Docs: docs.spraay.app
MCP Server: smithery.ai/servers/Plagtech/Spraay-x402-mcp
BPA Spec: docs.spraay.app/bpa/1.0/

If you're building loop-engineered agents that handle money, I'd love to hear how you're thinking about the payment layer. What safety guarantees matter most to you? What event types would you want callbacks for?

Spraay is an x402 payment gateway — 170+ endpoints, 16 chains, batch payments as the primary differentiator. Built by a solo founder in public.

Follow the build: @lostpoet on X, @plag on Farcaster.

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.

DEV Community: Mr Hamlin

I wrote the book I wish existed when I started shipping solo with AI

What's actually in it

One idea from the book, free

Who it's for

I Built a Batch Payment Plugin for AI Agents in 48 Hours (and It Made Its First Cent On-Chain)

The insight: plugins own execution paths, skills get invoked

What SpraayBatch does

The 48 hours

The receipt

The pricing math

Design decisions worth stealing

Try it

You're Running a GPU Rig and Waiting 2 Weeks to Get Paid. Why?

The question nobody is asking

What Spraay Direct actually does

How this compares to what you're using now

Who this is for

The part where I'm honest about what this isn't

What happens next

We Made Our x402 Payment Gateway Loop-Native — Here's How (and Why Your Agent Needs It)

The Core Problem: Loops Need Callbacks, Not Polling

The Implementation: Three Layers

Layer 1: Webhook Infrastructure

Layer 2: Safety Guards

Layer 3: Wiring Endpoints

What This Enables

What We Didn't Build (and Why)

Try It

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

What `npx skills` actually is