DEV Community: Mr Hamlin

Bringing Crypto Batch Payouts to E-Commerce

Mr Hamlin — Sat, 31 Oct 2026 20:26:04 +0000

From Vendure to WooCommerce..

Crypto checkout is a solved problem. Dozens of payment gateways let customers pay with crypto at checkout. But what happens after the sale? How does the marketplace operator pay their vendors? How does a store owner pay suppliers?

That's the side of e-commerce payments nobody's building for. So we did.

Payouts, Not Checkout

Most crypto-in-commerce projects focus on the buy side: let a customer pay with ETH or USDC at checkout. That's fine, but it's competing with credit cards — and credit cards are really, really good at checkout.

The payout side is different. When a marketplace has 50 vendors and needs to distribute last week's earnings, they're dealing with bank transfers, payment processors taking percentage cuts, international wire fees, and settlement times measured in days. For vendors in countries where traditional banking is unreliable or expensive, it's even worse.

USDC batch payouts solve this cleanly: one on-chain transaction, all recipients paid simultaneously, settled in seconds, verifiable on-chain. The Spraay batch contract on Base handles up to 200 recipients per call. Gas costs are a fraction of what wire transfers charge.

We built payout plugins for two major open-source e-commerce platforms to prove this works in practice.

Vendure: The First Plugin

Vendure is a headless e-commerce framework built on Node.js and TypeScript. It's popular with developers building custom marketplace experiences.

Our @plagtech/vendure-spraay-plugin adds a payout workflow to the Vendure admin panel. When a marketplace operator is ready to distribute earnings, they select the vendors, review the amounts, and approve the batch. The plugin calls the Spraay gateway, which returns an unsigned transaction. The operator signs it with their own wallet — we never touch their keys — and the batch settles on Base.

The plugin is published on npm and we've submitted it to the Vendure Hub for listing.

Key design decision: the plugin is non-custodial. Plagtech never holds funds. The operator's wallet signs the transaction directly. We facilitate the batching, not the custody.

WooCommerce: Going Where the Merchants Are

Vendure is developer-friendly but niche. WooCommerce powers over 35% of all online stores. If we wanted batch payouts to reach real merchants, WooCommerce was the obvious next target.

But WooCommerce runs on PHP and WordPress. Our gateway is a Node.js service. We weren't about to ask WordPress hosts to run Node.

The architecture we landed on: a thin PHP plugin that calls the Spraay REST gateway over HTTP. The plugin handles the WordPress admin UI — settings pages, payout history, batch management — and the gateway handles the crypto. No Node.js dependency on the merchant's hosting.

The plugin works for two audiences: single-store owners paying suppliers, and multi-vendor marketplace operators distributing to vendors. We deliberately avoided requiring any specific multi-vendor plugin (Dokan, WCFM, etc.) as a dependency. The plugin reads WooCommerce's native order data and lets the operator define recipients.

The Auth Problem

Our gateway uses x402 — HTTP-native payment authentication. That's great for machine-to-machine scenarios, but a WordPress plugin can't pay an x402 challenge on every API call. Merchants need a simpler auth flow.

So we shipped API key authentication on the gateway side. B2B clients get an API key (prefixed sk_spraay_ so it's easy to identify in config files), pass it in an X-API-Key header, and skip the x402 challenge entirely. The gateway extends its existing key infrastructure with B2B-specific columns. Revenue comes from the same 0.3% on-chain protocol fee — no separate subscription or API pricing.

This was a gateway-level change that benefits any future integration, not just WooCommerce.

Production Tested

We didn't ship this with only unit tests. We ran a full production test: a local WordPress install (via LocalWP), the plugin installed and configured, connected to the live Spraay gateway on Base mainnet.

We triggered a real batch payout from the WordPress admin panel. Real USDC moved on-chain — 1 USDC to a recipient, 0.003 fee, settled on Base. The transaction confirmed and the plugin correctly reconciled the result by checking the on-chain receipt.

Two bugs surfaced during the live test and we fixed them on the spot: a null array crash in the order ID handling, and a unit mismatch between human-readable decimals and base-unit amounts. The kind of stuff you only catch by actually running money through the system.

Submitted and Waiting

The WooCommerce plugin is submitted to the WordPress.org plugin directory. We're waiting on reviewer approval. Once it's listed, any WooCommerce store can install it and start batching USDC payouts to their vendors or suppliers.

We also published a ClawHub skill for it — AI agents can now help merchants configure and run batch payouts through the plugin.

What's Next

WooCommerce and Vendure aren't the end. Medusa.js is on our list as the next e-commerce integration target. The pattern is the same every time: thin plugin on the platform side, heavy lifting on the gateway, non-custodial signing, batch settlement on Base.

The long-term play is straightforward: if you run an online marketplace and you need to pay people, you should be able to do it in one transaction, settled in seconds, for a fraction of what traditional payment processors charge.

Spraay Protocol is multi-chain batch payment infrastructure built by Plagtech. The WooCommerce plugin is pending at WordPress.org. The Vendure plugin is live on npm. Learn more at spraay.app.

Uniswap v4 Hooks Explained — And What We Built for OnChain Revenue Sharing

Mr Hamlin — Sat, 31 Oct 2026 05:39:14 +0000

Uniswap v4 introduced one of the most significant architectural changes in DeFi: hooks. If you've heard the term but aren't sure what it means in practice, this post breaks it down — and shows a real hook we built and got merged into the official Uniswap hook registry.

What Are Uniswap v4 Hooks?

In previous versions of Uniswap, the protocol was essentially closed. You could create pools, add liquidity, and swap tokens, but you couldn't customize what happened during those operations. The logic was fixed.

V4 changes that with hooks — external smart contracts that "hook into" the lifecycle of pool operations. Think of them like middleware for a DEX.

Every major pool action in v4 has a before and after stage:

beforeSwap / afterSwap — runs before or after a token swap
beforeAddLiquidity / afterAddLiquidity — runs when liquidity is added
beforeRemoveLiquidity / afterRemoveLiquidity — runs when liquidity is removed
beforeInitialize / afterInitialize — runs when a pool is first created

When a pool is created, the pool creator specifies a hook contract address. From that point on, every operation on that pool calls the relevant hook functions. The hook can run custom logic, modify behavior, collect fees, enforce rules — whatever the contract is designed to do.

The key insight: hooks don't modify the Uniswap core protocol. They're external contracts that the protocol calls at defined points. This means anyone can write a hook, and pool creators choose which hook (if any) to attach to their pool.

Why Hooks Matter

Before v4, if you wanted custom behavior on a DEX — say, distributing a portion of swap fees to a list of stakeholders — you had two options: fork the entire protocol, or build a wrapper contract that interacted with the pool externally. Both were messy.

Hooks make this native. Some real use cases:

Dynamic fees — adjust swap fees based on volatility, time of day, or pool utilization
On-chain limit orders — execute trades when price hits a target
TWAP (time-weighted average price) orders — spread large trades over time
Custom access control — restrict who can trade in a pool (KYC pools, DAO-gated pools)
Revenue distribution — automatically route a share of pool activity to stakeholders

That last one is what we built.

BatchDistributeHook: What It Does

Our hook lets pool operators push-distribute ERC-20 tokens or native currency (ETH) to up to 200 recipients in a single transaction through the Spraay batch contract on Base.

The use case: a pool generates fees or revenue, and the operator wants to distribute those funds to a list of stakeholders — liquidity providers, DAO members, team wallets, community funds, whatever the arrangement is.

Without a hook, the operator would need to manually collect fees, calculate shares, and send individual transactions to each recipient. With BatchDistributeHook, they call the distribution function and the Spraay batch contract handles the rest: one on-chain transaction, all recipients paid, all amounts verifiable.

The hook interacts with Spraay's batch contract on Base at 0xb9c1ab7bd023c784c19b8e9f10ce9cded9ff9010. This is the same contract that powers all of Spraay's batch payment infrastructure — the same one our e-commerce plugins, robot fleet payments, and gateway all settle through.

How It Works

The flow is straightforward:

A pool is created with BatchDistributeHook as its hook contract
The pool operates normally — swaps, liquidity, everything works as expected
When the operator wants to distribute accumulated tokens, they call the hook's distribute function
The hook approves the Spraay batch contract to spend the specified token amount
The batch contract executes a single transaction that transfers tokens to all recipients
Each recipient's share is settled on-chain, verifiable by anyone

The operator defines the recipient list and amounts. The hook handles the approval and contract interaction. The batch contract handles the multi-send efficiently.

Up to 200 recipients per batch means this scales to meaningful distribution sizes without needing multiple transactions.

Merged Into the Uniswap Hook Registry

Uniswap maintains an official hook registry — a curated list of hooks that developers have built for the v4 ecosystem. Getting listed means the hook has been reviewed and meets the registry's standards.

Our BatchDistributeHook was merged into the Uniswap hooklist as PR #10617 in October 2026, listed as "Add BatchDistributeHook hook on base." It's now part of the official v4 hook ecosystem.

This matters because it puts Spraay's batch payment infrastructure directly into the Uniswap developer surface. Anyone browsing the hook registry looking for distribution solutions finds our hook, and through it, the batch contract that powers the rest of our protocol.

The Bigger Picture

Hooks are still early. Most v4 pools are running without hooks, and the ecosystem of available hooks is still growing. But the architecture is powerful: it turns Uniswap from a fixed protocol into a programmable platform.

For us, BatchDistributeHook is a proof point. The same batch contract that settles robot fleet payments and e-commerce vendor payouts can also settle DeFi revenue distribution — all through one on-chain primitive. That's the advantage of building infrastructure instead of applications: the same settlement layer works across use cases.

If you're building on Uniswap v4 and need batch distribution, the hook is on the registry. If you're building anything that needs to pay multiple recipients on Base in one transaction, the Spraay batch contract is open and documented.

Spraay Protocol is multi-chain batch payment infrastructure built by Plagtech. BatchDistributeHook is listed on the Uniswap v4 hook registry. Learn more at spraay.app.

What Is x402 and Why It Matters for Machine-to-Machine Payments

Mr Hamlin — Fri, 30 Oct 2026 07:23:19 +0000

HTTP has a status code that almost nobody uses: 402 Payment Required.

It's been in the spec since HTTP/1.1 — reserved "for future use." That future is here. The x402 protocol turns that dusty status code into a real payment flow, and we've built our entire payment gateway around it.

The Problem With Paying for APIs

Right now, if you want to charge for an API, you have a few options:

API keys with a billing account — the client signs up, enters a credit card, gets a key, and you bill them monthly. Works great for humans. Terrible for machines. An autonomous agent can't fill out a signup form, and hardcoding API keys into agent workflows creates security and management headaches.

OAuth + subscription tiers — even more overhead. Token refresh flows, scope management, plan limitations. Fine for SaaS products with human users. Overkill for a machine that just needs to make one call.

Prepaid credits — buy credits upfront, spend them per request. Better, but still requires account creation, and the credits are locked into one service.

All of these assume a human is involved at setup time. That assumption breaks down when the client is an AI agent, a robot, an IoT device, or another service in a microservice mesh.

How x402 Works

x402 takes a completely different approach: payment happens inline with the HTTP request. No accounts. No API keys. No signup. Just pay and go.

Here's the flow:

Step 1 — the client makes a normal HTTP request to the API endpoint.

Step 2 — the server responds with 402 Payment Required and includes payment details in the response headers: how much, which token, which chain, where to send it.

Step 3 — the client makes the payment on-chain (or provides proof of a payment already made).

Step 4 — the client retries the original request, this time including the payment proof in a header.

Step 5 — the server verifies the payment and serves the response.

That's it. The client never created an account. The server never stored a credit card. The payment is settled on-chain, verifiable by both parties, and the whole flow happened over standard HTTP.

Why HTTP-Native Matters

The genius of x402 is that it works with existing HTTP infrastructure. Proxies, load balancers, CDNs, monitoring tools — they all understand HTTP status codes. A 402 response flows through the same infrastructure as a 401 or a 403. No special protocol, no WebSocket upgrade, no custom transport.

This means any HTTP client can be taught to handle x402 payments. A Python requests call, a curl command, a browser fetch — if it speaks HTTP, it can speak x402.

For machine-to-machine scenarios, this is transformative. An AI agent making an API call doesn't need pre-provisioned credentials for every service it might use. It just needs a wallet with funds and the ability to handle a 402 response. First time calling a new API? Pay the 402 and you're in.

How We Built On It: The Spraay Gateway

Spraay's payment gateway at gateway.spraay.app is an x402-native service. Every paid endpoint responds with a 402 challenge that tells the caller exactly what to pay.

The gateway handles batch payments — send USDC to up to 200 recipients in a single on-chain transaction on Base. The x402 flow means any HTTP client can use it without signing up:

Call the batch endpoint
Receive a 402 with the fee amount and payment address
Pay the fee on-chain
Retry with the transaction hash in the header
Receive the unsigned batch transaction to sign and submit

We support multiple chains for the payment itself (Base, Ethereum, Solana), and the gateway verifies payment on whichever chain the client used.

The fee structure is simple: 0.3% of the batch amount, with a minimum. The client knows the exact cost before paying because the 402 response spells it out.

x402 for Agents and Robots

This is where x402 really shines. We've integrated Spraay's gateway with:

AI agent frameworks — our payment tools are merged into NVIDIA's NeMo Agent Toolkit, Google's ADK community, and the Strands Agents documentation. Agents in these frameworks can handle x402 challenges natively.
Robot fleet management — our rmf-spraay bridge dispatches tasks through the gateway using x402. A robot fleet operator's software pays the 402 challenge, dispatches a task, and settles the payout — all over HTTP.
E-commerce plugins — for platforms where x402 per-request payment doesn't make sense (a WordPress plugin can't pay a 402 on every batch call), we added API key authentication alongside x402. B2B clients get a key that bypasses the challenge. Same gateway, flexible auth.

The flexibility is the point. x402 is the default for machine clients that can handle it. API keys are there for platforms that can't. Both hit the same endpoints, same settlement, same on-chain verification.

The Broader x402 Ecosystem

We're not the only ones building on x402. Coinbase has championed the protocol, and an ecosystem of x402-compatible services is growing. The pattern is consistent: HTTP endpoint, 402 challenge, on-chain payment, proof-of-payment header, service delivery.

What we've added to the ecosystem is batch payment infrastructure. Most x402 implementations handle simple one-to-one payments (pay $0.05, get an API response). Our gateway handles one-to-many: pay once, distribute to hundreds of recipients. That opens up use cases like payroll, vendor payments, revenue sharing, and fleet settlement that a simple per-request payment model can't cover.

Why We Think This Is the Future

Every trend points toward more machines talking to more machines, with less human involvement in each transaction. AI agents are calling APIs on your behalf. IoT devices are negotiating with services. Microservices are settling with each other.

All of these need a payment flow that doesn't require a human to set up an account first. x402 provides that: an open, HTTP-native, on-chain-verified payment protocol that any machine can use.

We've bet Spraay's entire architecture on it, and after months of building integrations across robotics, e-commerce, DeFi, and AI agents, the bet is holding up. The protocol works. The infrastructure works. The use cases are real.

If you're building something that needs to charge for API access or settle payments between machines, take a look at x402. The 402 status code has been waiting since 1997. It's ready now.

Spraay Protocol is multi-chain batch payment infrastructure built by Plagtech. Our x402 gateway is live at gateway.spraay.app. Learn more at spraay.app.

How to Pay Your Shopify Affiliates in USDC (Open Source)

Mr Hamlin — Fri, 31 Jul 2026 07:23:43 +0000

If you run affiliate or creator payouts for a Shopify store, you know the drill: export a spreadsheet, log into PayPal or a payout platform, pay per-transaction fees on every single recipient, wait days for settlement, and deal with the countries your payment provider doesn't support.

There's a simpler way: batch USDC payouts on Base. One transaction, N recipients, settlement in seconds, and it works for anyone with a wallet address — anywhere in the world.

In this tutorial, you'll self-host an open-source Shopify app that adds a Payouts section to your Shopify admin. You'll upload a CSV of affiliate wallet addresses and amounts, approve USDC once, and pay everyone in a single on-chain transaction.

Repo: github.com/plagtech/spraay-shopify (MIT license)

🤖 Using an OpenClaw agent? Skip the manual setup entirely: openclaw skills install @plagtech/spraay-shopify-selfhost walks you through deployment, and @plagtech/shopify-batch-payouts runs payouts via the Spraay gateway.

What you're building

The Spraay Shopify app is an embedded admin app (built with Remix + Polaris, so it looks and feels native to Shopify) that lets you:

Upload or paste a CSV of recipients — wallet address + USDC amount per row
Review the batch — recipients, totals, and the 0.3% protocol fee, all shown before anything moves
Connect a wallet — MetaMask or Coinbase Smart Wallet
Approve USDC once, then execute the entire batch in one transaction on Base
Track payout history right in your admin

Under the hood, payouts go through the Spraay batch contract on Base (0x1646452F98E36A3c9Cfc3eDD8868221E207B5eEC), using native USDC (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913). Base transaction fees are typically a fraction of a cent, so the cost of paying 50 affiliates is basically the same as paying one.

Why self-hosted?

Two reasons:

You control everything. Your Shopify credentials, your database, your infrastructure. The app requests zero Shopify scopes — it structurally cannot read your orders, customers, or products — and it never custodies funds: payouts are signed by your wallet, in your browser.
Custom app distribution is Shopify's intended path for merchant-specific tooling. You create your own app in the Shopify Dev Dashboard, install it on your store, and you're done. No app store, no waiting.

Prerequisites

A Shopify store (any plan; a development store works for testing)
A Shopify Partners account (free) to create the custom app
A Railway account for hosting (or any host that runs Docker/Node 20)
A Supabase project for the Postgres database (free tier is fine)
A wallet with USDC on Base (MetaMask or Coinbase Smart Wallet)

Total setup time: about 15 minutes.

Step 1: Fork and deploy

Fork plagtech/spraay-shopify, then deploy it to Railway. The repo ships with a railway.json and Dockerfile (node:20-alpine), so the Deploy to Railway button in the README gets you a running instance quickly.

One important detail: make sure PORT=3000 is set in your Railway service variables — the container expects it.

Once deployed, Railway gives you a public URL (e.g. your-app.up.railway.app). You can point a custom domain at it later via CNAME if you want something cleaner.

Step 2: Create your custom app in Shopify

Go to dev.shopify.com → Apps → Create app → choose Custom distribution. This is Shopify's intended path for merchant-specific tooling — no App Store review involved.
Set the App URL to your Railway deployment URL (HTTPS, no trailing slash).
Add all three OAuth redirect URLs:

   https://your-domain/auth/callback
   https://your-domain/auth/shopify/callback
   https://your-domain/api/auth/callback

Copy the Client ID and Client Secret — they become SHOPIFY_API_KEY and SHOPIFY_API_SECRET in the next step. Then install the app on your store from the Dev Dashboard.

Step 3: Configure environment variables

The repo includes a fully documented .env.example. Set these in your Railway service variables (the Deploy button pre-prompts for all of them):

Variable	Value
`SHOPIFY_API_KEY`	Client ID from Step 2 (public — it ships in the browser bundle)
`SHOPIFY_API_SECRET`	Client Secret from Step 2 (keep secret — it signs webhooks and OAuth)
`SHOPIFY_APP_URL`	Your Railway URL, no trailing slash
`SCOPES`	Leave empty — the app uses no Shopify data
`DATABASE_URL`	Supabase pooled connection string (port 6543), with `?schema=shopify&pgbouncer=true`
`DIRECT_URL`	Supabase direct connection string (port 5432), with `?schema=shopify`
`NODE_ENV`	`production`
`PORT`	`3000`

Two things worth knowing:

PORT=3000 is load-bearing. The Dockerfile exposes 3000; if Railway injects its default 8080 instead, every route returns a 502 even though the deploy shows "Online." If you ever see that symptom, this is why.
The ?schema=shopify suffix keeps the app's tables in their own Postgres schema, so it won't collide with anything else in your Supabase project.

Migrations run automatically on boot. When the deploy logs show a successful migrate and the server's listen URL, and the app opens from your Shopify admin, you're wired up.

Step 4: Run your first payout

Open the app from your Shopify admin sidebar.
Upload a CSV (or paste rows directly) in the format: wallet_address,amount. Each row is one affiliate.
Review the batch. You'll see every recipient, the total USDC, and the 0.3% protocol fee itemized before you sign anything.
Connect your wallet — MetaMask or Coinbase Smart Wallet.
Approve USDC for the batch total (one approval).
Execute. One transaction on Base pays every recipient. Settlement is near-instant, and the transaction hash links straight to BaseScan.

Your payout history is saved in the app, so month-over-month affiliate payments become a two-minute task: export your affiliate report as CSV, upload, execute.

What this costs

Base gas: typically under a cent for the whole batch
Protocol fee: 0.3% of the batch total, collected on-chain by the batch contract
Hosting: Railway's hobby tier + Supabase free tier cover a single-store deployment

Compare that to per-recipient fees on traditional payout rails, and the math gets very favorable very quickly once you're paying more than a handful of people.

Use cases beyond affiliates

The CSV-in, batch-out model fits anywhere you pay multiple people regularly:

Creator/UGC payouts for content programs
Supplier payments to international vendors who accept stablecoins
Referral and ambassador programs
Revenue splits between co-founders or collaborators

Wrapping up

You now have a self-hosted, open-source crypto payout system living inside your Shopify admin. No custodial platform, no per-recipient fees, no geography restrictions — just a CSV and one transaction.

⭐ Repo: github.com/plagtech/spraay-shopify
💧 Spraay Protocol: spraay.app — batch payment infrastructure on Base, Ethereum, Solana, and more
🐦 Questions? Reach out @Spraay_app

If you deploy it, open an issue or PR — contributions welcome.

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.

DEV Community: Mr Hamlin

Bringing Crypto Batch Payouts to E-Commerce

From Vendure to WooCommerce..

Payouts, Not Checkout

Vendure: The First Plugin

WooCommerce: Going Where the Merchants Are

The Auth Problem

Production Tested

Submitted and Waiting

What's Next

Uniswap v4 Hooks Explained — And What We Built for OnChain Revenue Sharing

What Are Uniswap v4 Hooks?

Why Hooks Matter

BatchDistributeHook: What It Does

How It Works

Merged Into the Uniswap Hook Registry

The Bigger Picture

What Is x402 and Why It Matters for Machine-to-Machine Payments

The Problem With Paying for APIs

How x402 Works

Why HTTP-Native Matters

How We Built On It: The Spraay Gateway

x402 for Agents and Robots

The Broader x402 Ecosystem

Why We Think This Is the Future

How to Pay Your Shopify Affiliates in USDC (Open Source)

What you're building

Why self-hosted?

Prerequisites

Step 1: Fork and deploy

Step 2: Create your custom app in Shopify

Step 3: Configure environment variables

Step 4: Run your first payout

What this costs

Use cases beyond affiliates

Wrapping up

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

What `npx skills` actually is