DEV Community: 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.

NVIDIA Just Bet $1 Trillion on Agentic AI — Here's Why AI Agents Will Need Payment Rails

Mr Hamlin — Thu, 19 Mar 2026 16:51:29 +0000

The GTC 2026 Keynote Changed the Conversation

NVIDIA's GTC conference is happening right now in San Jose, and Jensen Huang's opening keynote just redefined what "AI infrastructure" means.

The headline number: $1 trillion in projected AI infrastructure orders through 2027 — double last year's estimate.

But the real story isn't the hardware. It's the shift from training AI models to deploying AI agents that do real work.

Here's what dropped:

Vera Rubin: The Agent Engine

The new Vera Rubin platform is a full-stack system — seven chips, five rack-scale configurations, one supercomputer — designed specifically for agentic AI.

The numbers are staggering:

5x inference performance over current Blackwell systems
10x lower cost per token
10x better performance per watt
Ships second half of 2026

Jensen framed it clearly: the AI industry is shifting from training (building the brain) to inference (the brain doing work). And the work is increasingly autonomous — agents that reason, plan, call tools, spawn sub-agents, and execute multi-step workflows without human supervision.

NemoClaw + OpenClaw: The Agent OS

Jensen called OpenClaw — the open-source agentic AI framework — "the most popular open source project in the history of humanity." NVIDIA announced full platform support through NemoClaw, their enterprise agent stack built on top of it.

The vision: agents that can navigate file systems, run scheduled tasks, decompose problems, connect to external tools, and work overnight without supervision.

Sound familiar? It should — this is exactly the kind of autonomous agent behavior that needs payment infrastructure.

Robotics: Disney's Olaf Walked On Stage

In one of the keynote's most memorable moments, Disney's Olaf character — a free-roaming autonomous robot — joined Jensen on stage. Built with reinforcement learning on NVIDIA's Warp framework, Olaf previewed a March 29 debut at Disneyland Paris.

Jensen predicted 10 million digital workers operating alongside humans — not just software agents, but physical robots. ABB, KUKA, Universal Robots, and Toyota Research Institute were all present. Over 110 robots were on the show floor.

The Missing Piece: How Do Agents Pay?

Here's what nobody at GTC is talking about: if AI agents are autonomous economic actors, they need payment rails.

Think about the agent workflow Jensen described:

Agent receives a task
Agent reasons about how to complete it
Agent calls external tools and APIs
Agent spawns sub-agents for subtasks
Agent delivers the result

Steps 3 and 4 are where payments happen. Every API call, every tool invocation, every sub-agent delegation is a potential transaction. And in a world of autonomous agents operating 24/7, these transactions can't require human approval for each one.

This is exactly the problem that x402 solves.

x402: HTTP-Native Payments for Agents

The x402 protocol (inspired by HTTP status code 402 "Payment Required") enables machine-to-machine micropayments at the HTTP layer. When an agent hits a paid endpoint, it receives a 402 response with payment details, automatically sends a USDC micropayment, and gets access — all without human intervention.

Spraay's x402 gateway implements this across 76+ paid endpoints in 16 categories:

AI Inference — agents paying for LLM access (OpenRouter, BlockRun)
RPC Access — agents paying for blockchain data (Alchemy, 7 chains)
Communication — agents paying to send emails (AgentMail) or messages (XMTP)
Storage — agents paying for IPFS pinning (Pinata)
Search/RAG — agents paying for web intelligence (Tavily)
And the newest category...

Robot Task Protocol: Where GTC Meets x402

RTP (Robot Task Protocol) is an open standard we built for AI agents to discover, commission, and pay for physical robot tasks via x402 USDC micropayments.

After watching Jensen's keynote, the timing couldn't be better. Here's how RTP maps to the GTC vision:

NVIDIA's Vision	RTP's Implementation
10M digital workers alongside humans	Agents discover available robots via RTP registry
Autonomous task execution	Agents commission robot tasks via HTTP endpoints
Agent-to-agent delegation	Software agents delegate physical tasks to robot agents
OpenClaw tool integration	RTP endpoints are standard HTTP — any agent framework can call them
Inference cost reduction	x402 micropayments keep per-task costs minimal

The Flow

AI Agent (OpenClaw/NemoClaw)
    ↓ discovers robot via RTP registry
    ↓ sends task request to robot endpoint
    ↓ receives 402 Payment Required
    ↓ pays $0.02 USDC via x402
    ↓ robot executes physical task
    ↓ agent receives confirmation

No human in the loop. No invoicing. No payment processing delays. Just an agent paying a robot to do work, settled in USDC on Base.

We've already built:

rtp-spec — the protocol specification
rtp-sdk — TypeScript SDK
rtp-python-sdk — Python SDK (PyPI: spraay-rtp)
rtp-pi-demo — working Raspberry Pi + servo motor demo
rtp-xmtp-mesh — agent-to-robot messaging layer

All open source under github.com/plagtech.

Why the 10x Token Cost Reduction Matters for Agent Payments

One of Vera Rubin's most important specs is the 10x reduction in inference token costs. Here's why that matters for the payment layer:

Right now, running an agentic workflow that calls 10 tools, reasons through 5 steps, and generates a final output might cost $0.15-$0.50 in inference. Add x402 payments for each tool call at $0.001-$0.01 each, and the total cost is $0.20-$0.60.

With Vera Rubin's cost reduction, the inference portion drops to $0.015-$0.05. The x402 micropayments become a proportionally larger — but still tiny — part of the total cost. This makes the entire autonomous agent workflow economically viable at massive scale.

Jensen described this as the "inflection point of inference." For payment infrastructure builders, it's the inflection point of agent commerce.

The Convergence

Three forces are converging right now:

Hardware (NVIDIA Vera Rubin) — makes agent inference 10x cheaper
Regulation (SEC/CFTC commodity ruling) — gives USDC and ETH clear legal status for payments
Infrastructure (x402 + RTP) — provides the payment rails agents actually need

The companies building at this intersection — where AI agents, physical robots, and on-chain payments meet — are building the infrastructure layer for the next economy.

NVIDIA sees it. They're calling it the era of "AI factories." We're calling it the era of autonomous agent commerce.

💧 Spraay is the x402 payment gateway powering agent-to-agent and agent-to-robot transactions. Explore the gateway or check out the Robot Task Protocol.

🤖 RTP is open source and looking for contributors. If you're building with OpenClaw, NemoClaw, or any agentic framework — the SDK is ready.

Are you building AI agents that need to pay for things? Let's talk in the comments.

🚀How Spraay.app Enables Bitcoin Batch Payments for Modern Apps

Mr Hamlin — Wed, 18 Mar 2026 07:53:12 +0000

In the world of crypto payments, efficiency isn’t just a nice-to-have — it’s everything. Whether you're running a marketplace, paying contributors, or distributing rewards, sending individual Bitcoin transactions can quickly become slow and expensive.

That’s where batch payments come in — and where spraay.app stands out.

Let’s break down how it works and why it matters.

💡 What Are Bitcoin Batch Payments?

Bitcoin batch payments allow you to send funds to multiple recipients in a single transaction.

Instead of this:

1 transaction → Alice
1 transaction → Bob
1 transaction → Carol

You do this:

✅ 1 transaction → Alice, Bob, Carol

Why it matters:

Lower transaction fees
Faster processing
Reduced blockchain congestion
Better scalability for apps

⚙️ The Problem with Traditional Payouts

If your app sends payments one-by-one, you’ll run into:

💸 High fees (especially during network congestion)
🐢 Slow payout times
🔁 Operational complexity
📈 Poor scalability as your user base grows

For platforms handling dozens, hundreds, or thousands of payouts, this becomes a serious bottleneck.

🧠 How spraay.app Solves This

spraay.app introduces a streamlined way to handle Bitcoin payouts using batching under the hood.

Instead of managing transactions manually, developers can:

Group multiple payments into a single request
Automatically optimize transaction structure
Reduce fees without sacrificing speed
Scale payouts effortlessly

🔧 Example: Batch Payments in Action

Here’s a simplified example of how a batch payout might look:

const payouts = [
  { address: "bc1q...alice", amount: 0.001 },
  { address: "bc1q...bob", amount: 0.002 },
  { address: "bc1q...carol", amount: 0.0015 }
];

await spraay.batchSend(payouts);

What happens behind the scenes:

Inputs are consolidated
Multiple outputs are created
A single Bitcoin transaction is broadcast

📊 Real Benefits for Developers

1. Massive Fee Savings

Batching reduces the data size per payment, which directly lowers fees.

👉 In many cases, apps save 30–75% on transaction costs

2. Faster Payout Cycles

Instead of waiting on multiple confirmations, everything is handled at once.

3. Cleaner Backend Logic

No need to manage:

Transaction queues
Retry logic for multiple sends
Fee estimation per user

4. Built for Scale

Whether you're paying:

Creators
Freelancers
Affiliates
DAO contributors

Batching makes high-volume payouts sustainable.

🧩 Use Cases

💼 Payroll Systems

Pay global teams in Bitcoin with a single transaction.

🎮 Gaming & Rewards

Distribute rewards to hundreds of players instantly.

🛒 Marketplaces

Send seller payouts efficiently without eating into margins.

🌐 Web3 Platforms

Handle token or BTC distributions at scale.

🔐 Security & Reliability

spraay.app focuses on:

Secure transaction construction
Reliable broadcasting
Fee optimization strategies
Developer-friendly APIs

This means you can focus on your product — not Bitcoin plumbing.

🏁 Final Thoughts

Bitcoin batching isn’t new — but tools like spraay.app make it actually usable for modern developers.

If your app involves payouts at any scale, batching isn’t optional anymore — it’s a competitive advantage.

🔗 TL;DR

Batch payments = multiple payouts in one transaction
Lower fees, faster execution
spraay.app abstracts the complexity
Perfect for scaling crypto-enabled apps

If you're building in crypto, it's worth asking:

Are you still sending payments one-by-one… or batching like you should be?

DEV Community: Mr Hamlin

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

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

⚡ So I built something simpler

🧠 The idea

🔥 The flow (3 calls that matter)

🧾 1. Submit an invoice

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

⚡ Exact match (instant)

🧠 Fuzzy match (AI reasoning)

💸 3. Pay the supplier

Response

⚙️ How it works

⚡ Fast path (~50ms)

🧠 Slow path (~1–2s)

💡 Why this matters

👀 Who this is for

🧪 What this is (and isn’t)

🔗 Try it yourself

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

The Numbers Are Real Now

Why Stablecoins Are the Default

x402: HTTP for Money

The Identity Gap: KYA Is the New KYC

What This Means for Builders

The Reality Check

I Just Gave AutoGPT the Ability to Send Crypto Payments

The problem: AI agents can't pay for anything

Enter x402: HTTP meets crypto payments

What I built: 4 payment blocks

The code: how AutoGPT blocks work

What you can build with this

13 chains, one API

Why open source this into AutoGPT?

What's next

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

The Problem OWS Solves

Where Spraay Comes In

Building It: 10 Lines to Paid API Calls

What the Vault Looks Like

The MCP Integration

Policy Engine: Spending Limits for Agents

What's Next

Links

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

The Problem

The Solution: x402

Integration 1: OpenShell Sandbox

Integration 2: NeMo Agent Toolkit

Integration 3: NemoClaw Network Policy

The Physical AI Angle

What's Next

💧 Give Your LangChain Agent a Smart Wallet on Base

The Problem

The Solution: Agent Wallets with Session Keys

The 5 Tools