Verifiable AI Messages in Claude: ERC-8128 Signature Tools for Trustless Communication

2026-10-14

Verifiable AI Messages in Claude: ERC-8128 Signature Tools for Trustless Communication

Trustless communication between AI agents and web services is one of the hardest unsolved problems in the agentic stack — and if you're building Claude-powered workflows via MCP, you've probably already hit the wall where your agent needs to prove it is who it says it is. One line in your claude_desktop_config.json gives your Claude agent a wallet, 45 MCP tools, and — critically — the ability to sign and verify messages using ERC-8128, so every HTTP request your agent makes can be cryptographically authenticated.

Why Agent Identity Actually Matters

When a human visits an API, they log in with a password, an OAuth token, or a certificate. When an AI agent hits an API autonomously, what does authentication look like? A bearer token is a start, but it doesn't tell the receiving service which agent signed the request, whether the request was tampered with in transit, or whether the agent has the reputation to be trusted at all.

This is the gap that cryptographic signing closes. If your Claude agent signs every outbound HTTP request with a private key — and the receiving service can verify that signature against a known public key — you get tamper-evident, identity-bound communication without any centralized identity provider. ERC-8128 formalizes exactly this pattern for AI agents: a standard for HTTP request signing that ties agent actions to an onchain key, making agent behavior auditable and verifiable. WAIaaS exposes this capability directly as MCP tools, so Claude can call them natively.

What WAIaaS Brings to MCP

WAIaaS is a self-hosted, open-source Wallet-as-a-Service daemon designed to be the financial and cryptographic backend for AI agents. From Claude's perspective, it's just an MCP server — but under the hood it's a 15-package monorepo running a 7-stage transaction pipeline, 21-policy-type security engine, and integrations with 15 DeFi protocols across 18 networks.

The MCP server ships 45 tools covering wallet operations, transfers, DeFi actions, NFTs, onchain reputation, and — the focus of this post — ERC-8128 message signing and verification.

The two tools that matter most for trustless agent communication are:

erc8128-sign-request — signs an HTTP request payload with the agent's wallet key
erc8128-verify-signature — verifies an ERC-8128 signature against a known public key

These live alongside the broader tool set that includes get-balance, send-token, simulate-transaction, get-defi-positions, get-health-factor, polymarket, hyperliquid, and 38 others. Signing is just one dimension of what a credentialed agent can do once it has a wallet.

One Line to Give Claude a Wallet

The fastest path from zero to a signing-capable Claude agent is the WAIaaS CLI quickstart:

npm install -g @waiaas/cli
waiaas init
waiaas start
waiaas quickset --mode mainnet

quickset creates wallets, issues session tokens, and prints the MCP config JSON you need to paste into Claude Desktop. Or you can auto-register with:

waiaas mcp setup --all

Either way, you end up with a config block like this:

{
  "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"
      }
    }
  }
}

Paste that into ~/Library/Application Support/Claude/claude_desktop_config.json, restart Claude Desktop, and your agent now has 45 tools available — including erc8128-sign-request and erc8128-verify-signature.

Understanding ERC-8128 in Practice

Here's the concrete scenario: your Claude agent is calling a third-party API that requires proof the request came from a specific, trusted agent identity. Without signing, you're relying on a shared secret (the session token). With ERC-8128 signing, the receiving service can verify the request against your agent's public key without ever having seen the private key.

The flow looks like this:

Claude constructs the request payload it wants to send
Claude calls erc8128-sign-request via MCP → WAIaaS signs it with the wallet's private key
Claude sends the signed request to the target service
The target service calls erc8128-verify-signature (or the agent does, if it's verifying a response) → validity confirmed

From Claude's side, this is entirely natural language driven. You'd say something like: "Sign this API request payload with my wallet key and send it to api.example.com" — and Claude orchestrates the MCP tool calls to make it happen.

The Policy Layer: Controlling Which Domains Can Be Signed For

This is where WAIaaS's security model becomes important. You probably don't want your Claude agent signing arbitrary HTTP requests to any domain it pleases. The ERC8128_ALLOWED_DOMAINS policy type lets you whitelist exactly which domains the agent is permitted to sign requests for.

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": "ERC8128_ALLOWED_DOMAINS",
    "rules": {
      "domains": ["api.example.com", "*.trustedservice.io"]
    }
  }'

If Claude tries to sign a request for a domain not on this list, the policy engine blocks it — before the signing operation reaches the wallet. This is the default-deny posture that runs through every layer of WAIaaS: transactions (and signing operations) are blocked unless explicitly permitted.

The broader policy engine has 21 policy types and 4 security tiers (INSTANT, NOTIFY, DELAY, APPROVAL). For signing operations, you're typically working at the INSTANT tier — the signing happens immediately — but the domain whitelist acts as a gate that runs before any tier evaluation.

Onchain Reputation: ERC-8004 Tools for Agent Credentialing

ERC-8128 handles message authentication — proving a specific key signed a specific payload. But there's a related question: should this agent be trusted at all? That's where ERC-8004 comes in, and WAIaaS exposes those tools through MCP as well:

erc8004-get-agent-info — retrieves onchain agent metadata
erc8004-get-reputation — fetches the agent's reputation score from the chain
erc8004-get-validation-status — checks whether an agent has passed onchain validation

Together with REPUTATION_THRESHOLD policy (one of the 21 policy types), you can configure WAIaaS to refuse to sign anything until the agent's onchain reputation meets a minimum threshold. This creates a trust stack:

The domain whitelist controls where the agent can sign
The reputation threshold controls whether the agent is considered credentialed enough to sign at all
The signature itself proves which key signed each individual request

That's three independent, composable layers — all configurable without touching agent code.

Multi-Wallet Setup for Isolated Agent Identities

If you're running multiple Claude agents — say, a trading agent and a general-purpose assistant — you almost certainly want them to have separate wallet identities and separate signing keys. WAIaaS handles this natively:

{
  "mcpServers": {
    "waiaas-trading": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_AGENT_ID": "019c47d6-51ef-7f43-a76b-d50e875d95f4",
        "WAIAAS_AGENT_NAME": "trading-agent",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    },
    "waiaas-solana": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_AGENT_ID": "019c4cd2-86e8-758f-a61e-9c560307c788",
        "WAIAAS_AGENT_NAME": "solana-wallet",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    }
  }
}

Each agent gets its own session token, its own wallet keys, its own policy set, and therefore its own ERC-8128 signing identity. The receiving service can tell these agents apart by their public keys — not just by which bearer token they present.

The Auth Model Behind the Tools

It's worth understanding what's actually protecting your agent's signing key inside WAIaaS, because the security of the whole system depends on it.

WAIaaS uses three authentication layers:

masterAuth (Argon2id) — system administrator; creates wallets, policies, sessions
sessionAuth (JWT HS256) — the AI agent's credential; what Claude uses to call MCP tools
ownerAuth (SIWS/SIWE) — the human fund owner; required for approvals and kill-switch recovery

When Claude calls erc8128-sign-request, it's operating under sessionAuth. The signing key lives inside the WAIaaS daemon, the session token just authorizes the operation — the private key never leaves the server. This means even if a session token is compromised, an attacker can't extract the underlying wallet key.

For high-value signing operations, you can configure the APPROVAL tier, which requires an ownerAuth signature (via WalletConnect, for instance) before the signing proceeds. That's human-in-the-loop for cryptographic operations, which is a meaningful safety property.

Simulating Before Signing

If you want to verify that a signing operation will be permitted by your policies before it actually executes, WAIaaS supports dry-run mode across its API:

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "type": "TRANSFER",
    "to": "recipient-address",
    "amount": "0.1",
    "dryRun": true
  }'

The same dry-run capability that applies to token transfers applies across the pipeline — so you can test policy configurations without committing any onchain state.

Quick Start: From Zero to Signing in 5 Steps

Install the CLI and start the daemon:

npm install -g @waiaas/cli
waiaas init
waiaas start

Create wallets and sessions:
```
waiaas quickset --mode mainnet
```
Register with Claude Desktop:
```
waiaas mcp setup --all
```

Add a domain policy (so signing is allowed for your target service):

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": "ERC8128_ALLOWED_DOMAINS",
    "rules": {"domains": ["api.yourservice.com"]}
  }'

Restart Claude Desktop and ask Claude to sign a request — it will call erc8128-sign-request automatically when you describe what you want to do.

What's Next

The ERC-8128 tools are one slice of the 45 MCP tools WAIaaS exposes to Claude — the same wallet that signs verifiable messages can also swap tokens on Jupiter, check Aave health factors, trade perpetuals on Hyperliquid, and monitor incoming transactions in real time. If you're building agentic workflows where trust and accountability matter, the combination of cryptographic signing, onchain reputation, and a default-deny policy engine gives you a foundation that's hard to replicate with ad-hoc tooling.

Explore the full codebase and deployment options on GitHub: https://github.com/waiaas/WAIaaS

Learn more about WAIaaS and its capabilities at: https://waiaas.ai