DEV Community: Mr Hamlin

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.

How AI Agents Pay for APIs Without Exposing Private Keys: OWS + Spraay

Mr Hamlin — Mon, 23 Mar 2026 18:29:27 +0000

The agent economy just got its wallet layer.

Today MoonPay launched the Open Wallet Standard (OWS) — an open-source protocol that gives AI agents a single, encrypted vault for storing keys and signing transactions across every major blockchain. One seed phrase, one signing interface, eight chain families. Keys never leave your machine.

The coalition backing it reads like a who's who: PayPal, OKX, Ripple, Solana Foundation, Ethereum Foundation, Base, Polygon, Arbitrum, Circle, Virtuals, LayerZero, and more — 21 founding organizations in total.

But here's the part that caught my attention: OWS explicitly names x402 as the payment protocol it was built to serve.

I build Spraay — an x402 payment gateway with 76+ paid endpoints across 13 chains. So I spent the morning digging into the OWS spec, installing the SDK, and testing how well it plugs into our stack.

Short answer: it fits like a glove.

The Problem OWS Solves

Right now, if you're building an AI agent that pays for things — API calls, compute, data — you're probably doing something like this:

PRIVATE_KEY=0xabc123... # sitting in .env

Your agent reads that key at startup, holds it in memory, and passes it to whatever signing library you're using. If you're on EVM, you're using ethers.js. Solana? Different library, different key format. Bitcoin? Yet another one.

Three private keys. Three surfaces where they can leak — through logs, crash dumps, or the LLM context window itself.

OWS replaces all of that with:

const { createWallet, signTypedData } = require("@open-wallet-standard/core");

const wallet = createWallet("agent-treasury");
// => addresses for EVM, Solana, BTC, Cosmos, Tron, TON, Filecoin, Sui

const sig = signTypedData("agent-treasury", "evm", typedDataJson);
// Private key decrypted in Rust enclave, signed, immediately wiped

One seed. Eight chain families. Keys encrypted at rest with AES-256-GCM, decrypted only inside an isolated signing process, held in mlocked memory (pinned, never swapped to disk), and zeroized the moment the signature is produced.

Your agent never sees the private key.

Where Spraay Comes In

x402 is Coinbase's protocol for machine-to-machine payments. The flow works like this:

Agent requests an API endpoint
Server returns 402 Payment Required with a payment spec
Agent signs an EIP-3009 TransferWithAuthorization (typed data)
Agent retries with the signed payment in a header
Server verifies payment, returns the data

Steps 1, 4, and 5 are handled by the Spraay gateway. But step 3 — signing the payment — is where OWS comes in.

Until now, every agent doing x402 payments had to manage its own keys. OWS standardizes that layer so any agent, any framework, any tool can use the same wallet with the same security model.

Building It: 10 Lines to Paid API Calls

I tested this hands-on with the OWS Node SDK (@open-wallet-standard/core). Here's a complete flow — create a wallet, sign an x402 payment for a Spraay API call:

const { createWallet, signTypedData } = require("@open-wallet-standard/core");

// 1. Create wallet (one seed → addresses on every chain)
const wallet = createWallet("my-agent");
const evmAddress = wallet.accounts.find(a => a.chainId.startsWith("eip155:")).address;

// 2. Build the x402 payment (EIP-3009 TransferWithAuthorization)
const typedData = JSON.stringify({
  types: {
    EIP712Domain: [
      { name: "name", type: "string" },
      { name: "version", type: "string" },
      { name: "chainId", type: "uint256" },
      { name: "verifyingContract", type: "address" }
    ],
    TransferWithAuthorization: [
      { name: "from", type: "address" },
      { name: "to", type: "address" },
      { name: "value", type: "uint256" },
      { name: "validAfter", type: "uint256" },
      { name: "validBefore", type: "uint256" },
      { name: "nonce", type: "bytes32" }
    ]
  },
  primaryType: "TransferWithAuthorization",
  domain: {
    name: "USD Coin",
    version: "2",
    chainId: "8453",  // Base
    verifyingContract: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
  },
  message: {
    from: evmAddress,
    to: "0xAd62f03C7514bb8c51f1eA70C2b75C37404695c8",  // Spraay
    value: "100000",  // $0.10 USDC
    validAfter: "0",
    validBefore: String(Math.floor(Date.now() / 1000) + 3600),
    nonce: "0x" + [...crypto.getRandomValues(new Uint8Array(32))]
      .map(b => b.toString(16).padStart(2, "0")).join("")
  }
});

// 3. Sign it (key never leaves the Rust enclave)
const sig = signTypedData("my-agent", "evm", typedData);
console.log("Signature:", "0x" + sig.signature);

I ran this. It works. The OWS SDK produced a valid 65-byte secp256k1 signature with recovery ID, exactly what x402 expects. The signing happened in the native Rust core via NAPI-RS — no JavaScript crypto library touched the key material.

What the Vault Looks Like

After createWallet(), OWS stores everything at ~/.ows/ with 700 permissions:

~/.ows/
  wallets/
    480d3738-4839-4cb6-bbcf-2605eb841012.json   # encrypted keystore

Each wallet JSON uses the Ethereum Keystore v3 format — the same encryption that's been in production since 2015. One file, one seed, addresses for all chains.

The MCP Integration

Both OWS and Spraay expose MCP servers. This means an AI agent (Claude, GPT, LangChain, etc.) can have both tools loaded simultaneously:

{
  "mcpServers": {
    "ows": {
      "command": "ows",
      "args": ["serve", "--mcp"]
    },
    "spraay": {
      "command": "npx",
      "args": ["-y", "@plagtech/spraay-x402-mcp"]
    }
  }
}

OWS handles the wallet side (create, sign, manage keys). Spraay handles the payment side (76+ endpoints, 13 chains, token prices, batch payments, DeFi, RTP robot tasks). The agent orchestrates both without ever touching a private key.

Policy Engine: Spending Limits for Agents

One feature that's particularly useful for autonomous agents: OWS has a policy engine that evaluates rules before any key material is decrypted.

You can create API keys scoped to specific wallets, attach policies (spending limits, chain restrictions, recipient allowlists), and delegate them to sub-agents. The owner bypasses policies entirely — sudo access. Agent keys are constrained.

For Spraay payments, this means you could set:

Max $1.00 USDC per API call
Only Base chain allowed
Only the Spraay payment address in the recipient allowlist
Key expires in 24 hours

The agent can make as many API calls as it wants within those bounds. Step outside them and the policy engine blocks the signing request before the key is ever decrypted.

What's Next

I'm building a spraay-ows adapter package that will handle the full x402 payment flow in a single function call:

const { SpraayOWS } = require("spraay-ows");

const client = new SpraayOWS({ wallet: "my-agent" });
const { data } = await client.fetch("/v1/token/price?symbol=ETH&chain=base");

That's it. The adapter will handle the 402 response, construct the EIP-3009 typed data, call OWS for signing, encode the payment header, and retry — all transparently.

The code is already working in prototype. Will publish to npm once I've wired it into the Spraay gateway's test suite.

How to Add a Payment Layer to NVIDIA's Autonomous Agent Stack

Mr Hamlin — Sun, 22 Mar 2026 23:20:29 +0000

At GTC 2026 last week, Jensen Huang declared that "Claude Code and OpenClaw have sparked the agent inflection point — extending AI beyond generation and reasoning into action."

He's right. But there's a missing piece nobody on that stage talked about: agents that act need to pay.

Every time an autonomous agent spawns a sub-agent, accesses premium data, hires a robot, or compensates a contractor — there's a payment event. And right now, NVIDIA's agent stack (OpenShell, NemoClaw, NeMo Agent Toolkit) has no native payment rail.

I spent the last week building that missing piece.

The Problem

NVIDIA shipped an incredible agentic AI stack at GTC 2026:

OpenShell — the open-source sandbox runtime for autonomous agents
NemoClaw — the OpenClaw enterprise stack with security guardrails
NeMo Agent Toolkit — the library for connecting and optimizing teams of agents
Dynamo 1.0 — the distributed inference framework

These tools let agents reason, plan, and act inside isolated sandboxes with policy-enforced security. But when an agent needs to spend money — pay for an API call, send tokens to a contractor, fund an escrow — there's nothing in the stack for that.

The Solution: x402

The x402 protocol makes payments native to HTTP. It works like this:

Agent calls a paid API endpoint
Server returns HTTP 402 Payment Required with payment details in the header
Agent signs a USDC micropayment
Agent resends the request with the signed payment proof
Server verifies on-chain and executes the request

No API keys for payment. No wallet UX. No Stripe integration. Just pay-per-call with USDC.

I built Spraay — a gateway at gateway.spraay.app that exposes 76+ endpoints across 13 blockchains using this protocol. And this week I integrated it into three layers of NVIDIA's agent stack.

Integration 1: OpenShell Sandbox

OpenShell runs agents in isolated containers with policy-enforced egress. I built a Spraay sandbox image that any agent can launch with one command:

openshell sandbox create --from spraay -- claude

The sandbox includes:

A spraay CLI wrapper with 17 commands covering all gateway categories
4 agent skills (payments, escrow, RTP robot hiring, gateway discovery)
A locked-down network policy allowing only gateway.spraay.app and verified RPC providers
Python + Node.js crypto libraries for wallet operations

The key security property: private keys never leave the sandbox boundary. All payment signing happens inside the isolated OpenShell environment.

This is submitted as PR #50 to NVIDIA's OpenShell Community repo.

Integration 2: NeMo Agent Toolkit

NeMo Agent Toolkit lets you build agent workflows with a YAML config file. I created 8 custom async tools that connect to the Spraay gateway:

functions:
  spraay_balance:
    _type: spraay_balance
    description: "Check wallet balance on any chain"

  spraay_batch_send:
    _type: spraay_batch_send
    description: "Send tokens to multiple recipients"

  spraay_rtp_discover:
    _type: spraay_rtp_discover
    description: "Discover robots on the RTP network"

workflow:
  _type: react_agent
  tool_names: [spraay_balance, spraay_batch_send, spraay_rtp_discover]
  llm_name: nim_llm
  verbose: true

Now any NeMo Agent Toolkit agent can reason about payments and execute them:

nat run --config_file config.yml \
  --input "Check the USDC balance for 0xAd62...95c8 on Base"

This is submitted as PR #20 to NVIDIA's NeMo Agent Toolkit Examples repo.

Integration 3: NemoClaw Network Policy

NemoClaw sandboxes block all unauthorized outbound connections by default. For an OpenClaw agent to use Spraay, you need a network policy preset:

network:
  egress:
    - host: gateway.spraay.app
      port: 443
      methods: [GET, POST]
      paths: ["/v1/**", "/health"]
      note: "Spraay x402 payment gateway"

    - host: "*.base.org"
      port: 443
      methods: [POST]
      paths: ["/**"]
      note: "Base chain RPC for payment verification"

I submitted this as a feature request on the NemoClaw repo (13.9k stars) and as a preset PR to the awesome-nemoclaw community list.

The Physical AI Angle

Here's where it gets interesting. NVIDIA announced the Physical AI Data Factory Blueprint at GTC — an open architecture for training robotics systems. Spraay includes the Robot Task Protocol (RTP), an open standard for AI agents to hire robots via x402 USDC micropayments.

The RTP flow:

Agent discovers available robots/devices on the network
Agent reviews pricing and selects a device
Agent sends x402 micropayment to commission a physical task
Robot executes the task and reports results
On-chain proof of completion

This bridges NVIDIA's digital agent stack with their physical AI ambitions. When an agent running in OpenShell needs a robot to pick up a package, take a sensor reading, or run a 3D print job — RTP + Spraay is how it pays for that service.

What's Next

These integrations are all submitted and waiting for review. Whether they get merged or not, the architecture works today. You can point any agent at gateway.spraay.app and start executing payments via x402.

If you're building autonomous agents and need a payment rail, here are the resources:

Gateway: gateway.spraay.app
Docs: docs.spraay.app
MCP Server: @plagtech/spraay-x402-mcp on Smithery
x402 Protocol: x402.org
RTP Spec: github.com/plagtech/rtp-spec

The agent inflection point is here. Now agents can pay.

Built by @plagtech. Follow @Spraay_app for updates.

💧 Give Your LangChain Agent a Smart Wallet on Base

Mr Hamlin — Sun, 22 Mar 2026 04:12:44 +0000

Your AI agent can write emails, search the web, and query databases. But can it deploy a smart wallet?

Now it can.

I just published @spraay/langchain-agent-wallet — 5 LangChain StructuredTool classes that let your agent provision smart wallets, manage session keys, and predict wallet addresses on Base. Every call is paid with USDC micropayments via the x402 protocol. No API keys. No subscriptions. Just pay-per-call.

The Problem

AI agents are getting good at planning and reasoning. But when it comes to actually holding money and executing transactions, most frameworks punt. You end up with the agent's private key embedded in code, full access to everything, zero permission scoping.

That's not how you'd let a human employee operate. Why let your agent?

The Solution: Agent Wallets with Session Keys

Spraay's Agent Wallet infrastructure deploys a smart contract wallet for each agent on Base. The wallet is owned by you, but the agent gets a session key — a scoped, time-limited permission to act on behalf of the wallet.

Think of it like giving an employee a corporate card with a spending limit instead of handing them the company bank login.

The 5 Tools

npm install @spraay/langchain-agent-wallet @langchain/core

Tool	What it does	Cost
`spraay_provision_wallet`	Deploy a new smart wallet on Base	$0.05
`spraay_add_session_key`	Grant scoped permissions to an address	$0.02
`spraay_get_wallet_info`	Query wallet details and balance	$0.005
`spraay_revoke_session_key`	Remove a session key	$0.02
`spraay_predict_address`	Pre-compute CREATE2 wallet address	$0.001

Quick Start

import { ChatOpenAI } from "@langchain/openai";
import { createToolCallingAgent, AgentExecutor } from "langchain/agents";
import { ChatPromptTemplate } from "@langchain/core/prompts";
import { createSpraayWalletTools } from "@spraay/langchain-agent-wallet";

// Create all 5 tools with one function
const tools = createSpraayWalletTools({
  privateKey: process.env.EVM_PRIVATE_KEY!,
});

const llm = new ChatOpenAI({ model: "gpt-4o" });

const prompt = ChatPromptTemplate.fromMessages([
  ["system", "You are a Web3 agent that manages smart wallets on Base."],
  ["human", "{input}"],
  ["placeholder", "{agent_scratchpad}"],
]);

const agent = createToolCallingAgent({ llm, tools, prompt });
const executor = new AgentExecutor({ agent, tools });

// The agent decides which tool to call based on natural language
const result = await executor.invoke({
  input: "Deploy a new wallet for 0x1234...abcd labeled 'treasury'",
});

The LLM reads the tool descriptions and zod schemas to figure out which tool to call and what parameters to pass. You don't write any routing logic.

How x402 Payments Work

Every tool call hits the Spraay gateway at gateway.spraay.app. Instead of an API key, the request includes a signed payment header — your agent's private key authorizes a USDC micropayment on Base.

The gateway verifies the signature, settles the payment, and executes the operation. It's like HTTP 402 (Payment Required) actually working the way it was supposed to.

This means:

No API keys to manage or rotate
No rate limits — you pay for what you use
No subscription tiers — $0.001 to $0.05 per call
Permissionless — any agent with USDC on Base can use it

What's Deployed

The wallet contracts are live on Base mainnet:

Factory: 0xFBD832Db6D9a05A0434cd497707a1bDC43389CfD
Implementation: 0x61818Ae8bC161D1884Fd8823985B80e6733C34E7

The gateway serves 76+ paid endpoints across 16 categories and 13 chains. Agent Wallet is Category 17.

What's Next

This is one piece of a bigger push to get Spraay tooling into every major agent framework:

ElizaOS plugin — submitted to the registry
CrewAI tools — Python, no SDK dependency
MCP server — already live on Smithery as @plagtech/spraay-x402-mcp

If your agent needs to hold money, send payments, or manage wallets — and you don't want to hand it your private key — give this a try.

npm: @spraay/langchain-agent-wallet
GitHub: plagtech/langchain-spraay-wallet
Docs: docs.spraay.app

Built by @lostpoet / @Spraay_app

I Forked Abstract's Global Wallet to Give AI Agents Their Own Wallets on Base

Mr Hamlin — Sat, 21 Mar 2026 03:27:05 +0000

The Problem: AI Agents Need Wallets, and Nobody's Making It Easy

If you're building AI agents that interact with blockchain — trading bots, payment agents, autonomous task runners — you hit the same wall everyone hits: the agent needs a wallet.

Your options today are pretty bad:

Option 1: Hardcode a private key in .env. This is what most tutorials show you. It's also a disaster waiting to happen. One leaked key and your agent's funds are gone.

Option 2: Use a custodial wallet provider. Phantom has a Server SDK that lets you create wallets programmatically. Great concept. But you need to apply to their developer program and wait for approval. I've been waiting. And waiting.

Option 3: Manual setup. A human creates a MetaMask wallet, funds it, and pastes the key into the agent config. This works for demos. It does not work at scale when you need to spin up 100 agents.

None of these give you what agents actually need: a wallet with spending limits, time-bound sessions, and automatic expiry. You know, the kind of safety rails you'd want before letting an autonomous AI handle real money.

The Inspiration: Abstract Global Wallet

While building Spraay (a multi-chain batch payment protocol), I started exploring Abstract chain as a potential addition to our supported networks. Abstract is an L2 built by the Pudgy Penguins team, and their standout feature is the Abstract Global Wallet (AGW).

AGW is elegant. You sign up with an email, and a smart contract wallet gets deployed for you behind the scenes. No seed phrases. No browser extensions. The wallet travels with you across every app on Abstract. Under the hood, it uses:

A factory contract that deploys wallet instances via CREATE2
Native account abstraction for gasless transactions
Session keys for pre-authorized actions without repeated signing
Privy for key management (splitting the private key into three shards)

The architecture is adapted from Clave's zkSync contracts, and it's open source under GPL-3.0.

I looked at this and thought: this is exactly what AI agents need. But the SDK only works in browsers, and the chain is locked to Abstract.

The Fork: What I Kept and What I Changed

The AGW contracts repo gave me the blueprint. Here's what I adapted:

What I Kept

Factory pattern with CREATE2 — deterministic wallet addresses, minimal proxy clones (EIP-1167). Each wallet deployment costs roughly $0.01-0.05 in gas on Base.
Smart contract wallet architecture — the wallet is a contract, not an EOA. This enables programmable rules.
Session keys — the feature that makes this work for agents. A session key is a temporary signer with a spending limit, expiry time, and optional target restrictions.

What I Changed

Removed Privy key-sharding — AGW splits the private key into three shards (device, server, recovery cloud). Agents don't have devices or iCloud. In our version, agents either hold their own keys (self-custody) or the provisioning service generates and encrypts keys server-side (managed mode).
Deployed on Base instead of Abstract — Abstract's SDK is chain-locked due to their native account abstraction implementation. Our contracts are standard Solidity that works on any EVM chain. We deployed on Base because that's where the rest of the Spraay ecosystem lives.
Added agent metadata — Each wallet stores an agentId and agentType (e.g., "eliza", "langchain", "crewai"). This feeds into our trust scoring system.
Exposed via x402 gateway — Instead of a browser SDK, wallet provisioning happens through API endpoints on our payment gateway. An agent pays $0.05 USDC and gets a wallet.

The Architecture

AI Agent (ElizaOS / LangChain / CrewAI / etc.)
    │
    │  x402 USDC micropayment ($0.05)
    ▼
Spraay Gateway (gateway.spraay.app)
    │
    │  POST /v1/wallet/provision
    ▼
SpraayWalletFactory (Base)
    │
    │  CREATE2 deploy (EIP-1167 minimal proxy)
    ▼
SpraayAgentWallet
    ├── Session Keys (spending limits + time bounds)
    ├── Batch Execution (multi-call in one tx)
    └── Agent Metadata (identity + trust scoring)

The factory deploys minimal proxy clones — just 45 bytes of runtime bytecode that delegate all calls to the implementation contract. This keeps deployment gas costs extremely low.

The Contracts

SpraayAgentWallet.sol

The core wallet supports three main capabilities:

1. Session Keys

function addSessionKey(
    address sessionKey,
    uint256 spendLimitWei,
    uint256 validUntil,
    address[] calldata allowedTargets
) external onlyOwner;

An agent creates a session key with a spending cap, expiry, and optional contract whitelist. The session key can then sign transactions on behalf of the wallet within those bounds. If the key is compromised, damage is capped at the spending limit.

2. Batch Execution

function executeBatch(
    address[] calldata targets,
    uint256[] calldata values,
    bytes[] calldata datas
) external onlyOwnerOrValidSession;

Agents often need to do multiple things in one action — approve a token, then swap it, then send the result somewhere. Batch execution handles this atomically.

3. Agent Metadata

function setAgentMetadata(
    string calldata agentId,
    string calldata agentType
) external onlyOwner;

Every wallet knows what agent framework created it and carries a unique identifier. This connects to our ProofLayer trust scoring system — agents build reputation over time based on their on-chain behavior.

SpraayWalletFactory.sol

The factory takes an implementation address in its constructor and deploys clones:

constructor(address _implementation) {
    require(_implementation != address(0), "SWF: zero impl");
    admin = msg.sender;
    walletImplementation = _implementation;
}

function createWallet(
    address owner,
    string calldata agentId,
    string calldata agentType,
    bytes32 salt
) external whenNotPaused returns (address wallet) {
    bytes32 finalSalt = keccak256(abi.encodePacked(owner, salt));
    wallet = _deployClone(walletImplementation, finalSalt);
    SpraayAgentWallet(payable(wallet)).initialize(owner, agentId, agentType);
    _wallets.push(wallet);
    _isWallet[wallet] = true;
    emit WalletCreated(wallet, owner, agentId, agentType);
}

Deterministic addresses via CREATE2 mean you can predict a wallet's address before deploying it — useful for pre-funding scenarios.

Deployment

The contracts are live on Base Sepolia testnet:

Contract	Address
Implementation	`0xb6843955D914aD61dc6A4C819E0734d96467a391`
Factory	`0xe483F189af41FB5479cd8695DbbA16cc5CF1071D`
Demo Wallet	`0xcC74104d9d55889606e51FeD0f57c3AE23FC8054`

The deployment process had its share of nonce collisions and "replacement transaction underpriced" errors from rapid-fire attempts on the testnet RPC. Pro tip: when deploying multiple contracts in sequence, explicitly manage your nonces:

const nonce = await ethers.provider.getTransactionCount(deployer.address, 'pending');
const impl = await Impl.deploy({ nonce: nonce });
const factory = await Factory.deploy(implAddr, { nonce: nonce + 1 });

The SDK (Coming Soon)

Agent frameworks will be able to provision wallets with a few lines:

import { SpraayWallet } from 'spraay-agent-wallet';

const wallet = await SpraayWallet.provision({
  agentId: 'my-trading-agent',
  agentType: 'langchain',
  mode: 'managed',
}, {
  x402PaymentHeader: process.env.X402_HEADER,
});

// Add a session key: 0.5 ETH limit, 24 hours
const session = await wallet.addSessionKey({
  spendLimitEth: '0.5',
  durationHours: 24,
  allowedTargets: ['0x...BatchContract'],
});

The goal is one npm install and three lines of code. If it's harder than that, developers won't use it.

Why This Matters

The intersection of AI agents and crypto is heating up fast. Coinbase has x402 for agent-to-agent payments. Virtuals Protocol has an agent economy. Every major framework is adding tool-use capabilities that include blockchain interactions.

But the wallet layer has been ignored. Everyone assumes the agent already has a wallet. Nobody's asking: how does the agent get the wallet in the first place? And how do you put guardrails on it so it doesn't drain its funds on a bad decision?

Session keys are the answer. An agent with a session key that caps spending at 0.5 ETH per day, expires in 24 hours, and can only interact with three specific contracts is a fundamentally different risk profile than an agent holding an unrestricted private key.

What's Next

Base mainnet deployment — same contracts, real money
Gateway integration — wallet endpoints join the existing 76+ paid endpoints on Spraay's x402 gateway
Agent framework PRs — ElizaOS plugin, LangChain tool, CrewAI integration
ProofLayer scoring — wallet behavior feeds into agent trust scores
npm publish — spraay-agent-wallet package for drop-in SDK usage

Try It

The code is open source: github.com/plagtech/spraay-agent-wallet

Contracts are GPL-3.0, same license as the AGW contracts we forked from. If you're building agents that need wallets, take a look. If you have ideas for how session key policies should work for different agent types, open an issue.

Built by @lostpoet — building Spraay 💧, a multi-chain batch payment protocol with 76+ x402 gateway endpoints across 13 chains.

Thanks to the Abstract Foundation and Clave for the open source smart contract wallet architecture that made this possible.

Stripe Just Validated Agent Payments — Here's Why the Open Web Still Needs x402

Mr Hamlin — Thu, 19 Mar 2026 17:18:34 +0000

Stripe Just Said the Quiet Part Out Loud

Yesterday, Stripe and Paradigm launched Tempo — a payments-focused Layer 1 blockchain — alongside the Machine Payments Protocol (MPP), an open standard for AI agent-to-service payments.

The partner list reads like a who's who of global finance: Visa, Mastercard, OpenAI, Anthropic, DoorDash, Shopify, Revolut, Ramp, Nubank, and Standard Chartered.

Let that sink in. The world's largest payment processor just built a blockchain specifically so AI agents can pay for things.

If you've been building in the agent payments space, this is the validation moment. The thesis is no longer speculative. Stripe, with $1.9 trillion in annual payment volume, is betting its infrastructure future on the idea that machines will be the next wave of paying customers.

But here's where it gets interesting — and where builders need to pay attention to what's actually being built.

How MPP Works

The Machine Payments Protocol follows a straightforward flow:

An AI agent requests a resource from a service
The service responds with a payment request
The agent authorizes payment from its wallet
The transaction settles instantly on Tempo
The service delivers the resource

MPP also introduces sessions — described by Tempo as "OAuth for money." An agent authorizes once, then payments execute programmatically within defined limits. Think of it like an API key, but for spending.

Visa has extended MPP for card-based payments. Stripe extended it for cards and wallets. Lightspark extended it for Bitcoin payments over Lightning. The protocol is designed to be rail-agnostic.

This is genuinely impressive engineering. And it's going to accelerate the entire category.

But there's a catch.

MPP Runs on Tempo. Tempo Runs on Permission.

Tempo is a proprietary Layer 1 blockchain incubated by Stripe and Paradigm. It raised $500 million at a $5 billion valuation. Its engineering team includes former Optimism CEO Liam Horne and Paradigm CTO Georgios Konstantopoulos.

The partners building on it — Visa, Mastercard, Standard Chartered — are institutions that require compliance registries, KYC frameworks, and regulatory oversight baked into the chain itself.

That's not a criticism. It's a design choice. Tempo is built for enterprise-grade, regulated payment workloads. It has ISO 20022 compliance for banking integration. It has smart accounts with built-in governance.

But it's not the open web.

If you're an independent developer building an AI agent that needs to pay for an API call, you don't want to onboard to Tempo's partner ecosystem first. If you're a small team running a paid endpoint in Lagos or Bangalore, you don't want to wait for Stripe's compliance team to approve your service.

The open web runs on HTTP. And agent payments on the open web need something native to HTTP.

Enter x402: The Permissionless Alternative

The x402 protocol takes a fundamentally different approach. Instead of building a new blockchain for payments, it embeds payments into the protocol the web already runs on — HTTP.

Here's how x402 works:

An AI agent sends an HTTP request to a paid endpoint
The server responds with HTTP 402 Payment Required + payment details
The agent sends a USDC micropayment on-chain
The server verifies payment and returns the resource
All of this happens in a single HTTP request-response cycle

No new chain. No partner ecosystem. No compliance registry. Just HTTP + USDC + any EVM chain.

The 402 status code has been reserved in the HTTP specification since 1997 — literally waiting for digital payments to catch up. Coinbase formalized the x402 protocol to finally put it to use, and builders like us at Spraay have been running it in production.

The Real Comparison

Let's be honest about what each approach optimizes for:

MPP (Stripe/Tempo)

Optimized for: Enterprise, institutional, regulated workloads
Settlement: Tempo L1 (proprietary)
Partners: Visa, Mastercard, OpenAI, Anthropic, Shopify
KYC/Compliance: Built into the chain
Access model: Partner ecosystem onboarding
Best for: Large platforms integrating agent payments into existing Stripe infrastructure
Pricing: Sub-$0.001 fees on Tempo

x402 (Coinbase/Open Standard)

Optimized for: Permissionless, open web, developer-first
Settlement: Any EVM chain (Base, Ethereum, Arbitrum, Solana, etc.)
Partners: Anyone with an HTTP endpoint
KYC/Compliance: Not required at the protocol level
Access model: Permissionless — deploy and earn
Best for: Independent developers, API builders, open-source projects, global south builders
Pricing: Configurable per endpoint

These aren't competing standards. They're complementary layers for different parts of the economy.

MPP will handle the Shopify checkout, the DoorDash delivery payment, the enterprise SaaS billing. x402 will handle the indie API, the open-source tool, the agent-to-agent micropayment, the robot task commission — the long tail of the agent economy that institutional gatekeepers can't (and won't) serve.

What Spraay Is Doing With x402

We've been building the x402 gateway at gateway.spraay.app since early 2025. Today it has 76+ paid endpoints across 16 categories on 13 chains:

AI Inference — LLM access via OpenRouter and BlockRun (93 models)
RPC Access — Blockchain data via Alchemy across 7 chains
Communication — Email via AgentMail, messaging via XMTP
Storage — IPFS pinning via Pinata
Search/RAG — Web intelligence via Tavily
Robot Tasks — Physical robot commissioning via RTP (Robot Task Protocol)
Bitcoin — Non-custodial PSBT batch payments via Mempool.space
And 9 more categories covering oracles, compliance, compute, wallets, and more

Every endpoint accepts USDC micropayments via x402. Any agent — OpenClaw, NemoClaw, LangChain, CrewAI, or a custom script — can call these endpoints without onboarding, without KYC, without a Stripe account.

That's the point. The open web shouldn't require a permission slip to participate in the agent economy.

Why This Week Matters

In the span of 48 hours:

Stripe/Paradigm launched Tempo + MPP for institutional agent payments
Mastercard acquired stablecoin infrastructure firm BVNK for $1.8 billion
PayPal expanded cross-border stablecoin payments to 70 countries
SEC/CFTC classified 16 crypto assets as commodities (not securities)
NVIDIA projected $1 trillion in AI infrastructure spend through 2027

Every one of these events validates the same thesis: AI agents are becoming economic actors, and they need payment rails.

The institutional side is covered. Stripe, Mastercard, Visa, and PayPal are building for their customers.

But who's building for the rest of the web?

That's us. That's x402. That's every independent builder who ships a paid API endpoint and wants an AI agent to be able to pay for it — without asking anyone's permission.

Getting Started

If you want to explore agent payments via x402:

Use the Spraay gateway: gateway.spraay.app — 76+ endpoints ready for agent consumption
Read the x402 spec: Coinbase x402 repo
Build your own x402 endpoint: The facilitator pattern lets you add x402 payments to any Express.js server in ~20 lines of code
Try the MCP server: @plagtech/spraay-x402-mcp on Smithery — 66 tools for AI agent integration

The agent economy isn't coming. It launched this week. The question is whether it'll be open or closed.

We're betting on open.

💧 Spraay is a multi-chain batch payment protocol and x402 gateway. spraay.app | gateway.spraay.app | GitHub

What's your take — will MPP and x402 coexist, or will one standard win? Let me know in the comments.