Base Won the AI Agent Race—But We're Building on Shaky Infrastructure

General
1

Base has become the de facto home for onchain AI agents in 2026. Everywhere you look—Coinbase’s AgentKit bots, autonomous DeFi strategies, LLM-orchestrated keeper systems—they’re running on Base. With 250,000+ daily active agents and 48% of all L2 TVL, Base won the agent infrastructure race.

But here’s the problem: we just got hit with an $8,200 RPC bill for three weeks of agent testing.

I’m not complaining about the cost itself—infrastructure has value. What bothers me is that we had no way to predict it. Our test agent was designed to monitor liquidation opportunities and execute when conditions were right. During normal market conditions, it hummed along at ~500 requests per hour. Then volatility hit, and it spiked to 50,000 requests per hour for six hours straight. Our bill exploded.

Problem #1: Billing Models Designed for Humans, Not Agents

Traditional RPC pricing is built around human usage patterns: developers testing smart contracts, users checking wallet balances, dApps serving consistent traffic. Agents are fundamentally different—they make autonomous decisions that can cause 100x request spikes based on market conditions you can’t predict.

Credit-weighted pricing makes this worse. Some providers charge different rates for different RPC methods (eth_call vs eth_getLogs vs eth_subscribe). An agent that suddenly needs to scan historical events during a market event can rack up thousands of dollars in minutes. You can’t forecast agent infrastructure costs the way you budget human API usage.

Problem #2: WebSocket Reliability (Or Lack Thereof)

Agents need persistent connections for real-time data—price feeds, mempool monitoring, liquidation events. A dropped WebSocket isn’t just an annoyance; it’s a business failure. Last week, our connection to a major RPC provider dropped six times. Each drop lasted 15-90 seconds. During one of those drops, we missed a $12,000 liquidation opportunity.

Here’s the kicker: the provider’s status page showed 99.9% uptime. They were technically “up”—their HTTP endpoints worked fine. But our WebSocket event stream kept dying. When you reconnect, you have to implement recovery logic: Did we miss events during the 60-second gap? Do we query the last 50 blocks? What if the provider’s historical data lags their realtime stream?

The Paradox: We Optimized for TPS, Not Operations

Base crushes throughput. Flashblocks give us 200ms preconfirmations. We can process thousands of transactions per second. But we can’t reliably stream events to agents or predict our infrastructure costs.

It’s like building a Formula 1 race car with bicycle brakes and no fuel gauge. We focused on the sexy performance metrics (TPS! Low latency! Preconfirmations!) and ignored operational basics (stable connections, predictable billing, agent-friendly infrastructure).

What We’re Doing About It

We’re switching to flat-rate pricing—Chainstack and BlockEden both offer per-request models without method weighting. It won’t be cheaper, but at least we can forecast it. We’re also implementing dual providers with automatic failover, adding 40% more code complexity but hopefully preventing WebSocket drops from costing us liquidations.

We’re building internal monitoring—RPS percentiles, cost-per-agent tracking, WebSocket uptime metrics. Stuff that should have been built into provider dashboards but isn’t.

The Question

Did we scale transaction throughput without solving infrastructure fundamentals?

Solana’s AI Agent Hackathon in February (21,000 agents, 38 million transactions in 10 days) showed that agents can work at massive scale. But they also had sub-second finality and sub-cent fees, which simplifies agent economics significantly.

Base has the advantage of the EVM ecosystem and established DeFi protocols. But if we want agents to be production-ready—not just hackathon demos—we need infrastructure that’s built for autonomous, bursty, unpredictable workloads.

Should protocols prioritize agent-specific infrastructure (dedicated WebSocket pools, flat billing models, agent-optimized rate limits) before pushing mass adoption? Or is this just growing pains that’ll get solved as the market matures?

How are other builders handling this? What’s your agent’s request-to-revenue ratio? Are your WebSocket connections stable? What percentage of agent revenue goes to RPC costs?

I want to believe Base is the right foundation for onchain agents. But right now, it feels like we’re building skyscrapers on sand.

2

I’ve been dealing with exactly these issues while building analytics pipelines for agent activity tracking. Your $8,200 surprise bill resonates—we had a similar wake-up call last month when our monitoring agents spiked to 200K requests during a liquidation cascade.

Agent Request Patterns Follow Power Law Distributions

After tracking agent behavior across 50+ deployments, I found that request patterns follow a power law distribution: 90% of the time agents run at baseline (~500-2K RPS), but 10% of the time they spike to 20-100x that rate. Traditional rate limiting doesn’t work because agents need burst capacity during market events—that’s literally when they’re most valuable.

The problem: most RPC billing models are designed for Gaussian distributions (predict the average, charge for outliers). Agents break that model.

Cost Forecasting: Budget for p95, Not p50

Here’s what worked for us:

Sliding window analysis: Track 7-day and 30-day moving averages with spike detection. Our internal dashboard shows RPS at p50, p95, and p99 percentiles—not just averages. Budget for p95, not p50. If your agent averages 1K RPS but hits 50K RPS during volatility, you need to reserve capacity for 50K.

Provider-specific monitoring: We track 3 major RPC providers simultaneously. Discovered that:

  • Chainstack: Most stable WebSocket uptime (99.4% connection time over 30 days)
  • Alchemy: Best HTTP latency but WebSocket drops more frequently (97.8% connection time)
  • QuickNode: Balanced, but credit-weighted pricing caused billing surprises

WebSocket Reliability Data

Tracked 30 days of WebSocket connection stability:

  • Chainstack: 4 disconnects, avg reconnect time 8 seconds
  • Alchemy: 12 disconnects, avg reconnect time 15 seconds
  • QuickNode: 8 disconnects, avg reconnect time 12 seconds

Every disconnect requires recovery logic: We implemented exponential backoff + event gap detection—query last 100 blocks on reconnect to catch missed events. Added 200 lines of code and 15% latency overhead, but worth it.

The Cost Firewall

Built an internal “cost firewall”—kill switch that throttles agents if RPC costs exceed threshold. Saved us twice when test agents went rogue:

  • Agent 1: Infinite loop polling eth_getLogs, would’ve cost $40K/day
  • Agent 2: Market manipulation detector scanning every transaction, hit $15K before we caught it

Now every agent has a daily RPC budget. If it hits 80% of budget, alerts fire. At 100%, agent shuts down gracefully.

Request-to-Revenue Ratio

This is the key metric: What’s your agent’s request-to-revenue ratio?

Our benchmarks (30-day averages):

  • Liquidation bots: 2K requests per $1 revenue (infrastructure-heavy, thin margins)
  • Arbitrage bots: 500 requests per $1 revenue (better economics)
  • Yield optimizers: 8K requests per $1 revenue (monitoring-heavy, periodic execution)

If your ratio is worse than 10K requests per $1 revenue, you’re probably burning money on RPC costs. Either optimize request patterns or switch use cases.

Base vs Solana Infrastructure Comparison

You mentioned Solana’s hackathon (21K agents, 38M transactions). The economics are fundamentally different:

Solana: Sub-second finality + sub-cent fees = agent can poll aggressively without cost concerns
Base: 2-second blocks + variable gas = agents must optimize request patterns or pay premium for WebSocket subscriptions

But Base has DeFi liquidity that Solana lacks. Our arbitrage agents need access to Uniswap, Aave, Compound—that’s all on EVM. We can’t migrate to Solana even if infrastructure costs are lower.

Practical Recommendations

  1. Switch to flat-rate or request-unit pricing (you’re already doing this—smart move)
  2. Implement RPS monitoring at p95/p99, not just averages
  3. Build cost firewall before agent goes live (learned this the hard way)
  4. Track request-to-revenue ratio weekly—if it’s deteriorating, debug immediately
  5. Use dual providers with failover (40% code complexity is worth it for production agents)

The infrastructure will mature, but right now we’re in the “roll your own monitoring” phase. Providers are optimizing for dApp use cases (consistent traffic, predictable patterns), not agent use cases (bursty, autonomous, unpredictable).

You’re not building on sand—but you’re definitely building on gravel. Foundation exists, just need better tooling.

What’s your agent’s use case? Can help benchmark if your request patterns are reasonable or if there’s optimization opportunity.

3

This thread hits on something critical that doesn’t get enough attention: Base (OP Stack) has unique failure modes that people often misread as “RPC provider is down.”

Two Distinct Failure Classes on Base

1. Sequencer downtime: Block height freezes, no new transactions accepted
2. Transaction submission outages: Sequencer runs but can’t publish to L1, affects safe/finalized status

Your WebSocket drops might not be provider issues—they could be OP Stack sequencer hiccups that providers can’t control. When Base’s sequencer has submission lag (happened 3 times in February during high congestion), providers’ WebSocket streams can appear “broken” even though the provider infrastructure is fine.

Flashblocks Adds Complexity

Base’s 200ms preconfirmation layer (Flashblocks) changed the confirmation semantics. Now you have:

  • Preconfirmed (200ms, sequencer intent)
  • Unsafe (included in sequencer block)
  • Safe (submitted to L1, economically final)
  • Finalized (L1 confirmed, irreversible)

Agents optimized for speed might rely on Flashblocks preconfirmations, but you’re exposed to reorg risk. We saw this in January: Base had a 6-block reorg that affected preconfirmed transactions. If your agent executed a liquidation based on preconfirmed state that got reorged, you just lost money.

Are your agents handling OP Stack finality correctly? Most liquidation bots I’ve seen wait for “safe” status (L1 submission), not just sequencer preconfirmation.

WebSocket Infrastructure Matters

Not all RPC providers implement WebSocket the same way:

Proxy-based: Provider runs load balancer in front of Base nodes, WebSocket connection goes through proxy. Higher latency, more failure points, but scales better.

Direct connection: WebSocket connects directly to Base node. Lower latency, fewer failure points, but limited by node capacity.

When evaluating providers for agent workloads, ask:

  1. WebSocket architecture: Proxy or direct?
  2. Reconnect policy: Automatic with backoff, or manual?
  3. Load balancing: If one node dies, do you auto-failover?
  4. Historical event access: Can you query missed events on reconnect?

Most providers won’t publish these details publicly—you have to ask their enterprise sales teams.

Base vs Solana: Different Economics, Different Tradeoffs

You mentioned Solana’s AI Agent Hackathon (21K agents, 38M transactions February 2026). The infrastructure economics are fundamentally different:

Solana:

  • Sub-second finality (400ms) = one confirmation model, no “safe vs finalized” complexity
  • Sub-cent fees ($0.00001 per transaction) = agents can poll aggressively
  • RPC nodes handle 50K TPS = built for high-throughput workloads

Base:

  • Multi-stage finality (preconfirmed → unsafe → safe → finalized) = agents must choose tradeoff
  • Variable gas fees ($0.01-$1+ per transaction) = agents must optimize execution
  • RPC infrastructure handling 2-second blocks with L1 data availability bottlenecks

Base’s advantage: EVM ecosystem and DeFi liquidity. Uniswap V3, Aave, Compound, Morpho—all on Base. Solana has liquidity, but it’s fragmented and protocols aren’t as mature.

Your agent needs access to established DeFi primitives, so Base makes sense despite infrastructure challenges.

Multi-Provider Setup (Yes, It’s Worth the Complexity)

You mentioned implementing dual providers with 40% more code complexity. This is necessary for production agents—not optional.

Our setup:

  • Primary: Chainstack (stable WebSocket, flat pricing)
  • Backup: Alchemy (fallback if Chainstack drops)
  • Canary: QuickNode (test requests to monitor health)

Failover logic:

  1. Primary WebSocket disconnect → immediate switch to backup
  2. Backup serves traffic while primary reconnects
  3. On reconnect, query last 100 blocks from primary to detect missed events
  4. Compare backup vs primary event streams—if mismatch, alert (potential provider inconsistency)

Added 300 lines of code, 15% latency overhead, but zero missed liquidations in 60 days since implementing.

The Real Question: L2 Infrastructure Maturity

Your “building skyscrapers on sand” metaphor resonates, but I’d frame it differently: We’re building skyscrapers on a foundation that’s still settling.

L2s prioritized transaction throughput (TPS, gas costs, preconfirmations) because that’s what users complained about. Now that agents are the primary use case (NEAR co-founder prediction: AI agents will be primary blockchain users), we’re discovering the operational gaps.

What needs to happen:

  1. Agent-specific RPC endpoints: Dedicated infrastructure with burst capacity, stable WebSocket pools, flat billing
  2. Standardized finality semantics: Clear documentation on what “confirmed” means for each L2
  3. Provider SLAs that matter: “99.9% uptime” is meaningless—agents need “99.9% WebSocket connection uptime” and “event delivery guarantees”
  4. Better monitoring tools: Providers should surface RPS percentiles, WebSocket stability, and cost projections in dashboards

Base has the DeFi ecosystem and transaction throughput. Infrastructure will catch up—but right now, agent developers are doing the heavy lifting to build operational resilience themselves.

It’s not sand, but it’s definitely gravel. The foundation exists, just needs hardening.

How are you handling Base finality in your agent logic? Waiting for “safe” status or taking preconfirmation risk?