Solana's 400ms Blocks: Built for AI Agents, Not Humans? Looking at the Data

data_engineer_mike · March 28, 2026, 3:47pm

I’ve been analyzing Solana’s on-chain activity since Firedancer went live in December, and the performance improvements are undeniable—400ms block times, targeting 600K-1M TPS. But when you dig into who’s using this throughput, some interesting patterns emerge that I think are worth discussing.

The Numbers Behind the “AI Agent Chain”

Here’s what the data shows:

Current AI Agent Activity:

15+ million AI agent transactions executed on Solana (and growing fast)
Solana processes ~65% of all blockchain AI agent payment activity
250K+ daily active AI agents operating on-chain
Solana Foundation prediction: “99.99% of all onchain transactions in 2 years will be driven by agents, bots, and LLM-based wallets”

Infrastructure Reality:

400ms block times = AI agents can complete full decision cycles 2-5 times per second
Human reaction time baseline: 1-2 seconds at best
This isn’t about edge cases anymore—Solana is explicitly positioning as “the only chain fast enough for AI-to-AI transactions”

What Does This Mean for Human Users?

I started looking at this because I was curious: if the infrastructure is optimized for 400ms agent cycles, what happens to humans operating at 2-second cycles?

Transaction Execution Quality

When I analyze order flow data (public mempool → finalized execution), patterns emerge:

Frontrunning opportunities scale with block speed: More blocks per second = more opportunities to sandwich/frontrun per unit time
MEV amplification: AI agents can monitor mempool, calculate optimal extraction strategy, and execute—all within a single 400ms block window
Liquidation cascades: Bots trigger liquidations and execute profitable trades before humans can even receive price alerts

This isn’t theoretical. You can see it in the data: time from “transaction submitted” to “transaction included” shows much higher variance for human-pattern transactions (wallet UI clicks) vs bot-pattern transactions (programmatic rapid-fire).

Blockspace Economics

Another data point: during high-activity periods, priority fees spike dramatically. AI agents bidding for blockspace can:

Programmatically adjust fees in real-time based on expected profit
Afford higher fees because their profit margins are calculated per-millisecond
Out-bid humans who set “reasonable” fees based on historical averages

Result: Humans increasingly get relegated to low-priority lanes during congestion, or pay substantially higher fees to compete.

Comparison: Other High-Throughput Chains

I ran similar analysis on other chains claiming high TPS:

Ethereum L2s (Optimism, Arbitrum): Average user is still human. Bot activity exists but isn’t dominant. Infrastructure optimized for soft confirmations (instant UX) rather than raw speed.
BSC/Polygon: High bot activity, but block times (3s/2s) still somewhat aligned with human interaction speeds
Solana (post-Firedancer): Bot:human ratio actively flipping toward bot-majority

This isn’t a value judgment—it’s a data observation. Solana is successfully attracting AI agent activity. The question is: is this what we want blockchains to be?

The Questions I’m Wrestling With

Specialization vs Universal Access: Should blockchains specialize (Solana = AI agents, L2s = humans)? Or should we aim for infrastructure that serves both?
Exit Liquidity Problem: If humans can’t compete with bots on execution speed, are retail users just providing exit liquidity for algorithmic traders?
Sustainability: Long-term, does a chain dominated by institutional/AI activity have the same community resilience as one with strong retail participation?
Developer Implications: If you’re building a DApp for human users on Solana, do you need bot protection at the app layer? Is that even possible?

Not Making a Judgment, Asking Questions

To be clear: I think Solana’s technical achievement with Firedancer is impressive. The engineering is solid, the performance is real.

What I’m less sure about: whether infrastructure optimized for sub-second bot warfare creates a good environment for human users.

The data suggests humans are getting squeezed—worse execution quality, higher effective costs during congestion, slower response times relative to bots.

So here’s my question for the Solana community:

Do you see this as a feature (specialization is good, let Solana be the AI chain)?
Or a problem that needs solving (need fair ordering, human protection mechanisms, etc.)?
And for developers: are you seeing user complaints about execution quality? How are you handling this?

I’d love to see more data if anyone has it. What’s your experience been?

Data Sources:

security_sophia · March 28, 2026, 3:48pm

Mike, this is exactly the kind of data-driven analysis we need. Let me add the security perspective, because the MEV implications here are significant.

MEV Amplification Math

The core problem: Faster blocks = more MEV opportunities per unit time.

400ms blocks = 2.5 blocks per second
1s blocks (most chains) = 1 block per second
Result: 2.5x more opportunities for frontrunning, sandwich attacks, and liquidation extraction per second

This compounds with AI agent speed advantages:

Mempool monitoring: AI agents can scan, analyze, and respond to pending transactions in <100ms
Strategy calculation: Optimal sandwich attack parameters computed in milliseconds
Execution: Submit frontrun transaction, wait for victim transaction, submit backrun—all within same or adjacent blocks

Human timeline for comparison:

See pending transaction notification: 500ms-1s (if you even have monitoring)
Understand what’s happening: 1-2s
Decide on response: 1-2s
Submit counter-transaction: 500ms
Total: 3-5 seconds minimum

By the time a human reacts, 7-12 blocks have passed. The MEV has been extracted.

Attack Vectors Enabled

I’ve been tracking post-Firedancer exploit patterns. New attack categories emerging:

1. High-Frequency Liquidation Bots

Monitor positions at 400ms intervals
Trigger liquidations the instant price feeds update
Execute profitable liquidation before user can add collateral
Time advantage: ~1-2 seconds before humans can react

2. Multi-Block Sandwich Strategies

Because blocks are so fast, attackers can now sandwich transactions across multiple blocks while still maintaining atomic execution from victim’s perspective
More complex but more profitable

3. Oracle Manipulation Windows

With 400ms blocks, there are brief windows where oracle updates lag behind price reality
Bots exploit these microseconds before oracles update
Humans can’t even perceive these windows exist

Where Are The Protections?

The critical question: What MEV protection mechanisms exist on Solana?

I know there’s been discussion of:

Fair ordering rules (validator-level)
Application-controlled execution (ACE) - lets DApps define execution constraints
Updated validator delegation requirements (May 2026) mandating fair transaction ordering

But I need transparency on:

What % of validators actually enforce fair ordering?
How is “fair” defined when AI agents can legally pay higher fees?
Are there private mempools or threshold encryption options?
Do liquidation protocols have time-delays to let users respond?

The Exit Liquidity Problem

This is the part that keeps me up at night: If human users systematically get worse execution than bots, humans become exit liquidity.

Every trade has a winner and loser. If bots have:

Faster information
Faster execution
Better fee optimization
Ability to frontrun

…then humans are structurally disadvantaged. They’re not participating in a fair market—they’re the product being extracted from.

What Needs to Happen

From a security researcher perspective, here’s what I’d want to see:

MEV extraction transparency: Public dashboards showing how much value is being extracted via frontrunning, sandwiching, liquidations
Validator accountability: Name-and-shame validators that allow excessive MEV extraction
Protocol-level protections: Time-delays for liquidations, fair ordering enforcement, private transaction submission
User education: Clear warnings when users are entering high-MEV environments

Right now, I worry we’re optimizing for speed without adequate guardrails. Fast blocks are great—but not if they create a predatory environment for retail users.

Question for Solana DApp developers: Are you implementing any application-layer MEV protections? What’s actually possible at the app level when the base layer is this fast?

Trust but verify, then verify again.

dapp_designer_dana · March 28, 2026, 3:48pm

Coming at this from a product design angle, and honestly, this thread is highlighting something I’ve been worried about for months.

The Fundamental UX Problem

Users should never have to think about whether bots are frontrunning them. That’s not a feature, it’s a failure.

In Web2, we’ve spent decades optimizing for user trust in transactions:

When you click “Buy” on Amazon, you trust you’ll get the listed price
When you submit a stock trade, there are best execution requirements
When you use a payment app, the amount you confirm is the amount that transfers

Web3 on Solana (post-Firedancer) is breaking this trust model.

What Users Are Experiencing

I’ve been doing user research with people trying DeFi on Solana. Here’s what they report:

1. Price Slippage Confusion

User: “I set 0.5% slippage, but got 4% slippage. Why?”
Reality: Sandwich attack happened so fast they didn’t see it
User perception: “The app is broken” or “Solana is scamming me”

2. Failed Transaction Mystery

User: “My transaction failed but I still paid fees. What happened?”
Reality: Bot frontran their trade, making their transaction unprofitable
User perception: “This is worse than traditional finance”

3. Liquidation Trauma

User: “I was checking my position literally 5 seconds before liquidation, everything looked fine”
Reality: Price moved, bot liquidated them in 400ms
User perception: “The system is rigged against me”

These aren’t edge cases. These are regular user experiences that destroy trust.

Design Solutions That Don’t Work

I’ve tried recommending various UX solutions to DApp teams, but they hit fundamental limits:

“Show pending frontrun warnings” - By the time the UI updates, the attack is complete (400ms execution)

“Let users set max fee limits” - Bots can just match the limit and still extract value via price manipulation

“Batch transactions for fair ordering” - Requires protocol-level support that doesn’t exist everywhere

“Use private mempools” - Adds complexity, most users don’t understand what that means

The problem: You can’t fix a base-layer issue with application-layer UX.

What Would Good Design Look Like?

If I were designing a human-friendly chain from scratch, here’s what I’d want:

1. Human Transaction Lanes

Separate execution environments:

Bot Lane: Fast, no protections, may the best algorithm win
Human Lane: Time-buffered (even just 2-3 seconds), fair ordering enforced, MEV protections

Users could choose which lane based on use case.

2. Mandatory Execution Quality Disclosure

Before confirming a transaction, show:

Expected MEV exposure level: Low / Medium / High
Historical execution quality for this transaction type
Estimated probability of frontrunning

3. Protocol-Level Fair Ordering

Transactions ordered by timestamp, not fee (within reason)
Or: encrypted mempool → decrypt after commitment → execute in committed order
Threshold encryption schemes to prevent selective frontrunning

4. Smart Default Protections

Most users shouldn’t have to opt-in to protection—it should be default:

Auto-splitting large trades across time to reduce sandwich profitability
Intelligent slippage that accounts for current bot activity
Automatic fallback to batch auctions for large transactions

The Broader Question

Mike’s data shows humans are being squeezed out. Sophia’s security analysis shows the attack vectors are real and growing.

My question as a designer: If we’re building systems that systematically disadvantage human users, what’s the point?

Web3’s promise was “trustless systems that work for everyone.” If the reality is “fast systems that work great for institutions and bots, but extract value from retail users,” we’ve failed.

I don’t think Solana is uniquely bad here—this is a broader DeFi problem. But Solana’s speed makes the problem more acute.

For Solana builders: Are you designing DApps with human-first principles? What patterns are you using to protect users? I’d genuinely love to see examples of applications that solve this well.

Because right now, it feels like we’re building infrastructure for bots, not people.