Trustless AI Commerce: How ERC-8004 Reputation Enables Autonomous Economic Agents

2026-09-17

Trustless AI Commerce: How ERC-8004 Reputation Enables Autonomous Economic Agents

AI agents will need to pay for compute, data, and API calls — and right now, the infrastructure to let them do that autonomously barely exists. We talk endlessly about agents that can reason, plan, and act, but the moment one of those agents needs to spend money, we fall back to humans holding the keys. That gap between "autonomous agent" and "agent that can actually participate in economic activity" is exactly what trustless wallet infrastructure is built to close.

The Problem Nobody Talks About at the AGI Conference

Here's a scenario that plays out constantly in production AI systems today: an agent needs to call a paid API, execute a trade, or pay for inference compute. So what happens? A human pre-loads a balance into some custodied account, the agent draws from it, and a human periodically reviews the spending.

That's not autonomous economic activity. That's a very complicated expense account.

The deeper issue is trust — specifically, the lack of a mechanism for counterparties to verify that an agent is what it claims to be, that it will honor its obligations, and that it has the authority to spend the funds it's trying to spend. In human commerce, we have credit scores, corporate registration, banking relationships, and legal liability. For AI agents, we have... vibes.

ERC-8004 is an attempt to change that. It's a standard for onchain agent reputation and validation — a way to assign verifiable identity and track record to an autonomous agent so that other parties in a transaction can make informed decisions about whether to transact with it. And WAIaaS, an open-source self-hosted Wallet-as-a-Service for AI agents, ships with ERC-8004 support built in.

This isn't vaporware. It exists today. Let's talk about what that actually means.

What ERC-8004 Actually Does

The concept is straightforward even if the implementation is not. An AI agent — or rather, the wallet infrastructure backing that agent — registers an onchain identity. Over time, as the agent completes transactions, fulfills obligations, and operates within defined parameters, that identity accumulates a reputation score. Other parties can query that reputation before deciding whether to transact.

Think of it like a credit score for machines, except it's transparent, onchain, and queryable by any counterparty without a centralized bureau acting as gatekeeper.

WAIaaS exposes this through two MCP tools that Claude and other AI frameworks can call directly:

The policy engine also has a corresponding REPUTATION_THRESHOLD policy type. This means you can configure a wallet so that it will only transact with counterparties whose onchain reputation meets a minimum bar. Default-deny applies here too: if the counterparty doesn't have a verifiable reputation, the transaction doesn't go through.

This is the foundation of trustless AI commerce — not a pinky promise that an agent is well-behaved, but a cryptographically verifiable track record that any party in the system can inspect.

The Infrastructure Layer: Wallets for Autonomous Agents

Before we get further into reputation, it's worth being precise about what "autonomous wallet infrastructure" means in practice, because it's doing a lot of work.

WAIaaS is a 15-package monorepo that you self-host. The core component is a daemon that exposes 39 REST API routes and communicates with AI agents through 45 MCP tools. It supports 18 networks across EVM and Solana. It has a 7-stage transaction pipeline. It integrates with 15 DeFi protocols.

None of that is relevant if the mental model is wrong. So here's the mental model:

There are three principals in the system, and they have different levels of trust.

  1. The owner — the human (or organization) that funds the wallet. They authenticate with ownerAuth using SIWE or SIWS signatures. They set policy, approve high-value transactions, and hold the kill switch.

  2. The master — the system administrator role that creates wallets and sessions. Authenticates with masterAuth using Argon2id. This is typically infrastructure automation, not a human sitting at a keyboard.

  3. The session — the AI agent. It gets a JWT that scopes what it can do. It authenticates with sessionAuth. It operates entirely within the policy envelope the owner and master have defined.

The agent never holds the private key. It holds a session token that lets it request transactions. The daemon handles signing. This is the critical architectural choice that makes autonomous operation safe: the agent has economic agency (it can initiate spending decisions) without having custody (it can't drain the wallet by bypassing controls).

A Policy Engine That Actually Enforces Rules

The policy engine is where the rubber meets the road on autonomous operation. WAIaaS has 21 policy types and 4 security tiers: INSTANT, NOTIFY, DELAY, and APPROVAL.

Here's what a spending limit policy looks like:

curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "SPENDING_LIMIT",
    "rules": {
      "instant_max_usd": 100,
      "notify_max_usd": 500,
      "delay_max_usd": 2000,
      "delay_seconds": 900,
      "daily_limit_usd": 5000
    }
  }'

That's not pseudocode. That's the actual API call. A transaction under $100 executes immediately. Between $100 and $500, it executes immediately but the owner gets notified. Between $500 and $2,000, it gets queued for 15 minutes — enough time for the owner to cancel if something looks wrong. Over $2,000, it requires explicit owner approval through WalletConnect, Telegram, or a push notification.

The REPUTATION_THRESHOLD policy type fits into the same framework. You set a minimum reputation score, and the policy engine enforces it at transaction time. If the counterparty doesn't meet the threshold, the transaction is denied with a POLICY_DENIED error — the same structured error format used throughout the system:

{
  "error": {
    "code": "POLICY_DENIED",
    "message": "Transaction denied by SPENDING_LIMIT policy",
    "domain": "POLICY",
    "retryable": false
  }
}

Other policy types relevant to autonomous agent operation include CONTRACT_WHITELIST (the agent can only interact with pre-approved contracts), ALLOWED_TOKENS (default-deny token whitelist), X402_ALLOWED_DOMAINS (more on this in a moment), and VENUE_WHITELIST (allowed trading venues).

Default-deny is not a configuration option. It's the baseline. An agent operating without explicit allowlists set cannot move tokens to arbitrary addresses or call arbitrary contracts. You grant permissions explicitly; you don't restrict from an open default.

x402: The HTTP Payment Layer for Machine Commerce

ERC-8004 reputation handles identity and trust. But how does an agent actually pay for things at the HTTP layer?

The x402 protocol is a proposed extension to HTTP where a server responds with HTTP 402 (Payment Required) and an attached payment claim. The client — in this case, an AI agent — pays the claim and resubmits the request. The whole thing happens in-band with the HTTP request, without any human in the loop.

WAIaaS has native x402 support. The MCP tool is called x402-fetch, and the TypeScript SDK exposes it as client.x402Fetch(). The policy engine has X402_ALLOWED_DOMAINS so you can restrict which domains the agent is permitted to pay automatically.

The practical implication: an AI agent can call a paid API, receive a 402 response, pay it from its wallet, and complete the request — all autonomously, all within the spending limits and domain restrictions you've configured. No human clicks "approve payment." The policy envelope does that work.

This is what machine-to-machine commerce actually looks like. Not a billing portal. Not a human reviewing invoices. An agent with a wallet, a reputation, and a set of rules it operates within.

Getting Something Running

If you want to see this in practice rather than read about it, here's the minimal path:

Step 1: Start the daemon

git clone https://github.com/waiaas/WAIaaS.git
cd WAIaaS
docker compose up -d

The daemon binds to 127.0.0.1:3100 by default.

Step 2: Create a wallet and session

# Create a wallet
curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "trading-wallet", "chain": "solana", "environment": "mainnet"}'

# Create a session token for your agent
curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

Step 3: Set a spending policy

Before your agent touches real funds, set a spending limit. The example from earlier — $100 instant, $500 notify, $2,000 delay with 15-minute queue, $5,000 daily cap — is a reasonable starting point for a trading agent.

Step 4: Connect to Claude via MCP

{
  "mcpServers": {
    "waiaas": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_SESSION_TOKEN": "wai_sess_<your-token>",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    }
  }
}

Or use the CLI shortcut:

npm install -g @waiaas/cli
waiaas mcp setup --all

From there, Claude has access to 45 MCP tools covering wallet operations, transactions, DeFi positions, NFTs, and x402 payments. It can check balances, execute swaps on Jupiter, query DeFi positions across 15 integrated protocols, and pay for API calls via x402 — all within the policy constraints you've defined.

The Bigger Picture

The reason this matters beyond the technical specifics is that we're at an inflection point. The question of whether AI agents will participate in economic activity is largely settled — of course they will. The open question is whether that participation will be trustless and transparent, or whether it will require humans as intermediaries at every step.

Trustless doesn't mean unsupervised. The policy engine, the security tiers, the owner approval flow, the WalletConnect integration for human-in-the-loop signing — all of that exists precisely because autonomous operation needs guard rails. The goal isn't to remove humans from the picture. It's to make human oversight scalable — to let an owner set policy once and then have the system enforce it consistently across thousands of agent transactions, surfacing only the exceptions that genuinely require human judgment.

ERC-8004 reputation is one piece of that puzzle. It gives agents verifiable identity that accumulates over time. Combined with the x402 payment layer, the policy engine, and the session-based auth model, it starts to look like the infrastructure layer that autonomous economic agents actually need.

That infrastructure exists today. It's open-source. You can run it on your own hardware. The 684+ test files suggest the team takes correctness seriously. The interactive API reference at /reference means you don't have to guess at the API shape.

What's Next

If you're building agents that need economic autonomy, the place to start is the WAIaaS GitHub repository — the README has the quickstart path, and the codebase is the authoritative source on what's actually implemented. For a broader overview of capabilities and deployment options, waiaas.ai has the documentation. The most productive next step is probably standing up a local instance with Docker Compose, creating a test wallet, and seeing what the policy engine actually enforces — reading about default-deny is less convincing than watching a transaction get blocked because you forgot to configure ALLOWED_TOKENS.