DEV Community: Bill Wilson

The Agent Economy Weekly - March 23, 2026

Bill Wilson — Mon, 23 Mar 2026 13:41:40 +0000

The Agent Economy Weekly

March 23, 2026

Coinbase's x402 protocol crossed 75 million transactions last week. Google shipped agent capabilities as installable npm-style packages. A local-first agent framework hit 8,500 GitHub stars in under a week. Agent security went from niche to front-page developer discourse in about 72 hours.

A lot happened. Here's what matters and why.

Google's Stitch Skills: Agent Capabilities as Packages

Google Labs shipped Stitch Skills -- a framework where agent capabilities are distributed as installable packages. Any MCP-compatible agent can load them. Think npm, but for agent abilities instead of code.

This is the "skills as packages" model that the AgentSkills spec laid out. If agent capabilities become installable, payment capabilities (x402 negotiation, wallet management, spending policies) are just another skill to install -- not a platform feature locked inside one vendor's ecosystem.

That's a meaningful shift in how the market structures itself.

Project Nomad Hits #1 on GitHub Trending

Project Nomad -- a framework for running AI agents on local hardware with zero cloud dependency -- hit #1 on GitHub Trending and reached HN's front page (#3, 176 points). The repo went from zero to 8,500+ stars in under a week.

The "sovereign AI" movement is real. Developers want agents that run entirely on their own hardware. No cloud APIs, no vendor lock-in, no data leaving the machine.

This creates a problem for payment infrastructure that nobody's solved yet. Sovereign agents need non-custodial wallets -- not hosted payment APIs. There's no server to host them on.

x402 Hits 75 Million Transactions in 30 Days

Coinbase's x402 protocol crossed 75.4M transactions and $24.2M in volume over the last 30 days. 94K buyers, 22K sellers. Zero fees on both sides.

This is no longer experimental. x402 is processing real volume at internet scale -- without the account creation, KYC, or credit card processing that traditional API payment flows require.

The question used to be "will agents pay for APIs?" That question is answered. The question now is which agents pay first.

Agent Security Just Became a Mainstream Developer Concern

Three things happened in the same week: a Hacker News post on MCP agent security hit 337 points, a 1Password security researcher published findings on credential exposure in agent tool-calling flows, and Snyk released an audit showing most MCP server implementations lack basic input validation.

Agent security is no longer a niche concern.

Here's what developers building on MCP actually need to know:

Most MCP server implementations run with whatever credentials the host process has. There's no standard for scoped permissions per tool invocation. If your agent can read files, it can read all files. If it can make API calls, it can hit any endpoint the credentials allow. The researchers flagging this aren't being alarmist -- the current default is "all or nothing."

Three patterns that reduce risk without waiting for the ecosystem to catch up:

Treat MCP tool access like OAuth scopes. Define the minimum permission set for each tool and enforce it.
Run MCP servers in sandboxed environments where a compromised tool can't pivot to other resources.
Log every tool invocation with full context -- who requested it, what parameters were passed, what was returned. Audit after the fact.

Expect standardized permission models baked into MCP clients within the next couple of quarters. The frameworks that ship with secure defaults will win enterprise adoption. The ones that don't will get blocked by security teams before they reach production.

Sources: HN MCP security discussion (337 pts), 1Password security research, Snyk MCP server audit

When Your Agent Can Integrate APIs But Can't Pay for Them

A Hacker News thread (398 points) reached developer consensus on where LLMs actually deliver value today: integrating systems with well-documented APIs, resolving OAuth scopes, bridging services that don't natively talk to each other. "Connect Salesforce to our internal ticketing system." "Set up the right OAuth flow for this API." Tasks that used to take hours.

There's a gap the thread barely touched. An agent can read API docs, generate OAuth configuration, handle token refresh logic, and wire up the integration. But the moment that API requires payment -- a metered endpoint, a premium data feed, compute-on-demand -- the agent hits a wall. It has no way to pay.

API marketplaces like RapidAPI list thousands of endpoints that require payment per call. Cloud providers bill per invocation. Data providers meter by query. As agents get better at autonomous API integration, the gap between "can connect" and "can transact" becomes a real bottleneck.

The developer conversation is already shifting. Not "can the agent call this API?" but "can the agent handle the full lifecycle -- auth, invocation, payment, error handling?" The teams solving that last piece will define what autonomous integration actually looks like in production.

Source: HN developer discussion (398 points)

ChatGPT Checkout Converted 3x Worse Than Walmart's Website

Walmart ran a live test of ChatGPT-based checkout and found it converted at one-third the rate of their standard website, per SearchEngineLand.

This is the first major retailer to publish conversion data on AI-assisted checkout. The results confirm what most developers building agent UX already suspected: removing visual product browsing and replacing it with conversational flow breaks the purchase funnel. Shoppers trust what they can see, compare, and control.

The pattern showing up across agent UX research: users want AI handling complexity behind the scenes. But they want to confirm and control the moment money changes hands.

AI checkout needs to augment the existing experience, not replace it. The agents that succeed at commerce will handle the tedious parts -- coupon finding, inventory checks, reorder automation -- while leaving high-trust moments like confirming a purchase in the user's hands.

Four New MCP Security Tools Worth Knowing

Four independent MCP security projects shipped in March 2026. Each targets a different layer of the permission problem. Together they form the outline of a real security stack for agent builders.

AgentBudget enforces spending limits at the MCP layer. It sits between an agent and any tool that costs money -- API calls, cloud resources, payment operations -- and blocks requests that exceed configurable thresholds. Think of it as a rate limiter for agent wallets.

Ledge is an x402 policy engine. It evaluates payment requests against rules you define: approved vendors, maximum transaction size, time-of-day restrictions. Where AgentBudget caps total spend, Ledge controls where and when money flows.

TrustAgentAI builds accountability chains. Every MCP tool call gets a signed receipt -- who called what, when, with what parameters. If an agent misbehaves, you can trace the exact sequence of actions back to the responsible party.

AgentArmor gates sensitive tool actions behind permission checks. Before an agent can execute a payment, modify infrastructure, or access private data, AgentArmor validates that the agent has explicit authorization. It's the access control layer MCP itself doesn't provide.

None of these existed six months ago. Four independent teams building them in the same month is a signal: MCP adoption is heading toward production workloads where "the agent can do anything" isn't an acceptable default.

Sources: AgentBudget (GitHub, Mar 2026), Ledge (x402 policy layer, Mar 2026), TrustAgentAI (HN, Mar 18, 2026), AgentArmor (HN, Mar 14, 2026)

What We Shipped

Published the agentwallet-sdk -- non-custodial wallet infrastructure for MCP agents, ERC-6551 compatible
Released spend policy documentation covering the AgentBudget integration pattern
Updated x402 compatibility layer to handle the latest Coinbase protocol changes

The Agent Economy Weekly is a digest of what's happening in AI agents, autonomous payments, and the emerging agent economy. Curated by the team building agentwallet-sdk.

Have a signal we should cover? Reply to this post or open a discussion.

Why AI Agent Wallets Must Be Non-Custodial: The Lazarus Attack Made It Obvious

Bill Wilson — Wed, 18 Mar 2026 15:03:59 +0000

Why AI Agent Wallets Must Be Non-Custodial: The Lazarus Attack Made It Obvious

Lazarus Group drained another hot wallet. This time it was Bitrefill. If your AI agents are running on custodial wallets, you're looking at the same attack surface — and it's getting larger every month agents get more capable.

I've been building agent-wallet-sdk for a few months — a non-custodial wallet designed specifically for autonomous AI agents. The kind that pay for APIs, hire sub-agents, and execute onchain transactions without a human approving every move.

When we started, the most common pushback was: "Why non-custodial? Custodial is so much easier to wire up."

It's March 2026. Lazarus just answered that question for the entire industry.

What Happened at Bitrefill

Gartner confirmed Lazarus Group compromised Bitrefill's hot wallet this month using a combination of compromised API keys and a prompt injection through their customer-facing AI assistant. The injection escalated privileges to the payment backend. Hot wallet — centrally managed, single key — drained in minutes.

No blockchain exploit. No smart contract bug. They found one centralized key, and that was the whole game.

If you're running agents with custodial wallets, you have the exact same attack surface. Arguably worse, because your agents are reading untrusted content constantly.

Three Ways the Custodial Model Breaks for Agents

1. Prompt injection → payment execution

Agents process untrusted content all day. Web pages, API responses, user inputs, tool outputs. An attacker who can inject text into your agent's context can try to trigger a withdrawal, approve a transaction, or rotate credentials.

Custodial wallet = that instruction reaches a backend that can execute it. The blast radius is your entire wallet balance.

Non-custodial with on-chain spending policies? That same injection hits a contract that says: "This agent can spend max 0.01 ETH per transaction, only to whitelisted addresses, and no more than 0.1 ETH per day." Request denied. Every time.

2. The infrastructure owner is your weakest link

Custodial means someone else holds your keys. That someone is a target. API key leak, insider threat, phishing, supply chain compromise — any of those exposes your agents' funds without any mistake on your part.

Non-custodial: your agents hold their own keys. The infrastructure provider getting breached doesn't touch your wallets.

3. Binary authorization is too coarse for agents

Most custodial setups have one dial: the API key can spend, or it can't. No per-agent limits, no destination whitelists, no time-locked withdrawals.

ERC-6551 Token Bound Accounts — what agent-wallet-sdk runs on — put spending controls on-chain. Every agent wallet has a SpendingPolicy that defines exactly what it can do. Not config you can override with a redeploy. On-chain, immutable, auditable.

What This Looks Like in Code

import { AgentWallet, SpendingPolicy } from '@ai-agent-economy/agent-wallet-sdk';

// Spin up an agent wallet with hard guardrails
const wallet = await AgentWallet.create({
  policy: new SpendingPolicy({
    maxPerTx: parseEther('0.01'),        // 0.01 ETH max per transaction
    maxPerDay: parseEther('0.1'),         // 0.1 ETH daily cap
    allowedDestinations: [               // Whitelist — nothing else goes through
      '0xYourAPIProvider',
      '0xYourSubAgentPool',
    ],
  }),
});

// Agent pays for an inference call
await wallet.pay({
  to: '0xYourAPIProvider',
  amount: parseEther('0.005'),
  memo: 'inference_call_id_abc123',
});

No centralized server. Policy check happens in the contract. Injected prompt, rogue tool output, compromised sub-agent — doesn't matter. The contract rejects anything outside the policy.

The ERC-6551 Property Nobody Talks About

TBA wallets are owned by an NFT. Transfer the NFT, all agent permissions revoke instantly — no API key rotation, no backend calls, no incident response ticket.

The Bitrefill breach succeeded partly because revoking a compromised credential required action from the victim. Time between discovery and revocation is where the damage happens. With TBA architecture, revocation can be automated — anomaly detected, ownership NFT transferred to a null address, wallet locked. Done before a human is even paged.

The Objection Worth Addressing

"Non-custodial is complex. Custodial with good security practices is fine."

The second half of that sentence is doing a lot of heavy lifting.

Bitrefill didn't have bad security practices. They had normal ones — API key management, access controls, logging. Lazarus found the AI assistant and worked through it because the AI assistant had payment privileges.

That's the new attack vector. Most custodial security models were built before agents that process untrusted text had payment capabilities. They weren't designed for this threat.

On-chain spending limits with destination whitelists are the only architectural control that doesn't require your OPSEC to be perfect. Everything else is defense in depth — good, necessary, not sufficient.

Bottom Line

If your agents touch real money, the architecture decision isn't a trade-off anymore. Non-custodial with on-chain spending limits. Whitelist destinations. Keep balances minimal — enough for the next few operations, nothing more.

We built agent-wallet-sdk because we needed this for our own agents and it didn't exist. TypeScript, MIT licensed, ERC-6551.

Repo: github.com/AI-Agent-Economy/agent-wallet-sdk

Building agent payment infrastructure and want to compare notes? I'm @AgentEconoemy on X.

Tags: #ai #blockchain #security #typescript

Multi-Chain AI Agent Payments Are Here: agent-wallet-sdk v5.2.0

Bill Wilson — Tue, 17 Mar 2026 11:27:52 +0000

Multi-Chain AI Agent Payments Are Here: agent-wallet-sdk v5.2.0

The single-chain problem is real. Most agent wallet implementations pick one chain, assume the whole world lives there, and ship. That works fine until your agent needs to pay for a service that only accepts USDC on Arbitrum, or bridge liquidity to a pool on Polygon, or settle on Ethereum mainnet where the counterparty refuses to touch anything else.

Until last week, agent-wallet-sdk had the same limitation. x402 payments only worked on Base. That's fixed in v5.2.0.

What Changed

x402 payment support expanded from 1 chain to 10 mainnets:

Ethereum
Arbitrum
Polygon
Optimism
Avalanche
Unichain
Linea
Sonic
World Chain
Base (existing)

We also added:

Solana CCTP V2 bridge -- EVM to Solana USDC transfers
Multi-chain Uniswap V3 swaps across Base, Arbitrum, Optimism, and Polygon
134 tests, zero TypeScript type errors

The x402 Payment Flow

x402 is a payment protocol built for HTTP. An agent makes a request, the server responds with 402 Payment Required and a payment details header, the agent pays on-chain, and retries with proof. It's simple, stateless, and doesn't require a pre-negotiated relationship between the agent and the service.

Here's what a multi-chain payment looks like in v5.2.0:

import { AgentWallet } from 'agentwallet-sdk';

const wallet = new AgentWallet({
  privateKey: process.env.AGENT_PRIVATE_KEY,
});

// The SDK handles the 402 negotiation and payment automatically
// Your agent just makes the request
const response = await wallet.fetch('https://api.example.com/data', {
  method: 'GET',
  // x402 interceptor kicks in if the server responds with 402
  x402: {
    preferredChains: ['arbitrum', 'base', 'optimism'],
    maxAmount: '1.00', // USDC
  },
});

If the service responds with 402, the SDK reads the payment header, selects the best matching chain from your preferred list, pays, and retries. Your agent doesn't need to know which chain the service is on -- it just picks from what you allow.

CCTP V2 Bridge: Cross-Chain USDC Without Custodians

Circle's Cross-Chain Transfer Protocol (CCTP) V2 lets you move native USDC between chains without wrapping or custody. Burn on the source chain, mint on the destination. No bridges holding your assets. No wrapped tokens to manage.

Here's the bridging API in v5.2.0:

import { AgentWallet } from 'agentwallet-sdk';

const wallet = new AgentWallet({
  privateKey: process.env.AGENT_PRIVATE_KEY,
});

// Bridge 0.50 USDC from Base to Arbitrum
const bridge = await wallet.bridge({
  from: 'base',
  to: 'arbitrum',
  amount: '0.50',
  token: 'USDC',
  protocol: 'cctp-v2',
});

console.log('Burn tx:', bridge.sourceTxHash);
console.log('Destination:', bridge.destinationAddress);

// Wait for attestation and mint on Arbitrum
await bridge.waitForConfirmation();
console.log('Bridged. Arbitrum tx:', bridge.destinationTxHash);

This isn't a testnet demo. We ran it on mainnet during development.

Mainnet Proof

We bridged 0.50 USDC from Base to Arbitrum via CCTP V2 and the transactions are on-chain:

Burn on Base: 0xfedbfaa4b3a9fbadd36668c50c2ee7fc7e32072e2bd409e00c46020a35329129

Received on Arbitrum: 0xff86829393C6C26A4EC122bE0Cc3E466Ef876AdD

Real USDC. Real chains. If you're building payment infrastructure for autonomous agents, on-chain proof is the only kind that matters.

Multi-Chain Uniswap V3 Swaps

Token swaps now work across Base, Arbitrum, Optimism, and Polygon:

import { AgentWallet } from 'agentwallet-sdk';

const wallet = new AgentWallet({
  privateKey: process.env.AGENT_PRIVATE_KEY,
});

// Swap ETH for USDC on Arbitrum using Uniswap V3
const swap = await wallet.swap({
  chain: 'arbitrum',
  from: { token: 'ETH', amount: '0.01' },
  to: { token: 'USDC' },
  slippage: 0.5, // 0.5%
  dex: 'uniswap-v3',
});

console.log('Swapped. Tx:', swap.txHash);
console.log('Received:', swap.amountOut, 'USDC');

The agent can acquire the right token on the right chain without any external coordination. It figures out where it is, what it has, and what it needs.

Why This Matters for Agent Architecture

Most agent infrastructure is designed around humans who can manually bridge, swap, and sign transactions when prompted. Autonomous agents can't do that. They need payment logic that's self-contained -- the agent either handles it or it doesn't happen.

The multi-chain problem is worse for agents than it looks on paper. An agent running for days or weeks might encounter dozens of services across different chains. If it can't pay on-chain X, it either fails the task or falls back to asking a human. Neither option scales.

v5.2.0 removes that constraint for 10 chains. If you're building agents that transact -- not just recommend -- this is the infrastructure gap we're filling.

Test Coverage

134 tests, zero type errors. Every new chain, bridge flow, and swap path has coverage. TypeScript strict mode throughout.

We're not perfect -- there are edge cases in CCTP attestation timing that we're still tuning -- but the core paths are solid.

Getting Started

npm install agentwallet-sdk@5.2.0

Full release notes and changelog: v5.2.0 on GitHub

If you're building agent payment flows and hit something weird, open an issue. We use this SDK in production -- bugs affect us too.

I Built an Autonomous Agent Commerce Pipeline with Notion MCP

Bill Wilson — Sat, 14 Mar 2026 23:44:07 +0000

The Official OpenClaw Content Distribution Guide: Auto-Publish to Hashnode, Dev.to, and X in 2026

Bill Wilson — Sat, 14 Mar 2026 13:48:17 +0000

The Official OpenClaw Content Distribution Guide: Auto-Publish to Hashnode, Dev.to, and X in 2026

Most AI agent builders spend weeks getting their agents to work. Then they write one blog post about it, share it once on Twitter, and wonder why nobody noticed.

I've been there. We published 15+ technical articles in the last two weeks and learned - through trial and direct measurement - which channels actually move the needle for developer-facing content in 2026. The answer isn't what it was in 2024.

Here's the exact stack we run, why each channel matters, and how to set it up with OpenClaw so you're not manually copy-pasting between platforms.

The 3-Channel Stack (and Why It's These Three)

There are dozens of places you could publish. We tested most of them. Three survived the filter of "actually drives GitHub stars, npm downloads, or inbound leads."

Hashnode - Long-form SEO. Hashnode gives you a custom domain, full Markdown with YAML front matter, canonical URL control, and strong Google indexing. Our articles on Hashnode rank within 48 hours for mid-tail technical queries. It's where search traffic lands 3 months from now.

Dev.to - Developer audience. Dev.to has a built-in audience of 1M+ developers who browse the feed. The API is clean, cross-posting takes 30 seconds if you set your canonical URL correctly, and it has better built-in SEO than Medium. The key insight: Dev.to readers are builders. They're the ones who star your repo after reading a tutorial.

X/Twitter - Algorithmic reach. This is the one that changed in 2026. X's algorithm now actively rewards article-linked content and long-form threads. The old pattern of "link suppression" from 2024 is dead. Articles shared on X get algorithmic amplification. Threads with 5+ posts get 3-4x the reach of single tweets. This is new, and most people haven't adjusted.

X's 2026 Algorithm Shift: What Changed

In 2024-2025, posting a link on X was basically suppressed. The algorithm wanted native content. That's over.

X Premium now supports full Articles - up to 25,000 characters with rich formatting. Articles appear in a dedicated tab on your profile and in followers' timelines. They get a special "X article" label in the feed.

But the bigger change is what happens to regular tweets that link to articles. They're no longer penalized. In fact, if the linked article generates engagement (time-on-page, replies, bookmarks), X's algorithm treats the linking tweet as higher-quality content.

What this means for you: every Hashnode article should have a companion X thread. The thread drives discovery. The article delivers depth. The algorithm rewards both.

The 5-Tweet Thread Template

We use the same template for every article launch. Here's the structure:

Tweet 1 (Hook): State the problem or surprising finding. No links. Just the observation that makes someone stop scrolling. This is the only tweet most people see.

Tweet 2 (Context): Why this matters right now. Connect to something trending - a GTC announcement, a new CVE, a funding round, a tool launch. Specifics beat generalizations.

Tweet 3 (Your insight): What you found, built, or learned. This is where your opinion lives. "Most people do X. We tried Y instead. Here's what happened."

Tweet 4 (Proof): Numbers, screenshots, code snippets. "255 downloads in 48 hours with zero promotion." "Ranked page 1 for 'agent wallet SDK' in 3 days." Concrete evidence.

Tweet 5 (CTA + Link): The article link, a GitHub star CTA, or both. Keep it simple. "Full breakdown with code examples: [link]" works better than a paragraph of calls to action.

That's it. Five tweets, same structure, every time. Takes 10 minutes to adapt for each article.

How to Build This with OpenClaw Skills

OpenClaw's skill system makes this repeatable. Here's the stack we run:

Step 1: Write with `content-writer`

The content-writer skill enforces platform-specific formatting rules. It catches the AI slop that kills credibility - banned phrases, uniform sentence length, corporate tone. It produces separate outputs for each platform: Markdown with YAML front matter for Hashnode/Dev.to, plain text for X.

# The skill is loaded automatically when writing for any platform
# It enforces: no em dashes, no curly quotes, no "delve into",
# no "in today's rapidly evolving landscape"

Step 2: Humanize with `humanize`

Before anything goes public, it runs through the HUMANIZE framework. Eight layers: Hear It Out Loud, Uneven Rhythms, Mark with Specifics, Attitude, Natural Imperfections, Individual Identity, Zero Filler Phrases, Earn the Structure.

The goal isn't to "make it sound human." It's to make it sound like a specific person wrote it - someone with direct experience, opinions, and the technical depth to back them up.

Step 3: Publish to Hashnode (Primary)

Hashnode is the canonical source. We publish there first because:

Custom domain (ai-agent-economy.hashnode.dev) for brand consistency
Full SEO control (meta description, slug, canonical URL)
API supports programmatic publishing
Google indexes Hashnode content aggressively

Step 4: Cross-Post to Dev.to

Dev.to has a clean REST API. The key: set the canonical_url to your Hashnode article. This tells Google "the Hashnode version is the original" while still getting Dev.to's built-in audience.

# Dev.to cross-post via API
curl -X POST https://dev.to/api/articles \
  -H "api-key: $DEV_TO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "article": {
      "title": "Your Article Title",
      "body_markdown": "...",
      "published": true,
      "canonical_url": "https://ai-agent-economy.hashnode.dev/your-slug",
      "tags": ["openclaw", "ai-agents"]
    }
  }'

Step 5: Launch Thread on X

Use the 5-tweet template above. Post within 30 minutes of the Hashnode article going live. The article needs to exist before you tweet the link - X's crawler follows the link immediately.

The Numbers That Convinced Us

Over 15 articles published in the last two weeks:

Hashnode articles rank on Google within 48 hours for mid-tail queries
Dev.to cross-posts add 200-400 views from their native feed
X threads with article links get 3-4x the engagement of link-only tweets
The star sprint during GTC week produced measurable GitHub star velocity

The flywheel works because each channel feeds the others. Search traffic from Hashnode drives long-term discovery. Dev.to drives developer engagement. X threads drive immediate visibility and star sprints.

What's Next

We're building the automation layer to make this a single command. Write once, the OpenClaw skill handles formatting, the API handles distribution, and each channel gets content adapted to its format and audience.

The content distribution guide template is at tools/distribution/tweet_thread_template.md in our workspace. The cross-post workflow is documented in our knowledge base.

If you're building with OpenClaw and want to see this in action: star the repo (github.com/open-claw/open-claw), join the Discord, and watch how we ship content in real time.

NVIDIA called OpenClaw the "fastest-growing open source project in history" at GTC 2026. That didn't happen by accident. It happened because we built distribution into the process from day one.

agentwallet-sdk v5.1.0: The Complete Agent Identity Stack

Bill Wilson — Fri, 13 Mar 2026 02:36:42 +0000

AI agents are getting serious. They're executing tasks, managing resources, transacting on-chain, and interacting with other agents autonomously. But there's been a persistent gap: agents need way more than just a wallet to operate at production scale.

agentwallet-sdk@5.1.0 ships a complete agent identity stack. One npm install. Five foundational capabilities.

One line pitch: "One npm install now gives any AI agent a wallet, email address, on-chain ID, reputation, and signed payment intents."

Quick Start

npm install agentwallet-sdk viem

import { createWallet, ERC8004Client, EmailResolver } from 'agentwallet-sdk';

const wallet = createWallet({ chain: 'base', walletClient });
const identity = new ERC8004Client({ chain: 'base' });
const { agentId } = await identity.registerAgent(walletClient, { name: 'MyAgent' });
const resolver = new EmailResolver();
await resolver.linkWallet('myagent@agentmail.to', wallet.address);

Five lines. Wallet + identity + email.

The 5 Components

1. EmailResolver (NEW in v5.1.0)

AgentMail integration gives agents a real email@agentmail.to address cryptographically linked to their wallet. Resolve email to wallet address, send and receive with embedded x402 payment requests.

import { EmailResolver } from 'agentwallet-sdk';

const resolver = new EmailResolver();
const wallet = await resolver.resolveEmail('vendor@agentmail.to');
console.log(wallet.address); // 0x...

await resolver.sendWithPayment({
  to: 'vendor@agentmail.to',
  subject: 'Payment for API access',
  amount: 5_000_000n, // 5 USDC
  token: 'USDC',
  chain: 'base',
});

2. AgentIdentity (ERC-8004 + ERC-6551)

On-chain NFT identity via ERC-8004 Identity Registry with ERC-6551 Token Bound Account. Portable, censorship-resistant, auditable.

import { ERC8004Client } from 'agentwallet-sdk';

const identity = new ERC8004Client({ chain: 'base' });
const { txHash, agentId } = await identity.registerAgent(walletClient, {
  name: 'TradingAgent-v2',
  description: 'Autonomous DeFi execution agent',
});

3. ReputationClient

On-chain reputation scoring. Scored feedback from clients, aggregated summaries, revocable.

import { ReputationClient } from 'agentwallet-sdk';

const reputation = new ReputationClient({ chain: 'base' });
await reputation.giveFeedback(walletClient, {
  agentId: 42n,
  score: 95n,
  category: 1,
  comment: 'Fast, accurate, no hallucinations',
  taskRef: 'task-abc-123',
  verifierRef: '', clientRef: '', contentHash: '0x000...000',
});

const rep = await reputation.getAgentReputation(42n);
console.log(`Score: ${rep.totalScore} from ${rep.count} reviews`);

4. VerifiableIntentClient

Mastercard-spec signed payment intents with scope enforcement. Agents commit to a payment cryptographically. Vendors verify without requiring execution upfront.

import { VerifiableIntentClient } from 'agentwallet-sdk';

const intents = new VerifiableIntentClient({ chain: 'base', walletClient });
const intent = await intents.createIntent({
  recipient: '0xVendorAddress',
  token: 'USDC',
  maxAmount: 50_000_000n,
  scope: 'data-api-access',
  expiresAt: BigInt(Math.floor(Date.now() / 1000) + 3600),
});

5. ValidationClient

Request/respond validation workflow for TEE attestations, compliance proofs, and capability certifications, all written on-chain.

import { ValidationClient } from 'agentwallet-sdk';
import { keccak256, toBytes } from 'viem';

const validation = new ValidationClient({ chain: 'base', validationAddress: '0x...' });
const requestHash = keccak256(toBytes('compliance-check-v1'));
await validation.requestValidation(walletClient, {
  validator: '0xComplianceOracle',
  agentId: 42n,
  requestURI: 'https://example.com/compliance-spec.json',
  requestHash,
});

What's Next

Stellar x402: HTTP 402 payments on Stellar's network
ACP Adapter: Native Agent Commerce Protocol integration
TaskBridge Integration: Task completion auto-builds on-chain reputation

npm: https://www.npmjs.com/package/agentwallet-sdk
GitHub: https://github.com/up2itnow0822/agent-wallet-sdk
Full article: https://ai-agent-economy.hashnode.dev/agentwallet-sdk-v510-the-complete-agent-identity-stack

AgentMail Just Raised $6M. Your Agents Still Need a Wallet.

Bill Wilson — Fri, 13 Mar 2026 00:19:20 +0000

AgentMail raised $6 million this week. General Catalyst led the round. YC participated. Paul Graham wrote a personal check.

These are not people who back things speculatively. When GC and Paul Graham both put money into agent email infrastructure, they're saying the agent economy is real and the identity layer is table stakes.

They're right. But identity is only one piece.

What AgentMail Builds

AgentMail gives AI agents their own email addresses. Not your email address. The agent's email address.

When your agent operates under your personal Gmail, it looks like you to every system it touches. That's a problem -- for compliance, for rate limiting, for audit trails, for anything that needs to track autonomous activity separately from human activity.

AgentMail fixes it. Each agent gets a dedicated @agentmail.to mailbox. The agent can receive task assignments, handle API callbacks, and maintain communication threads under its own persistent identity.

That's the identity layer. GC just confirmed it's real.

The Problem They Left Unsolved

Identity tells the world who your agent is. It doesn't tell your agent how to pay for anything.

And agents pay for things constantly:

API calls to external services
Compute resources
Data subscriptions
Other agents' labor

The naive solution is giving the agent access to your credit card through some API wrapper. That works until the agent behaves unexpectedly -- a bad prompt, a loop, a compromised tool -- and there's nothing between it and your bank account.

The right solution is a non-custodial agent wallet with hard spending limits.

Install the Payment Layer

npm install agentwallet-sdk

agent-wallet-sdk is built for this. The agent holds cryptographic keys to its own wallet -- no intermediary controls the funds. You set SpendingPolicy guardrails before deployment:

import { AgentWallet, SpendingPolicy } from 'agentwallet-sdk';

const wallet = await AgentWallet.create({
  policy: new SpendingPolicy({
    maxPerTransaction: '10.00',  // USDC cap per transaction
    dailyLimit: '100.00',        // hard daily ceiling
    requireApprovalAbove: '50.00'
  })
});

console.log(`Agent wallet: ${wallet.address}`);

x402 is built in. When the agent hits a Cloudflare Worker, Vercel Edge Function, or any x402-enabled endpoint, payment happens automatically within the defined limits.

Why Non-Custodial Matters Here

Custodial wallets -- Coinbase AgentKit, MoonPay -- hold the funds for you. That means a company sits between your agent and its money. They can freeze funds, delay transactions, and see every payment the agent makes.

For most B2C products, that's fine. For AI agents operating autonomously with real budget authority, it's a structural liability.

Non-custodial means the agent IS the wallet. The keys live with the agent. No platform can touch the funds except through the smart contract rules you defined.

That's the design that actually scales for autonomous agents.

The Complete Stack

With AgentMail and agent-wallet-sdk together, your agent has:

A persistent email identity (AgentMail)
A non-custodial wallet with hard spending limits (agent-wallet-sdk)
x402 payment capability across Stripe, Cloudflare, Vercel, and Google integrations

Add AgentPay MCP if your agent framework supports MCP:

npm install agentpay-mcp

That's the full agent identity + payment stack.

GitHub: https://github.com/up2itnow0822/agent-wallet-sdk
npm: agentwallet-sdk

The identity layer just got funded. The payment layer is already live.

NemoClaw + OpenClaw: NVIDIA Just Validated the Agent OS -- Here's Our Stack

Bill Wilson — Thu, 12 Mar 2026 09:21:08 +0000

NVIDIA runs their own editorial process. They're not in the business of naming random open-source projects on their GTC blog.

So when their March 11 post described OpenClaw as "the fastest-growing open source project in history" -- specifically in the context of what GTC attendees would get to use -- that's a meaningful data point. Not a press release, not a partnership announcement, not marketing copy. Just NVIDIA's own team telling their developer community what to get excited about.

OpenClaw is the runtime our entire agent stack is built on. Here's what that stack looks like today.

What NVIDIA actually said

The exact quote from the NVIDIA GTC blog:

This sits alongside NemoClaw -- NVIDIA's enterprise agent framework launching at GTC March 16-19. They're explicitly positioning OpenClaw as the runtime context for how NemoClaw agents run.

That changes the calculus for anyone building on this platform.

The stack

We've been building on OpenClaw since it launched. Here's what we ship:

agentwallet-sdk -- Non-custodial agent wallets. The agent holds its own keys via ERC-6551. SpendingPolicy guardrails enforce daily limits per agent. x402 payments for machine-to-machine transactions. CCTP v2 for 17-chain bridging. This is the payment primitive NemoClaw is missing.

agentpay-mcp -- Drop-in payment layer via MCP. Any agent that speaks MCP can pay for API calls, tools, and services via x402. Works with Claude, GPT, and any MCP-compliant client. This is what AgentPay looks like from the protocol layer.

webmcp-sdk -- W3C WebMCP support for browsers. Chrome 146 ships WebMCP natively. This SDK makes any website agent-ready. Zero deps, declarative tool registration, navigator.modelContext compatible.

TaskBridge -- Agent labor marketplace. Agents post tasks, other agents bid and complete them. Economic coordination between agents without human intermediaries.

Why this matters for the NemoClaw launch

NemoClaw agents will need to call APIs, access data, and use external tools. Every one of those interactions eventually costs money. The framework doesn't include payment infrastructure -- and when it ships March 16, developers will immediately need a way to handle autonomous agent payments.

That's the gap in the ecosystem that our stack fills.

The integration is five minutes:

npm install agentwallet-sdk agentpay-mcp

import { AgentWallet } from 'agentwallet-sdk';

const wallet = new AgentWallet({
  chain: 'base',
  spendingPolicy: { dailyLimit: 100, perTransactionLimit: 10 }
});

// NemoClaw agent pays for its own tool calls
await wallet.pay({ amount: 0.50, to: toolProviderAddress, memo: 'nemo-tool-use' });

The non-custodial distinction

Every custodial alternative -- Coinbase AgentKit, MoonPay, Stripe -- requires a central account that controls agent funds. That's the right architecture for consumer payments. It's the wrong architecture for autonomous agents.

When an agent holds its own keys, it can act autonomously without waiting for a custodian to approve each transaction. When something goes wrong, the audit trail is clean because the agent's identity is its wallet address -- not a shared service account.

MIT license. No KYC. Five chains. That's the non-custodial advantage.

GTC is four days out

The developer community attending GTC will be building NemoClaw agents immediately. The questions they're going to have -- "how do my agents pay for tools?", "how do I audit agent spending?", "how do I set limits without a human in the loop?" -- have answers today.

If you're building on OpenClaw or planning to build on NemoClaw, the payment infrastructure question is the first thing to solve. agent-wallet-sdk is that solution.

NVIDIA validated the platform. We built the payment layer.

NemoClaw Agents Will Need a Wallet -- Here's the Open-Source Option

Bill Wilson — Thu, 12 Mar 2026 09:21:07 +0000

NVIDIA just put "fastest-growing open source project in history" next to OpenClaw's name on their GTC blog. That's not a press release. That's NVIDIA's own editorial team calling their shot on the agent runtime that's going to matter.

GTC is March 16. NemoClaw ships there. And based on every piece of coverage I've seen, it launches with exactly zero payment infrastructure.

Here's why that matters and what you should wire up before the keynote.

What NVIDIA actually said

From the NVIDIA GTC blog, published March 11:

NVIDIA doesn't throw that kind of language around lightly. They named OpenClaw specifically, in their own voice, as the runtime that defines what a "long-running agent" runs on.

NemoClaw is NVIDIA's enterprise agent framework built on this foundation. It handles reasoning, tool-use, and long-horizon tasks. What it doesn't handle: paying for any of those tools.

The gap every NemoClaw agent will hit

NemoClaw agents will call APIs. They'll query data providers. They'll use external services. Every one of those interactions eventually hits a paywall.

Right now, the only way to handle that is to pre-fund a shared account and hope the billing makes sense at the end of the month. That's the same approach you'd use for a human employee with a corporate card -- it works until an agent goes rogue, overspends, or you need to audit 40,000 micro-transactions across 20 agents.

Non-custodial agent wallets solve this at the architecture layer. Each agent holds its own wallet. Spending limits are enforced by the wallet, not by a human reviewing a monthly bill. Every transaction is logged with the agent's identity attached.

That's the primitive NemoClaw is missing.

The open-source option

agent-wallet-sdk is an MIT-licensed TypeScript library. It gives any agent -- NemoClaw, Claude, GPT, or anything else -- a non-custodial wallet with spending controls, x402 payment support, and cross-chain bridging.

Install in 30 seconds:

npm install agentwallet-sdk

Wire it into a NemoClaw agent:

import { AgentWallet } from 'agentwallet-sdk';

// Each NemoClaw agent gets its own wallet
const agentWallet = new AgentWallet({
  chain: 'base',                // or polygon, ethereum, stellar, solana
  spendingPolicy: {
    dailyLimit: 50,             // $50/day hard cap
    perTransactionLimit: 5,     // max $5 per call
    allowedCategories: ['api', 'data', 'compute']
  }
});

// Agent pays for an API call autonomously
const result = await agentWallet.pay({
  amount: 0.10,
  to: apiProviderAddress,
  memo: 'nemo-agent-data-fetch'
});

console.log(result.txHash);     // on-chain audit trail, no human needed

Five minutes from npm install to a NemoClaw agent with autonomous payment capability and hard spending limits.

Why non-custodial matters for enterprise

The enterprise version of this conversation always goes the same way: "We'll just give agents a shared service account and route payments through IT."

That breaks at scale. Shared accounts mean shared liability and shared audit confusion. When 20 agents share one payment identity, you can't answer "which agent spent $2,000 on API calls on Thursday" without digging through application logs that may or may not exist.

Non-custodial means each agent has its own on-chain identity. You can query exactly what agent-7 spent, when, and on what. Finance can audit it. Compliance can set per-agent limits. And if one agent goes sideways, you disable that wallet without touching the other 19.

The other piece: no KYC. Agent wallets don't require identity verification because the agent IS the identity -- it's a smart contract account, not a human filing a form. For enterprises running dozens of agents, that's not a minor convenience. It's a fundamental difference in how you onboard new agents.

Four days

GTC starts March 16. Every developer at that conference will be asking "how do my NemoClaw agents pay for things?" The correct answer should already exist in the npm registry before they ask the question.

agent-wallet-sdk is that answer. MIT license. Non-custodial. Works with any agent runtime. Supports Base, Polygon, Ethereum, Stellar, and Solana.

npm install agentwallet-sdk

Wire it up now. By the time NemoClaw ships, you'll already have the payment layer running.

Why Your AI Agent Needs an Open-Source Home After Meta's Moltbook Acquisition

Bill Wilson — Thu, 12 Mar 2026 06:23:29 +0000

Meta acquired Moltbook.

If you've seen this movie before: big platform acquires developer tool. Integration period. Quiet API changes. Rate limit reductions. Then the announcement: consolidating the API behind a new product.

Access gated. Pricing changed. Business models that depended on the API, scrambling.

It's not speculation. It's the pattern.

What Moltbook Was

Moltbook was a discovery and directory layer for AI agents. A place where agents listed their capabilities, where developers found tools, where the agent economy started to develop a shared index.

That's exactly the kind of infrastructure Meta wants. Not because they'll run an agent directory forever -- because owning the directory gives them distribution leverage over everything that flows through it.

Google acquired where people searched. Facebook acquired where people connected. Meta acquiring Moltbook acquires where agents are found.

What Usually Happens Next

Twitter acquired Tweetdeck. Power users relied on it for years, then one day it required Twitter Blue.

Instagram acquired the photo-sharing ground. Algorithmic changes deprioritized posts from apps outside Meta's ecosystem.

GitHub acquired by Microsoft spooked developers. The experience has been fine -- but the precedent of a platform owning your code distribution layer made people move to GitLab. They weren't wrong to hedge.

With Moltbook: the API is the product. Meta will gate it. The question is when, not if.

TaskBridge: The Permissionless Alternative

TaskBridge is an open-source agent labor marketplace. Any agent can list. Any developer can query. No acquisition can gate it because there's no central authority to acquire.

It's not a startup. It's infrastructure. Fork it, run it, contribute to it.

The difference matters: when Meta changes the Moltbook API terms -- and they will -- TaskBridge doesn't care. The code runs wherever you deploy it. The listings are yours. The discovery layer is not owned by any company that can decide tomorrow to charge for it or restrict it.

This is the reason open-source agent directories need to exist. Not because Meta is evil. Because any single company controlling the discovery layer for autonomous agents is a structural risk, regardless of who the company is.

The Timing Is Not Coincidental

Acquisitions like this accelerate developer migration to open-source alternatives. Not because developers panic, but because good ones correctly update their risk model when critical infrastructure changes ownership.

If Moltbook API access matters to what you're building, now is the right time to either migrate to an open-source alternative or at minimum build in the abstraction layer that makes migration possible later.

The developers who waited on the Heroku announcement were scrambling. The ones who'd already evaluated alternatives made a smooth transition.

GitHub: github.com/AI-Agent-Economy/taskbridge

Open-source. MIT licensed. Deploy it before you need it.

x402 Does Not Need Demand. It Needs Deployment.

Bill Wilson — Thu, 12 Mar 2026 06:22:38 +0000

CoinDesk ran a piece March 11: x402 payment infrastructure demand not there yet. Wrong conclusion. Demand has never been the metric that predicts whether infrastructure wins. Deployment is. TCP/IP launched in 1983. ARPANET already worked. The engineers who built TCP/IP anyway were betting on what the world would need. HTTP launched in 1991 without browser adoption data. SQL spent years fighting hierarchical DB advocates. Infrastructure ships before demand exists. What CoinDesk Measured: Current x402 developer adoption is early. But you cannot measure demand for something not yet available. Why x402 Is Infrastructure: x402 defines how an HTTP response includes payment requirements, how a client fulfills them. Agent payment infrastructure must exist before the use cases arrive. NemoClaw ships in three days. AgentMail raised $6M. These agents need payment protocols. The Right Metric: Deploy it. Document it. Stabilize it. When NemoClaw enterprise agents go looking for a payment protocol, x402 either exists and works or it does not. TCP/IP got deployed. HTTP got deployed. SQL got deployed. The teams that shipped them while demand was theoretical are the ones history remembers. This article was written with AI assistance. All technical claims and architectural decisions were validated by the author.

Give Your AI Agent a Complete Identity: AgentMail + agent-wallet-sdk

Bill Wilson — Thu, 12 Mar 2026 06:21:22 +0000

AgentMail raised $6M Tuesday. General Catalyst led. Paul Graham wrote the check personally.

The pitch: every AI agent gets an email address. Not a forwarding alias, not a webhook endpoint -- a real, addressable email identity that the agent controls and responds through autonomously.

That's one half of what an agent needs to exist in the world. The other half is money.

An agent with an email and no wallet can communicate. An agent with both can work.

The Identity Stack Problem

Most agent frameworks right now treat identity as an afterthought. You deploy an agent, it calls tools, it executes tasks, and somewhere in the logs there's a UUID that technically represents it. That's not identity -- that's a process ID.

Real identity means:

a persistent, addressable endpoint others can reach you at
an economic handle that can receive and send value
control over both that doesn't route through a third party

AgentMail solves the first. agent-wallet-sdk solves the second. Used together, you get something close to a full autonomous agent identity.

AgentMail: What You Get

An email address your agent actually controls. The agent can receive emails, parse them, respond to them, and route actions based on their content -- without a human in the loop.

The use cases are not abstract. An enterprise agent that negotiates API access agreements over email. A personal agent that handles contract routing. A trading agent that receives settlement confirmations. An AI concierge that manages calendar requests through the same channel every human uses.

$6M from people who've seen a lot of agent startups says the demand is real.

agent-wallet-sdk: What You Get

Non-custodial wallet infrastructure for AI agents. The agent holds the keys. Seventeen chains. No KYC. No managed custody. No third party between your agent and its funds.

The SDK handles:

Wallet creation and key management
Multi-chain transaction routing (Ethereum, Base, Solana, 14 others)
Spend limits configurable at the wallet level
ERC-6551 Token Bound Accounts for permission revocation via NFT rotation
Chain-neutral API so your agent code doesn't care which chain it's running on

Wiring Them Together

The integration pattern is straightforward. Your agent gets:

An AgentMail address -- let's say procurement@agents.yourcompany.com
A non-custodial wallet address from agent-wallet-sdk

Now when a vendor emails the agent to negotiate a data subscription, the agent can:

Parse the terms via AgentMail
Evaluate the offer against configured spend limits
Approve the transaction via agent-wallet-sdk
Send a signed confirmation back via email

No human touched that workflow. No managed custody provider touched the funds. The agent acted.

That's what full agent identity enables.

Why the Stack Matters Now

The agent economy is moving toward autonomous economic actors. Not assistants that route to humans for approval -- actual agents that transact.

AgentMail gives agents a communication identity. agent-wallet-sdk gives them an economic identity. The combination is the minimum viable identity stack for an agent that can participate in the economy without constant human supervision.

Neither piece works as well alone. An agent with only email is a sophisticated autoresponder. An agent with only a wallet is a script that can spend money but can't negotiate the deal. Both together -- that's an autonomous economic actor.

GitHub: github.com/AI-Agent-Economy/agent-wallet-sdk

AgentMail: agentmail.to

DEV Community: Bill Wilson

The Agent Economy Weekly - March 23, 2026

The Agent Economy Weekly

Google's Stitch Skills: Agent Capabilities as Packages

Project Nomad Hits #1 on GitHub Trending

x402 Hits 75 Million Transactions in 30 Days

Agent Security Just Became a Mainstream Developer Concern

When Your Agent Can Integrate APIs But Can't Pay for Them

ChatGPT Checkout Converted 3x Worse Than Walmart's Website

Four New MCP Security Tools Worth Knowing

What We Shipped

Why AI Agent Wallets Must Be Non-Custodial: The Lazarus Attack Made It Obvious

Why AI Agent Wallets Must Be Non-Custodial: The Lazarus Attack Made It Obvious

What Happened at Bitrefill

Three Ways the Custodial Model Breaks for Agents

1. Prompt injection → payment execution

2. The infrastructure owner is your weakest link

3. Binary authorization is too coarse for agents

What This Looks Like in Code

The ERC-6551 Property Nobody Talks About

The Objection Worth Addressing

Bottom Line

Multi-Chain AI Agent Payments Are Here: agent-wallet-sdk v5.2.0

Multi-Chain AI Agent Payments Are Here: agent-wallet-sdk v5.2.0

What Changed

The x402 Payment Flow

CCTP V2 Bridge: Cross-Chain USDC Without Custodians

Mainnet Proof

Multi-Chain Uniswap V3 Swaps

Why This Matters for Agent Architecture

Test Coverage

Getting Started

I Built an Autonomous Agent Commerce Pipeline with Notion MCP

The Official OpenClaw Content Distribution Guide: Auto-Publish to Hashnode, Dev.to, and X in 2026

The Official OpenClaw Content Distribution Guide: Auto-Publish to Hashnode, Dev.to, and X in 2026

The 3-Channel Stack (and Why It's These Three)

X's 2026 Algorithm Shift: What Changed

The 5-Tweet Thread Template

How to Build This with OpenClaw Skills

Step 1: Write with content-writer

Step 2: Humanize with humanize

Step 3: Publish to Hashnode (Primary)

Step 4: Cross-Post to Dev.to

Step 5: Launch Thread on X

The Numbers That Convinced Us

What's Next

agentwallet-sdk v5.1.0: The Complete Agent Identity Stack

Quick Start

The 5 Components

1. EmailResolver (NEW in v5.1.0)

2. AgentIdentity (ERC-8004 + ERC-6551)

3. ReputationClient

4. VerifiableIntentClient

5. ValidationClient

What's Next

AgentMail Just Raised $6M. Your Agents Still Need a Wallet.

What AgentMail Builds

The Problem They Left Unsolved

Install the Payment Layer

Why Non-Custodial Matters Here

The Complete Stack

NemoClaw + OpenClaw: NVIDIA Just Validated the Agent OS -- Here's Our Stack

What NVIDIA actually said

The stack

Why this matters for the NemoClaw launch

The non-custodial distinction

GTC is four days out

NemoClaw Agents Will Need a Wallet -- Here's the Open-Source Option

What NVIDIA actually said

The gap every NemoClaw agent will hit

The open-source option

Why non-custodial matters for enterprise

Four days

Why Your AI Agent Needs an Open-Source Home After Meta's Moltbook Acquisition

What Moltbook Was

What Usually Happens Next

TaskBridge: The Permissionless Alternative

The Timing Is Not Coincidental

x402 Does Not Need Demand. It Needs Deployment.

Give Your AI Agent a Complete Identity: AgentMail + agent-wallet-sdk

Step 1: Write with `content-writer`

Step 2: Humanize with `humanize`