Trustless Trading Bots: ERC-8004 Onchain Reputation for Automated DeFi

2026-07-06

Trustless Trading Bots: ERC-8004 Onchain Reputation for Automated DeFi

Trustless trading bots that execute DeFi strategies autonomously sound great until you ask the hard question: how does anyone — a protocol, a counterparty, a smart contract — actually verify that your bot is what it claims to be? Reputation in DeFi has always been fragile, off-chain, and easy to fake. ERC-8004 changes that, and WAIaaS ships with native support for it alongside 15 integrated DeFi protocols — so you can build a bot that doesn't just trade, but proves itself onchain.

Why Onchain Agent Reputation Actually Matters

If you've built a DeFi trading bot before, you've dealt with the trust problem from the other direction: you're the one who has to trust the protocols, the oracles, the RPC endpoints. But as automated agents become more capable — executing multi-step strategies across Jupiter swaps, Aave lending positions, Hyperliquid perps, and Lido staking in a single session — the question flips. Protocols, DAOs, and other agents need a way to trust your bot.

ERC-8004 is a standard for onchain agent reputation and validation. Instead of your bot just asserting "I'm authorized," it can present cryptographically verifiable reputation data that lives on-chain. This matters for DeFi specifically because you're often interacting with smart contracts that could gate access, apply different fee tiers, or require proof of trustworthiness before allowing high-value operations. Without something like ERC-8004, your bot is a black box to everyone it interacts with.

WAIaaS has built ERC-8004 support directly into its architecture — both as a DeFi action provider (erc8004 in the protocol list) and as MCP tools (erc8004-get-agent-info, erc8004-get-reputation, erc8004-get-validation-status) that AI agents can call directly. Combined with 14 other protocol integrations and a policy engine that enforces rules before any transaction executes, it's the infrastructure layer for building bots that are both capable and verifiable.

The Protocol Stack Your Bot Actually Needs

Let's be concrete. A serious DeFi trading bot in 2026 isn't just doing spot swaps. It's managing positions across multiple layers: swapping on DEXes, lending/borrowing for leverage, staking idle assets, bridging between chains, and sometimes trading perps. WAIaaS integrates 15 DeFi protocol providers:

EVM side: Aave v3 (lending), Lido (liquid staking), 0x Swap, LI.FI (cross-chain bridging), Across (bridging), Pendle (yield tokenization), Polymarket (prediction markets)

Solana side: Jupiter Swap, Kamino (lending/vaults), Jito (liquid staking), Drift (perpetuals), D'CENT swap, XRPL DEX

Cross-chain/meta: Hyperliquid (perpetuals and spot), ERC-8004 (agent reputation)

Instead of maintaining 15 separate SDKs, authentication flows, and error handling implementations, you make a single API call pattern. Here's what executing a Jupiter swap looks like:

curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount": "1000000000"
  }'

That's SOL → USDC on Jupiter. The same Authorization header and the same request pattern works across every protocol. Your bot doesn't need to know how Jupiter constructs its versioned transactions under the hood — that complexity lives inside WAIaaS.

ERC-8004: Wiring in Onchain Reputation

Here's where it gets interesting for trustless systems. The erc8004 provider in WAIaaS exposes three MCP tools that your bot can call:

These aren't just read operations for curiosity. In a production system, you'd wire erc8004-get-validation-status into your bot's pre-trade logic. Before your bot interacts with another agent's positions, or before you allow an external agent to trigger actions on your wallet, you check its validation status first.

WAIaaS also exposes this at the policy layer via the REPUTATION_THRESHOLD policy type. You can set a minimum onchain reputation score that any agent must meet before transactions are allowed — enforced by the policy engine before execution, not as an afterthought in application code:

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": "REPUTATION_THRESHOLD",
    "rules": {
      "min_reputation_score": 80
    }
  }'

This is the default-deny philosophy applied to agent trust: unless an interacting agent meets your reputation threshold, the transaction doesn't happen. The policy engine enforces it at stage 3 of the 7-stage transaction pipeline, before execution ever reaches the protocol layer.

The 7-Stage Pipeline: Where Safety Lives

Speaking of the pipeline — understanding it matters for bot builders because it's where all your safety guarantees actually live. Every transaction, whether it's a Jupiter swap or an Aave borrow, goes through these stages:

  1. Validate — schema and parameter validation
  2. Auth — verify the session token
  3. Policy — check all applicable policies (this is where REPUTATION_THRESHOLD, SPENDING_LIMIT, CONTRACT_WHITELIST, etc. all fire)
  4. Wait — enforce time delays if the DELAY tier was triggered
  5. Execute — broadcast to the network
  6. Confirm — wait for confirmation

The policy check at stage 3 is comprehensive. For a DeFi bot, the relevant policy types include:

That's 11 policy types directly relevant to DeFi trading, out of 21 total. For a bot managing real funds, you'd typically layer several of these together. Here's a spending limit that creates meaningful safety tiers for an automated strategy:

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
    }
  }'

Transactions under $100 execute immediately. $100-$500 execute but trigger a notification to the owner. $500-$2000 get queued for 15 minutes, cancellable by the owner via WalletConnect. Above $2000, the bot needs explicit human approval before anything moves.

Simulate Before You Execute

One of the most practical features for bot development is the dry-run API. Before you wire up a new strategy to live funds, you can simulate the full transaction — including policy checks — without broadcasting to the network:

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 dryRun: true flag runs the full pipeline except the execute and confirm stages. If your CONTRACT_WHITELIST would block this transaction, you find out in simulation, not after a failed on-chain transaction. If the SPENDING_LIMIT would route it to the DELAY tier instead of INSTANT, simulation tells you that too.

This is table stakes for any serious bot development workflow — you should know exactly what the policy engine will do before you deploy.

Building the Bot: TypeScript SDK

For production bots, the REST API is fine but the TypeScript SDK is cleaner. Here's a simplified example of a bot that checks its wallet state, executes a strategy, and polls for confirmation:

import { WAIaaSClient, WAIaaSError } from '@waiaas/sdk';

const client = new WAIaaSClient({
  baseUrl: process.env['WAIAAS_BASE_URL'] ?? 'http://localhost:3100',
  sessionToken: process.env['WAIAAS_SESSION_TOKEN'],
});

// Check balance before executing
const balance = await client.getBalance();
console.log(`Balance: ${balance.balance} ${balance.symbol} (${balance.chain}/${balance.network})`);

// Execute the strategy
const sendResult = await client.sendToken({
  type: 'TRANSFER',
  to: 'recipient-address',
  amount: '0.001',
});
console.log(`Transaction submitted: ${sendResult.id} (status: ${sendResult.status})`);

// Poll for confirmation
const POLL_TIMEOUT_MS = 60_000;
const startTime = Date.now();
while (Date.now() - startTime < POLL_TIMEOUT_MS) {
  const tx = await client.getTransaction(sendResult.id);
  if (tx.status === 'COMPLETED') {
    console.log(`Confirmed! Hash: ${tx.txHash}`);
    break;
  }
  if (tx.status === 'FAILED') {
    console.error(`Failed: ${tx.error}`);
    break;
  }
  await new Promise(resolve => setTimeout(resolve, 1000));
}

Error handling is worth calling out explicitly — policy denials come back as structured errors, not generic HTTP 4xx responses:

try {
  const tx = await client.sendToken({ to: '...', amount: '1.0' });
} catch (error) {
  if (error instanceof WAIaaSError) {
    console.error(`API Error: [${error.code}] ${error.message}`);
    // error.code examples: INSUFFICIENT_BALANCE, POLICY_DENIED, TOKEN_EXPIRED
  }
}

A POLICY_DENIED error with domain: "POLICY" tells you exactly what stopped the transaction. Your bot can branch on error codes — retry with a smaller amount, alert the operator, or fail gracefully — instead of parsing error message strings.

45 MCP Tools for AI-Native Bots

If you're building an AI agent rather than a traditional algorithmic bot, the MCP integration gives Claude (or any MCP-compatible model) direct access to 45 tools covering wallet operations, transactions, DeFi positions, NFTs, and ERC-8004 reputation queries. The setup is minimal:

waiaas mcp setup --all    # Auto-register all wallets with Claude Desktop

The tools include the full ERC-8004 surface (erc8004-get-agent-info, erc8004-get-reputation, erc8004-get-validation-status), DeFi position queries (get-defi-positions, get-health-factor), and trading actions (send-batch, simulate-transaction, x402-fetch). An AI agent can check its own reputation, verify counterparty agents, and execute multi-protocol strategies through the same tool interface.

Quick Start for DeFi Developers

Here's the minimal path from zero to a running bot with policy guardrails:

1. Start the daemon:

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

2. Create a wallet and session:

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

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

3. Apply DeFi-specific policies (PERP_MAX_LEVERAGE, CONTRACT_WHITELIST, SPENDING_LIMIT) using the policy API shown above.

4. Simulate your first action with dryRun: true to verify policy behavior before using live funds.

5. Install the SDK and connect your strategy:

npm install @waiaas/sdk

The OpenAPI spec auto-generated at /doc and interactive Scalar UI at /reference give you the full endpoint reference while you're building.

What's Next

The 15 protocol integrations, 21 policy types, and ERC-8004 reputation tools are all documented in the interactive API reference at http://localhost:3100/reference once you're running. The GitHub repo has the full codebase, including the 683+ test files that cover the pipeline stages and policy engine — useful reading if you want to understand exactly how policy enforcement works before trusting it with real funds.

Start building at github.com/minhoyoo-iotrust/WAIaaS and find protocol documentation, deployment guides, and SDK references at waiaas.ai.