DEV Community: Mr Hamlin

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

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

The Signal No One Should Ignore

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

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

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

The Problem Everyone Sees but Nobody Has Solved

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

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

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

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

Spraay is that infrastructure.

What We Actually Built

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

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

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

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

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

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

Why x402 Is the Payment Rail for Compute

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

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

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

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

The Landscape Is Moving Our Way

Look at the signals beyond Fink's statement:

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

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

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

We have answers. Live ones.

What Comes Next

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

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

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

It already is.

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

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

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

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

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

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

The Canton context

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

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

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

Where batch payments fit

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

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

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

What's live

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

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

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

Spraay just introduced new endpoints for Solana Agents.

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

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

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

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

What's new

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

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

What you don't deal with

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

Working code

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

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

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

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

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

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

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

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

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

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

Endpoint details, quickly

Jupiter

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

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

Helius DAS

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

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

Pyth

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

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

Trying it before you integrate

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

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

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

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

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

Error handling notes worth knowing

A few things that will save debugging time:

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

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

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

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

npx skills add plagtech/spraay-agent-skills

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

What problem does this solve?

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

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

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

Why an agent skill?

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

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

When an agent reads the Spraay skill, it knows:

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

The agent becomes payment-capable in one install.

What's covered

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

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

15 chains, real contracts

Every EVM chain has a verified, deployed batch contract:

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

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

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

How the gateway works

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

The flow is simple:

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

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

Quick integration

import { createClient } from "x402-client";

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

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

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

Where this fits in the Vercel ecosystem

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

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

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

Try it

Install the skill:

npx skills add plagtech/spraay-agent-skills

Or use the dApp directly: spraay.app

Full gateway docs: docs.spraay.app

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

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

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

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

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

Not anymore.

What We Shipped

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

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

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

Three Payment Rails, One Gateway

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

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

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

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

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

How It Works (Agent Perspective)

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

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

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

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

Discovery Endpoints

Agents can auto-discover payment options at:

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

What's Covered

93+ paid endpoints across 21 categories:

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

All of these now accept payment on Base or Solana.

Technical Implementation

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

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

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

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

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

Try It

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

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

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

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

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

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

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

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

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

Two Ways to Use Spraay

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

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

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

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

What You Get Access To

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

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

How Subscriptions Work

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

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

Rotate your key if compromised:

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

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

Why Both Models?

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

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

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

Built on Base

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

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

Get Started

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

How to pay 100 agents in a single x402 call

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

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

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

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

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

The cost of doing it wrong

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

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

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

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

Why x402 needs this primitive

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

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

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

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

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

The endpoint

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

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

Request shape:

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

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

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

Calling it from an agent

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

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

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

const fetchWithPayment = wrapFetchWithPayment(fetch, wallet);

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

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

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

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

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

Where this fits in a larger agent

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

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

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

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

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

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

Try it

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

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

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

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

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

Build something. Pay everyone. In one call.

— @mr_hamlin

How to Use Bittensor Like OpenAI (3 Lines of Code)

Mr Hamlin — Thu, 09 Apr 2026 16:25:32 +0000

Every OpenAI-compatible SDK works with Bittensor now. No wallet. No TAO. No subnet knowledge. Just one line:

const client = new OpenAI({
  baseURL: "https://gateway.spraay.app/bittensor/v1",
});

That's it. You're on decentralized AI.

What this is

Spraay Inference is a drop-in replacement for OpenAI's API that routes to Bittensor's decentralized AI network under the hood. Same /v1/chat/completions endpoint, same request format, same SDK support.

The difference: instead of hitting OpenAI's servers, your requests go to Subnet 64 (Chutes AI) — a decentralized network of GPU miners competing to serve the best inference. Every response is TEE-verified (Trusted Execution Environment), meaning you get cryptographic proof the model actually ran your prompt.

43+ models available today, including:

DeepSeek V3.2, DeepSeek R1 (reasoning)
Qwen3 32B, Qwen3 235B
GPT-OSS 120B (OpenAI's open-source model)
Mistral Small 3.1
And many more

Why switch from OpenAI?

Cost. Bittensor inference runs 40-85% cheaper than centralized providers because miners compete on price. A typical DeepSeek V3 call costs ~$0.25/M input tokens vs OpenAI's $2.50/M for GPT-4o.

Openness. Every model on Bittensor is open-source. No black boxes.

Permissionless. No one can revoke your access, change your pricing overnight, or censor your outputs.

Verifiable. TEE verification means you can prove the model ran exactly as specified — important for agent pipelines where trust matters.

Full example

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://gateway.spraay.app/bittensor/v1",
  apiKey: "not-needed", // x402 handles payment
});

const response = await client.chat.completions.create({
  model: "deepseek-ai/DeepSeek-V3-0324",
  messages: [
    { role: "system", content: "You are a helpful assistant." },
    { role: "user", content: "Explain how Bittensor's subnet architecture works." }
  ],
  max_tokens: 512,
  temperature: 0.7,
});

console.log(response.choices[0].message.content);

Python works too:

from openai import OpenAI

client = OpenAI(
    base_url="https://gateway.spraay.app/bittensor/v1",
    api_key="not-needed",
)

response = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-R1-0528",
    messages=[{"role": "user", "content": "What is proof of intelligence?"}],
)

print(response.choices[0].message.content)

cURL:

curl -X POST https://gateway.spraay.app/bittensor/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-32B",
    "messages": [{"role": "user", "content": "Hello from Bittensor"}],
    "max_tokens": 256
  }'

Available endpoints

The API follows OpenAI's specification exactly:

Endpoint	Method	Description
`/bittensor/v1/models`	GET	List all available models
`/bittensor/v1/chat/completions`	POST	Chat completions (streaming supported)
`/bittensor/v1/images/generations`	POST	Image generation
`/bittensor/v1/embeddings`	POST	Text embeddings
`/bittensor/v1/health`	GET	Health check

Streaming, function calling, structured output, and tool use all work as expected.

How it works under the hood

Your app (OpenAI SDK)
    ↓ standard HTTP request
Spraay Gateway (gateway.spraay.app)
    ↓ x402 payment verification
    ↓ model → provider routing
Bittensor Subnet 64 (Chutes AI)
    ↓ distributed across GPU miners
    ↓ TEE-verified execution
Response back to your app

The Spraay x402 Gateway handles payment via the x402 protocol — HTTP-native micropayments in USDC on Base. Agents can consume inference autonomously without API keys or accounts. This is designed for the agentic future where software pays for its own compute.

For AI agent developers

If you're building autonomous agents with LangChain, CrewAI, AutoGPT, or any framework that uses OpenAI-compatible endpoints, Spraay Inference is the simplest way to put your agents on decentralized AI:

# LangChain example
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    base_url="https://gateway.spraay.app/bittensor/v1",
    model="deepseek-ai/DeepSeek-V3.2",
    api_key="not-needed",
)

response = llm.invoke("Analyze the top Bittensor subnets by revenue")

The x402 payment model means your agent doesn't need a credit card, an account, or even a human in the loop. It pays per-request in USDC and gets inference back. That's the unlock for truly autonomous AI agents.

Try it now

Live playground (no setup needed): spraay.app/bittensor

Gateway endpoint: gateway.spraay.app/bittensor/v1

Spraay Protocol: spraay.app | Gateway docs

Spraay Inference is part of the Spraay x402 Gateway — 88+ pay-per-call API endpoints for AI, payments, DeFi, and infrastructure on Base. Built for agents.

$TAO 💧

I built a tool to send TAO to 100+ wallets in one transaction (Bittensor payouts)

Mr Hamlin — Wed, 01 Apr 2026 21:01:17 +0000

Bittensor subnet operators often need to send TAO payouts to multiple wallets — miners, contributors, validators.

Right now, most people are:

sending transactions one by one
writing custom scripts
or dealing with error-prone payout flows

So I built something simple:

👉 A way to batch TAO payouts in a single transaction

🚀 The problem: TAO payouts don’t scale well

If you’re running a Bittensor subnet, you’ve probably run into this:

you have a list of wallet addresses
each one needs a payout
you’re sending transactions manually or via scripts

This leads to:

wasted time
higher chance of mistakes
poor scalability as your subnet grows

There wasn’t a clean, simple way to:

👉 send TAO to multiple wallets at once

⚡ The solution: TAO Batch Payouts

I built a tool called:

👉 TAO Batch Payouts

It lets you:

paste wallet addresses + amounts
review the payouts
send everything in one transaction

No scripts. No manual sending.

🧠 How it works

The flow is intentionally simple:

Paste wallets + amounts (or upload CSV)
Click Review & Send
Confirm the payouts
Execute the batch transaction

That’s it.

💡 Example input

5F3sa2TJ...freqmY4p 1.5
5Grwva...GkutQY     2.3
5FHneW...M694ty     0.75

🔍 Why this matters

This isn’t just convenience — it solves a real pain in the Bittensor ecosystem:

✅ Batch payments

Send to 100+ wallets in one transaction

✅ Less manual work

No more copy-paste wallet-by-wallet

✅ Fewer errors

Review everything before sending

✅ Built for subnet operators

Designed specifically for TAO distribution and rewards

🔗 Try it here

👉 https://spraay.app/tao-batch

🧾 Pricing

1% batch fee
applied at confirmation
fully transparent before sending

🧠 Under the hood

This is powered by Spraay, a multi-chain batch payment infrastructure.

The idea is simple:

👉 make multi-wallet crypto payouts as easy as a single transaction

🤖 Bigger picture: programmable payments for AI agents

This tool is just one piece of a larger direction:

AI agents making payments
automated reward distribution
machine-to-machine transactions

Batch payouts are a foundational primitive for:

👉 agent-native payments + programmable finance

📌 Keywords (for devs searching this)

If you’re here looking for:

how to send TAO to multiple wallets
batch crypto payments
bittensor payouts automation
distribute TAO rewards
multi wallet crypto transactions
bulk crypto payments

This tool was built for exactly that.

🙏 Feedback

If you’re running a Bittensor subnet or dealing with TAO payouts:

how are you handling payouts today?
manual? scripts? something else?

Would love feedback or ideas.

👋 Closing

This started as:

👉 “there has to be an easier way to send payouts”

And turned into a simple tool you can use right now.

If it saves you time (or prevents one mistake), it’s doing its job.

👉 https://spraay.app/tao-batch

🚀 I built an API where an AI agent can verify an invoice and pay it in USDC

Mr Hamlin — Tue, 31 Mar 2026 20:57:38 +0000

Most accounts payable workflows still look like this:

Someone emails a PDF invoice
Someone checks it against a purchase order
Someone approves it
Someone logs into a bank and sends the payment

⏳ It takes days.
💸 It costs money.
🧠 It requires humans in the loop.

⚡ So I built something simpler

An API where an AI agent can verify an invoice and pay a supplier in one flow.

No API keys.
No accounts.
Just pay per request.

🧠 The idea

Instead of humans doing invoice checks, an agent can run:

Create PO → Submit invoice → Verify → Pay

That’s it.

👉 From invoice → verified → paid in seconds.

🔥 The flow (3 calls that matter)

Here’s the entire loop.

🧾 1. Submit an invoice

curl -X POST https://gateway.spraay.app/api/v1/sctp/invoice \
  -H "Content-Type: application/json" \
  -d '{
    "poId": "po_123",
    "supplierId": "sup_abc",
    "items": [
      {
        "description": "Resistor 10K x1000",
        "quantity": 1000,
        "unitPrice": 0.02
      }
    ],
    "total": 20.00
  }'

✅ 2. Verify it (this is the interesting part)

curl -X POST https://gateway.spraay.app/api/v1/sctp/invoice/verify \
  -H "Content-Type: application/json" \
  -d '{"invoiceId": "inv_456"}'

⚡ Exact match (instant)

{
  "status": "matched",
  "confidence": 0.99,
  "verifiedBy": "deterministic",
  "latencyMs": 42,
  "recommendation": "approve_payment"
}

🧠 Fuzzy match (AI reasoning)

{
  "status": "partial_match",
  "confidence": 0.87,
  "verifiedBy": "ai",
  "latencyMs": 1340,
  "discrepancies": [
    "Description variation: 'Resistor 10K' vs 'Resistors 10KΩ (1000pc)'"
  ],
  "recommendation": "approve_payment"
}

💸 3. Pay the supplier

curl -X POST https://gateway.spraay.app/api/v1/sctp/pay \
  -H "Content-Type: application/json" \
  -d '{
    "invoiceId": "inv_456",
    "supplierId": "sup_abc",
    "amount": 20.00,
    "token": "USDC",
    "chain": "base"
  }'

Response

{
  "status": "processing",
  "estimatedSettlement": "~2s"
}

⚙️ How it works

The /verify endpoint uses a two-step system:

⚡ Fast path (~50ms)

Deterministic checks
Totals, quantities, prices
Instant match → high confidence

🧠 Slow path (~1–2s)

LLM reasoning for fuzzy cases
Handles naming differences, rounding, inconsistencies

💡 Why this matters

This isn’t just another API.

It changes how financial workflows work:

❌ No dashboards
❌ No logins
❌ No subscriptions

Instead:

Programmable financial infrastructure that agents can use directly

An AI agent can:

receive an invoice
verify it
decide based on confidence
execute payment

All without a human.

👀 Who this is for

🤖 AI CFO / finance agents
🪙 Crypto startups paying vendors
🏛️ DAOs managing contributor payments
🧑‍💻 Indie hackers automating ops

🧪 What this is (and isn’t)

This is v0.1 of something I’m calling:

Supply Chain Task Protocol (SCTP)

Right now it focuses on:

invoices
verification
payments

Later, it may expand into:

escrow
shipment tracking
document verification

…but only after this core loop is proven.

🔗 Try it yourself

👉 https://gateway.spraay.app

👉 https://github.com/plagtech/sctp

If you're building AI agents and want to automate real-world workflows, I’d love feedback.

This is one of those things that either clicks immediately…

or sounds insane.

I’m betting on the former.

The agentic economy isn't a whitepaper anymore. Here's what the numbers say: 250,000 AI Agents Are Live On-Chain.

Mr Hamlin — Fri, 27 Mar 2026 02:47:02 +0000

On March 9, 2026, Coinbase CEO Brian Armstrong posted five sentences that rattled the entire payments industry:

"Very soon there are going to be more AI agents than humans making transactions. They can't open a bank account, but they can own a crypto wallet. Think about it."

Two weeks later, the data is starting to prove him right.

The Numbers Are Real Now

Daily active on-chain AI agents crossed 250,000 in early 2026 — a 400%+ increase from 2025. More than 68% of new DeFi protocols launched in Q1 2026 included at least one autonomous AI agent for trading or liquidity management. AI-powered agents now represent roughly 18% of total prediction market volume, outperforming human traders by 27% on accuracy.

This isn't speculative anymore. The machines are transacting.

Coinbase launched Agentic Wallets on February 11, 2026, via the x402 protocol — an open payment standard built for machine-to-machine transactions. By the time Armstrong made his post, the protocol had already processed over 50 million transactions. CZ, the founder of Binance, echoed the thesis the very next day: AI agents will make millions of times more payments than humans, and they'll use crypto to do it.

Why Stablecoins Are the Default

The reason agents are gravitating toward stablecoins isn't ideological — it's engineering.

Traditional payment rails weren't built for this. Credit cards have minimum fees around $0.30 per transaction. Banks require KYC, government IDs, and human identity verification. AI agents can't satisfy any of those requirements. But they can generate a cryptographic private key in milliseconds and start transacting globally.

Stablecoins solve every friction point an autonomous agent faces:

Programmability — spending limits, conditional flows, and policies enforced at the wallet layer
Always-on settlement — blockchains don't close on weekends
Price stability — agents can budget in USD terms without spot-crypto volatility
Micropayment economics — fractions of a cent per API call, per data query, per task

CB Insights projects that stablecoins will transition from crypto-native trading tools to the settlement layer for agent-driven commerce in 2026. Circle CEO Jeremy Allaire has called USDC the "best dollar API" for AI's global economic system. And the data backs it up — on-chain analysis shows USDC accounts for 98.6% of agent transactions on EVM chains and 99.7% on Solana within the x402 ecosystem.

The stablecoin market has matured into a $46 trillion annualized transaction volume economy. That's 20x PayPal and rivaling major card networks.

x402: HTTP for Money

The protocol making all of this work is x402 — and it just got a major upgrade.

x402 resurrects the long-dormant HTTP 402 "Payment Required" status code and turns it into a machine-readable payment negotiation layer. When an AI agent hits a paid endpoint, the server returns a 402 with payment details. The agent pays in USDC. Retries the request with a payment receipt header. No human intervention required.

Here's the flow:

Agent requests a resource
Server responds 402 Payment Required with price + recipient
Agent signs and submits payment
Agent retries with payment proof in the header
Server delivers the resource

No accounts. No subscriptions. No API keys. Just money moving at HTTP speed.

On March 22, x402 V2 shipped — adding multi-chain support, wallet-based identity, dynamic payment recipients, and a fully modular SDK. Coinbase and Cloudflare co-founded the x402 Foundation to govern the standard. The protocol is now live on Base, Solana, Ethereum L2s, and even Etherlink (Tezos). Cloudflare integrated x402 into both its Agents SDK and MCP servers.

The v1.0 spec freeze is targeted for Q3 2026, after which backward compatibility guarantees kick in.

The Identity Gap: KYA Is the New KYC

But payments alone don't solve the full picture. If agents can transact freely, how do you know who (or what) is behind each one?

a16z's crypto research team frames it this way: the bottleneck for the agent economy has shifted from intelligence to identity. In financial services, non-human identities already outnumber human employees 96-to-1 — yet these identities remain "unbanked ghosts." Agents need cryptographically signed credentials that link them to their principal, their constraints, and their liability.

Sam Altman's World project launched AgentKit on March 17 to address exactly this — a toolkit that lets AI agents carry zero-knowledge proof that a verified human is behind them. It integrates directly with x402, positioning World as the identity layer for the agentic web.

The industry that built KYC infrastructure over decades now has months to figure out KYA — Know Your Agent.

What This Means for Builders

If you're building in crypto right now, the signal is clear: the next wave of users isn't human.

The infrastructure play is wide open. Consider what's needed:

Payment rails — x402 gateways, facilitators, and middleware that let any API accept stablecoin micropayments per request.

Agent wallets — programmable wallets with session keys, spending policies, and budget controls that don't require human authorization per transaction.

Identity and trust — reputation systems and verifiable credentials for agents, so merchants and protocols can assess risk without blocking every non-human actor at the firewall.

Physical-world bridging — as AI agents move from digital tasks to coordinating physical robots and IoT devices, payment protocols need to extend into hardware.

I've been building in this exact space. Spraay is a multi-chain batch payment protocol with a live x402 gateway at gateway.spraay.app — 76+ paid endpoints across 13 chains, all accepting USDC micropayments per request. We just shipped Agent Wallets (Category 17) on Base mainnet, and we're working on the Robot Task Protocol (RTP) — an open standard for AI agents to hire physical robots via x402 micropayments.

The agentic economy is being built right now, in public, by independent builders. If you're waiting for a Fortune 500 company to hand you the playbook, you're already behind.

The Reality Check

Let's be honest about where things stand. Despite the narrative momentum, x402's average daily transaction volume is still around $28,000, and analysts estimate roughly half of that is wash trading or self-dealing. The gap between the vision and the current volume is real.

But as one analyst put it: the growth rate of the agent economy may be overestimated for the coming year, but its potential may be underestimated five years from now.

250,000 daily active agents. $46 trillion in stablecoin volume. 50 million x402 transactions. Two of crypto's most prominent founders publicly declaring that machines will dominate financial transactions.

The infrastructure layer is being poured. The question isn't if agents will be the primary users of crypto — it's whether you'll be building the rails they run on, or watching from the sidelines.

💧 Building in the agentic economy? Check out Spraay — batch payments, x402 gateway, agent wallets, and RTP across 13 chains. Docs | MCP Server | GitHub

Follow me for daily posts on building crypto infrastructure for AI agents: @mr_hamlin on dev.to | @Spraay_app on X

I Just Gave AutoGPT the Ability to Send Crypto Payments

Mr Hamlin — Tue, 24 Mar 2026 06:32:40 +0000

AI agents are getting smarter every week. They can browse the web, write code, manage your calendar, and post on social media. But ask one to pay someone? That's where they hit a wall.

I just opened PR #12533 on AutoGPT — the biggest open-source AI agent platform on GitHub — adding native crypto payment blocks powered by Spraay, the multi-chain batch payment gateway I've been building.

This is the first crypto payment integration in AutoGPT's block ecosystem. Here's why it matters and how I built it.

The problem: AI agents can't pay for anything

Think about it. AutoGPT can already:

Scrape Reddit for trending topics and create video content
Monitor your YouTube channel and auto-generate blog posts
Manage GitHub issues and coordinate workflows

But the moment an agent needs to compensate a freelancer, pay a bounty, or settle an invoice? It's stuck. There's no native payment rail.

Traditional payment APIs (Stripe, PayPal) require KYC, bank accounts, and don't work well for autonomous systems. Crypto solves this — specifically stablecoins like USDC that don't fluctuate in value.

Enter x402: HTTP meets crypto payments

The x402 protocol is elegantly simple. It extends HTTP with status code 402 (Payment Required) to let APIs accept USDC micropayments per request. No subscriptions. No invoices. Just pay-per-call.

Spraay's gateway sits at gateway.spraay.app and exposes 76+ paid endpoints across 13 blockchain networks. When an AI agent calls the API, it pays a fraction of a cent in USDC and gets the service done. That's the entire auth model.

What I built: 4 payment blocks

AutoGPT's platform uses a modular "block" system. Each block performs a single action, and users chain them together visually to build agent workflows. I added four blocks:

SpraayBatchPaymentBlock — The flagship. Send payments to multiple recipients in a single on-chain transaction. One call, multiple payees, massive gas savings.

SpraayTokenTransferBlock — Simple one-to-one transfer. Agent pays someone. Done.

SpraayGetBalanceBlock — Check any wallet's token balance on any chain. Essential for pre-flight checks before sending payments.

SpraayTransactionStatusBlock — Track confirmation status. Lets agents wait for finality before proceeding in a workflow.

The code: how AutoGPT blocks work

AutoGPT blocks follow a clean pattern: a Python class inheriting from Block, with typed input/output schemas and an async run method. Here's a simplified look at the batch payment block:

class SpraayBatchPaymentBlock(Block):

    class Input(BlockSchema):
        credentials: spraay_provider.credentials_field()
        chain: ChainNetwork = SchemaField(
            description="Blockchain network to send payments on",
            default=ChainNetwork.BASE,
        )
        recipients: list[str] = SchemaField(
            description="List of recipient wallet addresses",
        )
        amounts: list[str] = SchemaField(
            description="List of amounts to send",
        )

    class Output(BlockSchema):
        transaction_hash: str = SchemaField(...)
        status: str = SchemaField(...)
        error: str = SchemaField(...)

    async def run(self, input_data: Input, **kwargs):
        result = spraay_request(
            method="POST",
            endpoint="/v1/batch/send",
            api_key=api_key,
            json_body={
                "chain": input_data.chain.value,
                "recipients": input_data.recipients,
                "amounts": input_data.amounts,
            },
        )
        yield "transaction_hash", result["transaction_hash"]
        yield "status", result["status"]

The provider config uses AutoGPT's ProviderBuilder for API key management:

from backend.sdk import BlockCostType, ProviderBuilder

spraay_provider = (
    ProviderBuilder("spraay")
    .with_api_key("SPRAAY_API_KEY", "Spraay x402 Gateway API Key")
    .with_base_cost(1, BlockCostType.RUN)
    .build()
)

Clean, typed, testable. Every block includes test_input, test_output, and test_mock so it plugs right into AutoGPT's test suite.

What you can build with this

Once these blocks are merged, AutoGPT agents can do things like:

Freelancer payroll agent — Reads a Google Sheet of contractors, batch pays them all in USDC on Base. One transaction. Done weekly on a schedule.

Bounty payer — Monitors GitHub issues tagged bounty. When a linked PR gets merged, it automatically pays the contributor's wallet.

Agent-to-agent payments — One agent hires another agent for a subtask and pays via x402. This is the foundation of an autonomous agent economy.

Conditional payment workflows — Check balance → if sufficient funds → send batch payment → verify confirmation → log to Google Sheets. All without human intervention.

13 chains, one API

The blocks support every chain Spraay runs on:

Base, Ethereum, Arbitrum, Polygon, BNB Chain, Avalanche, Unichain, Plasma, BOB, Solana, Bittensor, Stacks, and Bitcoin.

Each chain is a simple enum value. Switch from Base to Solana by changing one field. The gateway handles all the chain-specific logic.

Why open source this into AutoGPT?

Visibility and ecosystem growth. AutoGPT has 183K stars and an active contributor community. Getting payment blocks into their marketplace means every AutoGPT user can add crypto payments to their agents without writing custom code.

It's also a signal. AI agents handling money is inevitable. The infrastructure should be open, auditable, and composable — not locked behind proprietary APIs.

What's next

The PR is live at #12533. If you're interested in AI agent payments, here are some links:

Spraay gateway: gateway.spraay.app
Docs: docs.spraay.app
MCP server (for Claude, Cursor, etc.): @plagtech/spraay-x402-mcp
GitHub: github.com/plagtech

If you're building agents that need to move money, I'd love to hear what you're working on. Drop a comment or find me on X at @Spraay_app.

Follow me for more on building crypto infrastructure for AI agents. I write daily about Web3, x402, and the agent economy.

DEV Community: Mr Hamlin

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

The Signal No One Should Ignore

The Problem Everyone Sees but Nobody Has Solved

What We Actually Built

Why x402 Is the Payment Rail for Compute

The Landscape Is Moving Our Way

What Comes Next

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

The Canton context

Where batch payments fit

What's live

Spraay just introduced new endpoints for Solana Agents.

What's new

What you don't deal with

Working code

Endpoint details, quickly

Jupiter

Helius DAS

Pyth

Trying it before you integrate

Error handling notes worth knowing

Links

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

What problem does this solve?

Why an agent skill?

What's covered

15 chains, real contracts

How the gateway works

Quick integration

Where this fits in the Vercel ecosystem

Try it

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

What We Shipped

Three Payment Rails, One Gateway

How It Works (Agent Perspective)

Discovery Endpoints

What's Covered

Technical Implementation

Try It

Links

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

Two Ways to Use Spraay

What You Get Access To

How Subscriptions Work

Why Both Models?

Built on Base

Get Started

How to pay 100 agents in a single x402 call

The cost of doing it wrong

Why x402 needs this primitive

The endpoint

Calling it from an agent

Where this fits in a larger agent

Try it

How to Use Bittensor Like OpenAI (3 Lines of Code)

What this is

Why switch from OpenAI?

Full example

Available endpoints

How it works under the hood

For AI agent developers

Try it now

I built a tool to send TAO to 100+ wallets in one transaction (Bittensor payouts)

🚀 The problem: TAO payouts don’t scale well

⚡ The solution: TAO Batch Payouts

🧠 How it works

💡 Example input

🔍 Why this matters

✅ Batch payments

✅ Less manual work

✅ Fewer errors

✅ Built for subnet operators

🔗 Try it here

🧾 Pricing

🧠 Under the hood

🤖 Bigger picture: programmable payments for AI agents

📌 Keywords (for devs searching this)

🙏 Feedback

👋 Closing