How to get a Base RPC endpoint for AI agents (2026 guide)

TL;DR

When an LLM controls the retry loop, a 429 response from Base’s public endpoint doesn’t pause the agent — it triggers an autonomous retry cascade that can exhaust a rate limit in seconds and silently fail the task mid-execution. Base has become the primary settlement layer for autonomous AI agents in 2026, with the x402 protocol processing over 165 million machine-to-machine transactions on Base and roughly 70,000 active agents transacting daily. This guide explains why AI agent infrastructure demands a private Base RPC endpoint with stable WebSocket connections, predictable billing, and Flashblocks support — and how to get one on Chainstack.

What is a Base RPC endpoint

Base is an OP Stack Layer 2 built by Coinbase that inherits Ethereum’s EVM execution environment while settling finality back to Ethereum mainnet. A Base RPC endpoint is an HTTPS or WebSocket URL that speaks standard Ethereum JSON-RPC — the same eth_sendRawTransaction, eth_call, and eth_getLogs methods your tooling already knows — but routes requests through Base’s sequencer rather than Ethereum’s validator set.

For AI agents operating on Base, the endpoint is the only door into the chain. Every wallet balance check, transaction submission, nonce lookup, and contract state read passes through it:

• Current account balance and nonce reads via eth_getBalance and eth_getTransactionCount
• Smart contract state calls via eth_call for reading DeFi positions, token prices, or agent wallet state
• Transaction broadcasting via eth_sendRawTransaction for agent-executed swaps, payments, and contract interactions
• Event log subscriptions via eth_subscribe logs for watching contract events in real time
• Flashblocks subscriptions via eth_subscribe newFlashblockTransactions for 200ms confirmation signals
• Historical state queries via debug_traceTransaction and archive methods for replaying past agent actions

You can review the full list of supported JSON-RPC methods and network parameters in the Base developer documentation.

For an AI agent, endpoint quality isn’t a preference — it’s the difference between a task that completes and one that silently fails mid-execution when a 429 interrupts an autonomous retry loop.

How Base RPC differs from Ethereum RPC

Base shares Ethereum’s JSON-RPC API surface, but the infrastructure decisions underneath it diverge in ways that directly affect how agents behave:

Attribute	Ethereum Mainnet	Base
Block time	~12 seconds	~2 seconds
Effective confirmation (Flashblocks)	N/A	~200ms via preconfirmations
Transaction fee	Variable — $0.50–$10+ depending on congestion	~$0.001 per transaction at typical load (May 2026)
Public RPC reliability	Rate-limited, congestion-prone	Rate-limited, explicitly not for production
Consensus	Proof of Stake (validator set)	OP Stack sequencer + Ethereum L1 settlement
L1 finality dependency	Native	~15 minutes for full Ethereum finality
Agent payment viability	Micro-transactions economically infeasible	Sub-cent fees enable millions of agent transactions daily

The two rows that matter most for AI agents are fee structure and Flashblocks. At ~$0.001 per transaction, Base is the only EVM environment where agents can execute thousands of on-chain actions daily without fee costs overwhelming the operation. Flashblocks’ 200ms preconfirmation signals let agents act on transaction outcomes without waiting a full 2-second block — a meaningful difference when an agent is chaining multiple sequential steps.

Base RPC endpoint options

Public vs private Base RPC endpoints

The public Base endpoint was designed for a developer opening MetaMask, not for an autonomous agent running a polling loop. The architectural problem isn’t just rate limits — it’s that agents don’t self-throttle. When an LLM-controlled loop encounters a failure, it retries.

Official public endpoints:

• Mainnet: https://mainnet.base.org
• Testnet (Sepolia): https://sepolia.base.org

⚠️ The public Base RPC endpoints are rate-limited and explicitly not intended for production systems. The Base docs themselves list professional node providers as the recommended path for any application beyond local development — and AI agents are the use case where that limit bites hardest.

Feature	Public RPC	Private RPC
Access	Free and open	Dedicated access
Resources	Shared infrastructure	Dedicated resources
Best use case	Local dev and one-off tests	AI agent production workloads
Rate limit	Aggressive — threshold unpublished	Controlled, plan-based, with documented RPS
WebSocket stability	Unreliable for persistent connections	Stable, monitored connections
Flashblocks support	Via mainnet-preconf.base.org only	Available on managed endpoints
Archive access	Not available	Available from $49/month

For an agent that subscribes to contract events, a WebSocket disconnect on a shared endpoint doesn’t just cause a hiccup — it causes a missed event the agent never knew about, leaving it in an inconsistent state with no recovery path.

📖 For a detailed comparison of Base RPC providers, see Best Base RPC providers for onchain applications in 2026.

Full node vs archive Base node

Archive access on Base matters specifically for agents that need to replay or verify past state — auditing previous transaction outcomes, reconstructing position history, or performing forensic analysis after an agent error.

Full node access	Archive node access
Current account balances and real-time nonce reads	Historical wallet state at any past block
Live contract state via eth_call	Historical contract state for position reconstruction
Event log subscriptions for real-time monitoring	Historical eth_getLogs queries beyond recent blocks
Transaction broadcasting and simulation	debug_traceTransaction on any historical transaction
Recent block queries	Complete trace history from genesis
Agent task execution and live monitoring	Agent audit trail reconstruction and error replay

Chainstack supports Base archive data access for both Base Mainnet and Base Sepolia Testnet from genesis, starting at $49/month.

For agents operating in regulated environments or those that need to prove what on-chain actions they took and when, archive access is the infrastructure requirement behind the compliance requirement.

HTTPS vs WebSockets

For AI agents, the transport choice isn’t about developer preference — it’s about which call patterns the agent actually generates. Most agent frameworks default to HTTP because it’s stateless and easy to retry. But agents that need to react to on-chain events — a price threshold crossing, a liquidation trigger, a new transaction landing — need WebSocket subscriptions. Polling every block via HTTP at 2-second intervals generates 1,800 requests per hour per agent just to maintain state awareness.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple — straightforward to retry	Requires reconnect and backfill logic
Best for	Nonce reads, tx submission, contract calls	Event subscriptions, Flashblocks feeds, real-time state
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

Flashblocks subscriptions are WebSocket-only — eth_subscribe newFlashblocks, eth_subscribe newFlashblockTransactions, and eth_subscribe pendingLogs. If an agent needs 200ms confirmation signals, and most production agents on Base do, WebSocket is mandatory, not optional.

How AI agents interact with Base differently from human-driven dApps

A human using a dApp clicks “Confirm” and waits. An AI agent executes a transaction, evaluates the outcome, and immediately queues the next action — sometimes within the same block. This creates three RPC interaction patterns that don’t exist in human-driven applications:

Autonomous nonce management. When a human submits two transactions, they wait for the first to confirm before submitting the second. Agents don’t wait — they calculate nonces programmatically via eth_getTransactionCount. When multiple agent instances share a wallet, nonce collisions cause silent transaction drops that don’t surface as errors — one transaction simply never lands. The fix is nonce serialization at the agent layer, not at the RPC layer, but it requires the endpoint to return fresh nonce values without caching lag.

LLM-controlled retry loops. Standard exponential backoff was designed for deterministic software with a fixed retry budget. When an LLM controls the retry decision — reasoning about whether to retry, wait, or escalate — the backoff curve behaves non-deterministically. An agent may retry aggressively before recognizing the error is a rate limit, not a transient failure. A private endpoint with a known RPS ceiling lets you instrument the retry boundary in code; a public endpoint makes that boundary invisible until the agent hits it.

Agentic transaction signing patterns. Agents using Coinbase AgentKit or ERC-4337 smart accounts submit transactions through signing abstractions that may issue multiple RPC calls per “single” agent action — one to simulate, one to estimate gas, one to submit, one to confirm. A task that looks like one transaction can generate 6–10 RPC calls. At 25 RPS on the free tier, a single active agent can saturate a shared endpoint during a complex multi-step task.

Chainstack’s RPC nodes for AI agents provides spec-compliant endpoints with the RPS headroom and billing predictability that autonomous agent loops require.

Rate limits and retries in agentic loops

The exponential backoff pattern that works well in deterministic code breaks down when an LLM drives the retry cycle. A standard HTTP client backs off on 429 and retries after a fixed interval. An LLM agent interprets a 429 as evidence that a task failed — and may reason that retrying faster, switching endpoints, or parallelizing requests is the correct response. The result is an agent that hammers a rate-limited endpoint harder than a non-agentic client would.

The practical implications for Base RPC infrastructure:

Rate limit visibility matters. A 429 response from a managed provider includes Retry-After headers that give the agent a concrete signal to reason about. A 429 from Base’s public endpoint does not consistently include them, which removes the signal that would allow a well-designed agent to self-throttle.

Burst headroom absorbs agentic spikes. Agent request patterns are inherently spiky — an agent may be idle for minutes then issue 50 calls in 3 seconds to evaluate a complex DeFi position or respond to a market event. A managed endpoint with 250 RPS (Growth plan) gives that burst room to resolve without triggering throttling.

Billing predictability enables agentic cost accounting. Credit-weighted pricing models charge variable amounts per RPC method — an agent that mixes eth_call, eth_getLogs, and debug_traceTransaction in a single task loop generates unpredictable credit consumption. Chainstack’s 1 RU per request model makes per-task cost calculable before deployment, which matters when you’re running agents at scale.

Recommended retry pattern for Base agent loops:

1. Catch 429s explicitly — do not treat them identically to 5xx errors
2. Extract Retry-After header if present; use it as the minimum backoff floor
3. Apply exponential backoff: 2x multiplier per retry, capped at 30 seconds
4. Log the rate limit event to your observability stack — not to the LLM’s context window, where it may influence the agent’s next reasoning step

MCP integration for direct blockchain access from AI toolchains

The traditional way to give an AI agent blockchain access requires building a custom tool layer: wrapper functions around ethers.js or web3.py, error handling, method routing, and documentation that the LLM must reason about correctly. The Model Context Protocol (MCP) eliminates this layer by exposing Chainstack’s Base RPC infrastructure directly as a tool that coding assistants and agent frameworks can call natively.

With Chainstack MCP configured, Claude, Cursor, Windsurf, or any MCP-compatible agent framework can:

• Deploy a Base node directly from a chat interface or agent script
• Query live Base state — block height, account balances, contract calls — without writing RPC wrapper code
• Access Chainstack documentation search for troubleshooting during agent development
• Manage node lifecycle programmatically from within the agent loop

The MCP endpoint at mcp.chainstack.com requires no local installation. To connect, add Chainstack MCP to your agent framework’s MCP config:

{
  "mcpServers": {
    "chainstack": {
      "type": "http",
      "url": "https://mcp.chainstack.com",
      "headers": {
        "Authorization": "Bearer YOUR_CHAINSTACK_API_KEY"
      }
    }
  }
}

Agents then authenticate with a Chainstack API key and access all supported chains including Base Mainnet and Sepolia Testnet through a single remote endpoint. For teams building AI agent pipelines where the agent itself needs to manage its own infrastructure, MCP turns node provisioning from a DevOps task into an agent capability.

How to get a private Base RPC endpoint with Chainstack

Chainstack’s Base infrastructure supports both standard and Flashblocks-enabled endpoints, archive nodes, and Dedicated Nodes — all accessible from the same console:

1. Log in to the Chainstack console (or create an account)
2. Create a new project
3. Select Base as your blockchain protocol
4. Choose network: Base Mainnet or Base Sepolia
5. Deploy the node
6. Open Access/Credentials and copy your HTTPS and WebSocket endpoints
7. Run a quick connectivity check before wiring it into production agent code

The ethers.js connection below matches the Chainstack tooling docs style — use getTransactionCount with the "pending" tag as the first health check before any agent task loop begins:

const { ethers } = require("ethers");

// Network ID 8453 for Base Mainnet; 84532 for Base Sepolia
const provider = new ethers.providers.JsonRpcProvider(
  "YOUR_CHAINSTACK_ENDPOINT",
  8453
);

// Agents: always fetch fresh nonce with "pending" before signing a transaction
provider.getTransactionCount("AGENT_WALLET_ADDRESS", "pending").then(console.log);

📖 For the full integration guide, see the Chainstack Base tooling documentation.

You can also access Chainstack Base RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

Using Chainlist

Base is on Chainlist (Chain ID 8453) and can be added to wallets like MetaMask with one click. Chainlist is a convenient shortcut for wallet configuration, but it surfaces public RPC endpoints only — not managed infrastructure. Any endpoint added via Chainlist should be replaced with a private managed endpoint before you wire it into an agent’s production environment.

Chainstack pricing for Base RPC

Chainstack uses a request-unit model where one RPC call costs one RU regardless of method complexity — which makes it straightforward to calculate what a Base AI agent deployment will actually cost before you commit to a plan. See the full Chainstack pricing page for current plan details and overage rates.

Plan	Cost	Requests/Month	RPS	Overage (per 1M extra)
Developer	$0	3M	25	$20/1M RU
Growth	$49	20M	250	$15/1M RU
Pro	$199	80M	400	$12.5/1M RU
Business	$499	200M	600	$10/1M RU
Enterprise	$990+	400M+	Unlimited	$5/1M RU

Advanced options:

• Archive Node add-on: archive calls cost 2 RU per request
• Unlimited Node add-on: unlimited requests for a fixed monthly fee
• Dedicated Nodes: from $0.50/hour (+ storage costs)

How to estimate monthly cost

1. Profile your agent: how many RPC calls does a single agent task generate end-to-end?
2. Estimate daily task volume: tasks per day x calls per task = daily RU budget
3. Calculate monthly baseline: daily RU x 30
4. Add WebSocket event volume: each active eth_subscribe session generates continuous events — estimate inbound event count separately from outbound request count
5. Budget for Base agent burst: x402 transaction volume on Base spikes hard during market events and agent coordination windows — buffer at least 2–3x your calculated baseline before choosing a plan, and set a quota alert at 80% to catch surprises before they interrupt running agents

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set (recommended: 10 seconds for Base)
• Retry logic with exponential backoff implemented — with explicit 429 handling separate from other error types
• Credentials stored in environment variables or secret manager (never hardcoded in agent code)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation (not just single failures)
• Nonce serialization implemented if multiple agent instances share a wallet — concurrent nonce reads without serialization cause silent transaction drops
• WebSocket reconnect logic in place with missed-event backfill for Flashblocks subscriptions
• L1 finality lag accounted for in any agent task that requires full Ethereum finality (~15 minutes) vs. Base sequencer confirmation (~2 seconds)

Troubleshooting common Base RPC issues

Issue	Likely Cause	How to Fix
429 Too Many Requests during agent task	Public endpoint rate limit hit by autonomous retry loop	Move to a managed endpoint with a known RPS ceiling; instrument explicit 429 handling in agent retry logic
WebSocket disconnects during agent run	Shared endpoint drops idle or long-lived connections	Use managed endpoint with stable WebSocket; implement reconnect handler with missed-event backfill
Nonce collision / transaction silently dropped	Multiple agent instances reading stale nonce concurrently	Serialize nonce management at the agent layer; always fetch nonce via eth_getTransactionCount(address, "pending") immediately before signing
Flashblocks subscription returns no events	Endpoint not Flashblocks-aware	Use the Flashblocks-enabled endpoint — mainnet-preconf.base.org for public, or the Flashblocks-specific URL in Chainstack credentials
Agent action confirmed on Base but state appears stale	Querying full node for data beyond its state history window	Switch to archive node for historical state queries; confirm block range is within the provider’s supported history
High per-task billing on credit-weighted provider	Complex agent tasks mix light and heavy RPC methods	Switch to flat-rate or RU-based pricing; map each method in the agent’s task loop to its credit weight before deployment
L2 transaction confirmed but cross-chain action fails	Confusing sequencer confirmation with full L1 finality	Wait for Ethereum L1 finality (~15 minutes) for any agent action requiring cross-chain settlement guarantees

Conclusion

The failure mode that breaks Base AI agents in production isn’t a network outage — it’s a 429 error that arrives mid-task, triggers an autonomous retry cascade, and leaves the agent in an inconsistent state it cannot diagnose. The agent doesn’t know the endpoint is rate-limited; it knows the transaction failed and retries harder. On Base’s public endpoint — no published rate threshold, no Retry-After header — that loop exhausts the quota in seconds and silently fails the task.

The infrastructure pattern that works: a private Base RPC endpoint with at least 250 RPS, a stable WebSocket connection for Flashblocks subscriptions, explicit 429 handling in the agent’s retry logic, and nonce serialization if multiple agent instances share a wallet. Archive access is non-negotiable for agents that need to reconstruct past state or audit their own transaction history — it’s the difference between “we think the agent succeeded” and “we can prove every step it took.”

FAQ

What makes Base the dominant chain for AI agents in 2026?

Three properties align with agent economics: transaction fees of ~$0.001 make high-frequency on-chain actions viable at scale, the x402 protocol enables machine-to-machine payments natively without smart contract intermediaries (165M+ transactions processed as of early 2026), and Flashblocks’ 200ms preconfirmations give agents rapid confirmation signals without waiting a full 2-second block. The combination of Coinbase’s AgentKit SDK and Base’s fee structure created the density of agent activity that other chains haven’t matched — roughly 70,000 active agents transacting daily at peak.

Can I use the public Base RPC endpoint for my agent?

For local testing with one agent instance making occasional calls, yes. For any production deployment where an agent runs autonomously, no. The public endpoint at https://mainnet.base.org is rate-limited with no published threshold, has no WebSocket stability guarantees, and provides no Retry-After headers to guide retry logic. An autonomous agent hitting an unknown rate limit mid-task has no graceful recovery path — the task fails silently. Move to a managed endpoint before connecting an agent to real funds or production workflows.

How do I manage nonces when multiple agent instances run in parallel?

Always fetch nonce with eth_getTransactionCount(address, "pending") immediately before signing each transaction — not once at agent startup or at fixed intervals. For multiple concurrent instances sharing a wallet, implement a nonce coordinator: a lightweight service or Redis-based lock that serializes nonce assignment across agent instances. Without serialization, two agents reading the same nonce simultaneously produce a collision that drops one transaction without raising an error.

Do I need Flashblocks support for my Base AI agent?

It depends on how your agent chains actions. If your agent submits a transaction and needs to know the outcome before deciding the next step, standard 2-second block confirmation adds latency that compounds across multi-step tasks — a 5-step chain adds 10 seconds of wait time. Flashblocks reduces effective confirmation to ~200–500ms, which meaningfully improves throughput for agents with sequential dependencies. For agents doing simple read queries or fire-and-forget transactions, standard endpoints are sufficient.

How does Base’s L2 finality affect agent transaction confirmation?

Base provides two confirmation levels: sequencer confirmation (~2 seconds, immediately reflected in Base state) and Ethereum L1 finality (~15 minutes, after the transaction batch is posted to Ethereum). For most agent tasks — DeFi interactions, token transfers, contract calls within Base — sequencer confirmation is what eth_getTransactionReceipt reflects and is sufficient. For agent operations that require cross-chain settlement guarantees — bridging, compliance-sensitive actions, or any task where a downstream system checks Ethereum L1 state — wait for L1 finality explicitly.

What’s the right Chainstack plan for a production Base AI agent?

Start with the Growth plan ($49/month, 20M RU, 250 RPS). A single moderately active agent generating 10 calls per task at 500 tasks/day uses roughly 150,000 RU/month — well within the Growth tier. The 250 RPS ceiling provides burst headroom for typical agent spike patterns. Step up to Pro ($199/month, 80M RU, 400 RPS) when you’re running multiple concurrent agents or when a single agent’s task complexity and frequency pushes beyond 20M monthly requests. Factor in archive calls at 2 RU each if your agent performs historical state reconstruction.

Additional resources

• Base: Deploy an ERC-721 contract with Hardhat — practical tutorial for deploying contracts on Base via Chainstack nodes
• Flashblocks on Base: 200ms preconfirmations — how to subscribe to Flashblocks data and integrate preconfirmation signals into agent workflows
• Chainstack Base tooling documentation — SDK integration guides for ethers.js, web3.py, web3.js, and more
• Base developer documentation — official network documentation, chain parameters, Flashblocks reference, and node provider directory
• x402 Protocol documentation — Coinbase’s machine-to-machine payment protocol for AI agents on Base
• More Base tutorials and articles on the Chainstack Blog