What AI Agents Actually Need from Blockchain Infrastructure: RPC, WebSockets, and the Missing Infrastructure Layer

In the first two weeks after ERC-8004 launched on Ethereum mainnet on January 29, 2026, over 21,000 AI agents registered on-chain. By early March, that number crossed 85,788 agents across 18+ EVM chains. Combined with 550+ existing Web3 AI agent projects, the picture is clear: autonomous agents are live, on-chain, and generating real RPC traffic.

The agent standards stack is converging fast. ERC-8004 gives agents verifiable identity and reputation. x402 lets them pay for services over HTTP with USDC. MCP (Model Context Protocol) exposes blockchain tools to LLMs via JSON-RPC 2.0. EIP-7702 enables smart account delegation with session keys and spending limits.

Most of the conversation focuses on what agents do, not what they need. Agents do not browse dashboards. They fire bursts of RPC calls, maintain persistent WebSocket connections, query multiple chains in parallel, and operate 24/7 with no human to click "retry." The infrastructure assumptions behind most RPC providers were built for human-driven applications. Those assumptions break down when agents become the primary consumers.

This guide covers how AI agents use RPC infrastructure, what the emerging standards stack demands from providers, and five specific infrastructure requirements that most providers get wrong for agent workloads.

How AI Agents Actually Use RPC

Agent-to-blockchain interactions follow five distinct patterns. Each places different demands on your infrastructure.

1. State Reads

The most frequent operation. Agents call eth_call, eth_getBalance, eth_getCode, and eth_getLogs to read contract state, check token balances, and monitor on-chain conditions. A DeFi agent monitoring arbitrage opportunities across 5 DEXs might fire 500+ eth_call requests per minute for price feeds alone. Multi-chain agents multiply this by the number of chains they monitor.

The critical difference from human dApps: agents read state continuously, not in response to user clicks. Infrastructure needs to handle sustained read throughput, not peak request bursts.

2. Transaction Submission

When an agent identifies an opportunity, it submits transactions via eth_sendRawTransaction. Latency is critical. A 200ms delay on transaction submission can mean the difference between a successful arbitrage capture and a missed opportunity worth thousands of dollars. Agents need low-latency transaction submission paths and confirmation monitoring via eth_getTransactionReceipt immediately after.

For a deeper look at latency-sensitive transaction infrastructure, see the MEV bot infrastructure guide.

3. Event Subscriptions

Agents subscribe to real-time blockchain events via WebSocket connections using eth_subscribe for newHeads, logs, and pendingTransactions. A liquidation bot monitors health factor changes across lending protocols. A trading agent watches for large swap events. An agent orchestrator listens for ERC-8004 registration events to discover new agents.

These connections must stay alive for hours or days. A dropped subscription during a market crash means missed liquidation events worth thousands. Connection persistence matters more than raw throughput for agent workloads. See Hyperliquid WebSocket subscription limits for how connection management affects real-time data reliability.

4. Registry Queries (New with ERC-8004)

ERC-8004 introduces on-chain agent registries that create new RPC read patterns. Agents call ResolveByDomain() and ResolveByAddress() to discover other agents. They call getSummary() and readAllFeedback() to evaluate reputation before interacting. They use eth_getLogs to filter registration and feedback events across the Identity, Reputation, and Validation registries.

These are standard contract reads using Ethereum RPC methods, but the access pattern is new: agents perform discovery queries in bursts, reading dozens of registry entries before selecting a counterparty.

5. Payment Flows (New with x402)

When an agent pays for an API call via x402, the flow requires low-latency RPC on the settlement chain, typically Base or Ethereum. The agent signs an EIP-3009 TransferWithAuthorization, and the Facilitator submits the on-chain USDC transfer. Settlement takes 1-2 seconds on Base. Slow RPC adds directly to payment latency, stacking on top of the HTTP round-trip.

For agents making dozens or hundreds of paid API calls per hour, RPC performance on the payment chain becomes a bottleneck even if the agent's primary activity is on a different network.

The Agent Lifecycle

These patterns combine into a continuous operational loop:

Discover  ->  Evaluate  ->  Execute  ->  Verify  ->  Report
  |              |             |            |           |
  |  ERC-8004    | Reputation  | eth_send   | Receipts  | Logs
  |  registry    | queries,    | Raw        | and       | and
  |  lookups     | Agent Cards | Transaction| traces    | events
  |              |             |            |           |
  v              v             v            v           v
(eth_call,    (eth_call,   (eth_send    (eth_get     (eth_getLogs,
 getLogs)      getLogs)    RawTxn)     TxnReceipt)   subscribe)

Each stage depends on reliable, low-latency RPC. A failure at any point breaks the loop. There is no user to manually retry.

The Emerging Agent Stack

Four standards are converging to form the infrastructure layer for autonomous agents on-chain. Each changes what your RPC layer needs to support.

ERC-8004: Agent Identity and Reputation

ERC-8004, launched on Ethereum mainnet on January 29, 2026, provides three on-chain registries:

• Identity Registry (ERC-721 + URIStorage): Each agent gets a unique NFT representing its on-chain identity, with metadata stored as a URI. 85,788+ agents are registered across 18+ EVM chains as of early March 2026.
• Reputation Registry: Agents and users submit feedback as int128 values, building on-chain reputation scores.
• Validation Registry: Generic hooks for custom validation logic, still under active development.

Each registry deploys as a singleton per chain - one contract instance serves all agents on that network with no cross-chain messaging between instances.

The Agent Card format complements the on-chain registries. Agents publish a JSON file at /.well-known/agent-card.json describing their capabilities, supported protocols (A2A, MCP), trust models, and registration details. Other agents and LLMs read this file during discovery.

Infrastructure impact: ERC-8004 creates new read patterns against known singleton addresses. The operations are standard eth_call and eth_getLogs, but volume scales with agent count. As the registry grows beyond 85,000 entries, query efficiency and log filtering performance become infrastructure concerns.

For the full ERC-8004 specification, see EIP-8004 on eips.ethereum.org.

x402: HTTP-Native Payments

x402 enables AI agents to pay for API calls directly over HTTP using USDC, without accounts, API keys, or human authorization. The protocol has processed 35M+ transactions with $26.19M+ in total volume, including a peak of 239,505 transactions in a single day.

The payment flow works in six steps: the client requests a resource, the server responds with HTTP 402 and a PAYMENT-REQUIRED header, the client signs an EIP-3009 authorization, the client resends with a PAYMENT-SIGNATURE header, a Facilitator verifies and submits the on-chain transfer, and the server delivers the resource. The agent never needs gas tokens - the Facilitator pays gas.

Infrastructure impact: Every x402 payment requires at least one on-chain transaction on the settlement chain. Agents making frequent paid API calls generate sustained RPC traffic on Base, where most x402 volume settles. Low-latency RPC on the payment chain directly reduces end-to-end payment time.

For a complete technical breakdown of x402 architecture and a working implementation, see What Is x402 Protocol.

MCP: Model Context Protocol

MCP, developed by Anthropic, provides a standardized way for LLMs and AI agents to interact with external tools. With 97 million monthly SDK downloads across Python and TypeScript and over 1,200 MCP servers deployed, MCP is the default tool integration layer for AI systems.

MCP uses JSON-RPC 2.0 as its transport protocol - the same protocol blockchain nodes use. Blockchain MCP servers wrap RPC methods as "tools" that LLMs can invoke. An LLM calls a tool like getTokenBalance, which internally makes an eth_call to an RPC endpoint.

Infrastructure impact: MCP adds an abstraction layer between the LLM and the blockchain, but RPC quality directly determines tool reliability. A flaky RPC endpoint means flaky MCP tools. Timeouts, rate limits, and connection drops at the RPC layer propagate up through MCP as tool failures that the LLM must handle. QuickNode and Chainstack have both published blockchain MCP servers, and reliable RPC is what makes them work.

EIP-7702: Smart Account Delegation

The Pectra upgrade (May 2025) introduced EIP-7702, which allows Externally Owned Accounts (EOAs) to temporarily delegate execution to smart contract code via a new transaction type (0x04). For agents, this enables:

• Session keys: Agents operate with limited-permission keys that expire after a set time or number of uses
• Spending limits: On-chain enforcement of maximum transaction values
• Batched transactions: Multiple operations in a single transaction, reducing gas and latency
• Programmable guards: Custom logic that validates every agent action before execution

EIP-7702 complements ERC-4337 bundler infrastructure for account abstraction. Together, they give agents smart account capabilities without requiring a full smart contract wallet deployment.

Infrastructure impact: Transaction type 0x04 is a format that not all tooling handles correctly yet. Your RPC provider and transaction simulation tools need to support it. Bundler infrastructure for ERC-4337 UserOperations adds another RPC dependency for agents using account abstraction.

The Stack, Visualized

Identity Layer    | ERC-8004 (Agent Cards, Reputation, Validation)
Payment Layer     | x402 (HTTP-native USDC payments)
Tool Layer        | MCP (JSON-RPC 2.0 tool protocol)
Account Layer     | EIP-7702 / ERC-4337 (Smart accounts, session keys)
------------------+---------------------------------------------------
Infrastructure    | RPC Endpoints / Dedicated Nodes / WebSockets

Every layer above the line depends on the infrastructure layer below it. Registry lookups, payment settlement, tool calls, and transaction submission all flow through RPC endpoints. The agent stack is only as reliable as its infrastructure foundation.

Five Infrastructure Requirements Traditional Providers Get Wrong

Most RPC providers optimized for human-driven dApps: a user clicks a button, the frontend makes a few RPC calls, the user waits. Agent workloads break these assumptions in specific, measurable ways.

1. Predictable Billing, Not Credit-Weighted Pricing

The biggest cost surprise for agent workloads comes from compute unit multipliers. Agents do not make uniform API calls. A single workflow might mix cheap state reads with expensive trace operations, and cost per call varies by 10-1,000x depending on method and provider.

Consider an arbitrage agent making 50,000 eth_call requests and 200 debug_traceTransaction requests per day. Here is what that costs across providers:

At Infura's credit weighting, the same workload consumes 84x more credits than at Dwellir. For a continuously running agent, this difference determines whether the operation is economically viable. The problem compounds because agents cannot predict their method mix in advance - they adapt behavior based on market conditions.

Dwellir's 1:1 pricing model charges 1 credit per RPC response regardless of method. An eth_call costs the same as a debug_traceTransaction. For agents with unpredictable, mixed-method workloads, this eliminates billing uncertainty. For a broader comparison of RPC providers without compute unit complexity, see the dedicated guide.

2. WebSocket Reliability Over Raw Throughput

RPC providers compete on requests-per-second benchmarks. Agents care more about p99 connection uptime.

An agent monitoring liquidation opportunities on Aave maintains a WebSocket subscription to logs events filtered for health factor changes. That connection needs to stay alive for days. A single dropped subscription during a market crash means missed liquidation events. One missed liquidation during a volatile period can cost more than months of infrastructure fees.

The metrics that matter for agent WebSocket workloads:

• p99 connection uptime: What percentage of time does the WebSocket stay connected over a 30-day period?
• Reconnection gap: When a connection drops, how long until the subscription resumes?
• Subscription limit: How many concurrent subscriptions can a single connection support?
• Backpressure handling: What happens when event volume spikes during volatile markets?

Raw RPS numbers capture none of this. An endpoint handling 10,000 RPS but dropping WebSocket connections every 4 hours is worse for agents than one handling 1,000 RPS with 99.99% connection uptime.

For an example of how WebSocket limits affect real-time data systems, see Hyperliquid WebSocket subscription limits and the Hyperliquid order book server guide for gRPC streaming alternatives.

3. Multi-Chain From a Single Provider

An agent monitoring arbitrage opportunities across Ethereum, Arbitrum, Base, Polygon, and Solana needs RPC access to all five networks. With separate providers per chain, that means:

• 5 separate accounts
• 5 different billing models (some credit-weighted, some flat-rate, some subscription-based)
• 5 different rate limit policies
• 5 sets of API keys to manage and rotate
• 5 different support channels when something breaks

For autonomous agents, this operational complexity creates failure modes. An agent that exhausts rate limits on one provider while others have idle capacity is poorly architected. An agent handling 5 different error response formats adds fragile parsing logic.

Dwellir supports 150+ networks through a single account and API key. One billing model, one rate limit policy, one set of credentials. For multi-chain agents, this reduces both operational complexity and the surface area for configuration errors.

4. Machine-Readable Documentation and Structured Errors

When a human developer hits a rate limit, they read the error page, check the docs, and adjust their code. When an agent hits a rate limit, it receives an HTTP response and must decide automatically: retry, back off, switch providers, or abort.

Most RPC providers return errors optimized for humans, not machines:

• HTML error pages instead of JSON error responses
• Vague error messages like "request failed" instead of machine-parseable error codes
• Documentation designed for browser navigation, not programmatic discovery
• No llms.txt or MCP tool definitions for agent-accessible method discovery

The infrastructure that agents need looks different:

• Structured JSON errors with standardized error codes, retry-after headers, and remaining rate limit information
• llms.txt endpoints so LLMs can discover available RPC methods and their parameters
• MCP tool definitions so agent frameworks can enumerate and invoke RPC capabilities
• CLI tools with --output json for scripted infrastructure management

Dwellir provides llms.txt endpoints and CLI tooling with structured JSON output, making infrastructure discoverable and manageable by both human developers and autonomous agents.

5. Burst Capacity Without Throttling

Agents idle, then fire. A trading agent might make 2 RPC calls per minute during quiet markets, then fire 100 requests in 2 seconds when a large swap event triggers an opportunity. A portfolio rebalancing agent sits dormant for hours, then reads state across 20 contracts on 5 chains simultaneously.

Per-second rate limits break this pattern. An agent with a 10 RPS limit cannot execute a 100-request burst even if it has been idle for an hour. The provider has unused capacity, the agent has unused credits, but the rate limiter says no.

Agent-friendly infrastructure needs burst headroom: rate limits measured per minute or per hour rather than per second, or burst allowances that let agents temporarily exceed steady-state limits. Some providers offer dedicated node allocations where the agent gets guaranteed capacity without shared rate limits.

For latency-sensitive workloads, dedicated nodes remove throttling entirely. This matters most for agents combining high-frequency reads with time-critical transaction submission.

Building Your First Agent-Ready Infrastructure Stack

With these requirements defined, here is a practical checklist for setting up infrastructure that supports autonomous agent workloads.

Infrastructure Checklist

• Choose a provider with 1:1 or flat-rate pricing for your target chains
• Set up both HTTPS and WSS endpoints for each chain
• Implement WebSocket reconnection with exponential backoff
• Use multicall for batched contract reads to reduce round trips
• Configure ERC-8004 registry contract addresses for agent discovery
• Ensure low-latency RPC on Base for x402 payment settlement
• Set up structured logging with per-method latency tracking
• Test burst patterns against rate limits before production deployment

WebSocket Connection with Reconnection Logic

Agents need persistent WebSocket connections that survive network interruptions. Here is a reconnection pattern using ethers.js with exponential backoff:

import { WebSocketProvider, JsonRpcProvider } from "ethers";

class AgentWebSocketManager {
  private wsProvider: WebSocketProvider | null = null;
  private reconnectAttempts = 0;
  private maxReconnectAttempts = 10;
  private baseDelay = 1000; // 1 second

  constructor(
    private wsUrl: string,
    private httpFallbackUrl: string,
    private onEvent: (log: any) => void
  ) {}

  async connect(): Promise<void> {
    try {
      this.wsProvider = new WebSocketProvider(this.wsUrl);

      // Monitor connection health
      this.wsProvider.websocket.on("close", () => {
        console.log("WebSocket closed, attempting reconnect...");
        this.reconnect();
      });

      this.wsProvider.websocket.on("error", (err: Error) => {
        console.error("WebSocket error:", err.message);
      });

      // Subscribe to contract events (e.g., ERC-8004 registry)
      await this.wsProvider.on(
        { topics: [/* your event signature hash */] },
        (log) => this.onEvent(log)
      );

      this.reconnectAttempts = 0;
      console.log("WebSocket connected and subscribed");
    } catch (err) {
      console.error("Connection failed:", err);
      await this.reconnect();
    }
  }

  private async reconnect(): Promise<void> {
    if (this.reconnectAttempts >= this.maxReconnectAttempts) {
      console.error("Max reconnect attempts reached, falling back to HTTP polling");
      this.fallbackToPolling();
      return;
    }

    const delay = this.baseDelay * Math.pow(2, this.reconnectAttempts);
    this.reconnectAttempts++;

    console.log(`Reconnecting in ${delay}ms (attempt ${this.reconnectAttempts})`);
    await new Promise((resolve) => setTimeout(resolve, delay));
    await this.connect();
  }

  private fallbackToPolling(): void {
    const httpProvider = new JsonRpcProvider(this.httpFallbackUrl);
    // Implement polling-based event monitoring as fallback
    setInterval(async () => {
      const logs = await httpProvider.getLogs({
        fromBlock: "latest",
        topics: [/* your event signature hash */],
      });
      logs.forEach((log) => this.onEvent(log));
    }, 12000); // Poll every 12 seconds (1 Ethereum block)
  }
}

// Usage
const manager = new AgentWebSocketManager(
  "wss://api-ethereum-mainnet.n.dwellir.com/YOUR_API_KEY",  // WSS endpoint
  "https://api-ethereum-mainnet.n.dwellir.com/YOUR_API_KEY", // HTTP fallback
  (log) => {
    console.log("Event received:", log);
    // Agent processes the event
  }
);

await manager.connect();

This pattern handles three critical agent requirements: automatic reconnection with backoff to avoid hammering the endpoint, a fallback to HTTP polling when WebSocket connectivity degrades, and clean event delivery to the agent's processing logic.

Batched Contract Reads with Multicall

Agents reading state from multiple contracts should batch calls to reduce round trips. A single multicall replaces N individual eth_call requests:

import { Contract, JsonRpcProvider } from "ethers";

// Multicall3 is deployed at this address on most EVM chains
const MULTICALL3_ADDRESS = "0xcA11bde05977b3631167028862bE2a173976CA11";
const MULTICALL3_ABI = [
  "function aggregate3(tuple(address target, bool allowFailure, bytes callData)[] calls) view returns (tuple(bool success, bytes returnData)[])",
];

async function batchAgentQueries(
  provider: JsonRpcProvider,
  agentRegistryAddress: string,
  agentAddresses: string[]
) {
  const multicall = new Contract(MULTICALL3_ADDRESS, MULTICALL3_ABI, provider);

  // Build batch: query reputation for multiple agents in one RPC call
  // encodeFunctionData and decodeReputation are app-specific helpers
  const calls = agentAddresses.map((addr) => ({
    target: agentRegistryAddress,
    allowFailure: true,
    callData: encodeFunctionData("getSummary", [addr]),
  }));

  // Single RPC call instead of N separate calls
  const results = await multicall.aggregate3(calls);

  return results.map((result: any, i: number) => ({
    agent: agentAddresses[i],
    success: result.success,
    reputation: result.success ? decodeReputation(result.returnData) : null,
  }));
}

For an agent evaluating 50 potential service providers from the ERC-8004 Reputation Registry, this reduces 50 RPC calls to 1. At scale, multicall is the difference between staying within rate limits and getting throttled.

For full Ethereum RPC method documentation, see Dwellir's Ethereum docs. For public endpoints to test against, see Dwellir's public RPC endpoints.

What Comes Next: The Infrastructure Roadmap for Agents

The agent stack is early. Several trends will reshape infrastructure requirements over the next 12-18 months.

Agent-to-agent discovery will drive new read patterns. As the ERC-8004 registry grows beyond 85,000 agents, discovery queries will become a meaningful share of RPC traffic. Agents evaluating multiple service providers before each interaction create read amplification that current indexing approaches may not handle well. Optimized registry querying and caching layers will become infrastructure features, not application concerns.

Payment volume will grow. x402 V2 introduces session support that makes high-frequency paid API calls practical. Google's AP2 protocol targets similar use cases with a different architecture. As more APIs adopt HTTP-native payment flows, RPC traffic on settlement chains (primarily Base) grows proportionally. Infrastructure providers with strong Base support will benefit.

Decentralized sequencing changes transaction submission. Espresso Systems is partnering with Arbitrum on decentralized sequencing, shifting how transactions get ordered and included. For agents submitting time-sensitive transactions on L2s, the sequencer landscape becomes another infrastructure variable to optimize for.

Agent-native chains are emerging. Kite AI ($33M raised, investors include PayPal Ventures) is building a blockchain designed specifically for AI agent payments and interactions. NEAR's AI-Intents architecture integrates agent reasoning directly into the protocol layer. These chains will require dedicated infrastructure support as they reach production.

As NEAR co-founder Illia Polosukhin stated in March 2026: "The users of blockchain will be AI agents." Gartner projects that 40% of enterprise applications will feature AI agents by 2026, up from 5% in 2025. Whether these projections hold exactly, the direction is clear: agent-generated RPC traffic will grow, and infrastructure providers that optimize for agent workloads will handle a growing share of blockchain interactions.

Key Takeaways

Agent workloads are structurally different from human dApp workloads. Continuous state reads, persistent WebSocket connections, burst transaction patterns, and multi-chain operation create infrastructure demands that traditional provider assumptions do not address.

The agent standards stack is real and live. ERC-8004 has 85,000+ registered agents. x402 has processed 35M+ transactions. MCP has 97M monthly SDK downloads. EIP-7702 is deployed on mainnet. These are production systems generating real RPC traffic, not proposals.

Pricing predictability matters more for agents than for humans. Agents cannot predict their method mix in advance. Credit-weighted pricing models that charge 20-1,000x more for certain methods create cost uncertainty that can make agent economics unviable.

WebSocket reliability is the most undervalued infrastructure metric. Agents depend on persistent connections for event-driven operation. Connection uptime, reconnection speed, and subscription limits matter more than peak RPS for most agent use cases.

Multi-chain is the default, not the exception. Agents operate across chains for discovery (Ethereum), payments (Base), execution (application-specific chains), and data (wherever the protocols live). Single-chain infrastructure is not sufficient.

Building infrastructure for AI agents? Dwellir provides RPC endpoints across 150+ networks with 1:1 pricing, WebSocket support, and multi-chain access from a single account.

• Get started: Create an account
• Pricing details: Transparent 1:1 pricing
• Public endpoints: Free RPC endpoints for testing
• Talk to the team: Discuss agent infrastructure needs