The Declared State: Sealevel Parallelism and the AI Agent Execution Contract on Solana

An AI agent managing a DeFi position on Ethereum has 12 seconds to observe state, run inference, and submit a transaction before the next slot. The same agent on Solana has 400 milliseconds. That 30× compression changes latency requirements, but it changes something more fundamental too: Solana requires every account the agent will touch to be declared before execution begins.

This isn’t a quirk — it’s the architectural mechanism that enables Solana’s parallel execution engine. And it rewrites how AI agents must be designed.

Two execution models

The EVM executes transactions serially. One transaction at a time, state transitions accumulate. A contract can call any other contract, read any storage slot discovered dynamically mid-execution, and produce state changes that later transactions in the same block depend on. The execution order is deterministic, but which state gets read is not knowable until the code runs.

Solana’s execution engine, Sealevel, starts from the opposite assumption. Every Solana transaction ships with an explicit account list — a complete declaration of every account it will read from or write to. The runtime reads this list before any computation begins, builds a dependency graph across the entire pending transaction pool, and routes non-conflicting transactions onto parallel worker threads.

The contract is binding: any account access that wasn’t declared upfront fails the transaction. Solana’s virtual machine never lets code discover state on the fly — it can only operate on state that was committed in the account list at submission time.

The payoff is real parallelism at the execution layer, not just pipelining. On a validator node with 16 cores, Sealevel can execute up to 16 independent transaction threads simultaneously — meaning 16 groups of non-overlapping transactions settle in the time a single EVM transaction takes.

Account locks: read vs. write

Account access has two modes, and the distinction matters for agents:

Read-only accounts get a shared lock. Any number of concurrent transactions can read from the same account simultaneously. A transaction that declares an account as readonly can run in parallel with any other transaction that also reads it.

Writable accounts get an exclusive lock. Only one transaction at a time can hold a write lock on an account. Every other transaction that needs to write to that same account queues behind it.

The implications for AI agents are concrete. An agent that only reads oracle prices, pool balances, and market state can run massively in parallel with other agents doing the same thing — all those transactions fit in separate lanes. An agent that writes to a liquidity pool, adjusts a position, or settles a swap needs an exclusive write lock on the pool’s state accounts, and serializes with every other agent touching the same pool.

⬢ loading artifact…

The hot account problem

Popular Solana DeFi programs have single accounts that become serialization chokepoints.

Jupiter Aggregator, which routes through dozens of liquidity sources, maintains program-owned accounts for its routing state. Raydium’s CLMM pools keep writable tick arrays. Orca’s whirlpools track global liquidity in writable accounts. During peak trading activity, hundreds of AI agents try to write to these same accounts per second.

The result is a serialization queue. Each write lock grants access to one transaction, then releases. Transactions waiting on the same hot account don’t execute in parallel — they line up. The effective throughput for any agent competing for a hot writable account is bounded not by Sealevel’s thread count but by how fast that single account can cycle through write operations.

This creates a structural asymmetry: agents that design around hot accounts — reading prices from read-only oracle accounts, deferring writes to less-contested pools, or batching multiple operations into a single atomic transaction — extract much more of Sealevel’s theoretical parallelism than agents that blindly write to the most liquid venues.

For AI agents running yield optimization or arbitrage across Solana DeFi, the architecture decision of which accounts to touch is not just a latency choice — it directly determines whether you run in 10 concurrent threads or 1 sequential queue.

The 400ms constraint and what fits inside it

A Solana slot targets 400 milliseconds. Within that window, an AI agent must complete the full observe → decide → submit loop to have any chance of inclusion.

In practice, validators see transactions and start building blocks roughly 150ms into the slot. Network round-trip to a well-connected validator (using QUIC, Solana’s custom transport layer) adds 50–100ms. That leaves roughly 200–250ms for the inference step — the actual decision-making.

For an agent calling an external LLM API, this is tight. A sub-100ms inference path — local quantized model, cached context, fast tool calls — is achievable. An agent that reaches out to a frontier model API or runs a multi-step reasoning chain at mid-slot is not competitive. It will submit to the next slot at best, and to a slot further out if it hits retries.

The 400ms constraint doesn’t eliminate LLM agents from Solana; it forces them to separate fast-path from slow-path decisions. Slow-path reasoning (what position should I hold over the next hour?) runs off the critical path. Fast-path execution (is this arbitrage opportunity still live at this exact slot?) must be a lightweight local computation: a lookup, a formula, a cached policy.

This is a different operating posture than EVM agents. On Ethereum, a 2-second inference step is comfortable within a 12-second slot. On Solana it misses the competitive window entirely. The twelve-second floor described how Ethereum’s slot clock shapes state freshness; Solana’s floor is 30× tighter and compounds the account-declaration requirement.

Jito: tip markets instead of gas auctions

Ethereum’s inclusion mechanism is a gas price auction. Higher gas bids get priority, and MEV searchers express value through gas. Solana uses a different mechanism.

Approximately 88% of Solana stake weight now routes through the Jito block engine, a MEV-aware block producer maintained by Jito Labs. To get priority inclusion through Jito, transactions include a tip instruction transferring lamports to a Jito-controlled account. The Jito block engine orders tip-bearing bundles and includes the most profitable combination.

For AI agents, this changes the MEV math significantly:

• There is no gas price. Transaction costs are a fixed base fee of 5,000 lamports (~$0.0009) per signature, regardless of computation.
• Jito tips are additive. An agent competing for a profitable opportunity expresses its bid as a tip, not a gas multiplier.
• Bundles are atomic. A Jito bundle is a group of up to 5 transactions that execute together or not at all, with the same atomicity guarantee as a flash loan on Ethereum. AI agents can use bundles to execute multi-step DeFi strategies — read state, compute, write — without risk of being interleaved with other transactions.

The competitive equilibrium for Jito tips is tip ≈ expected_profit × competition_factor. Agents that have better alpha (more precise profit estimates) tip less for the same outcome. Agents that over-estimate profit or miscalibrate competition over-bid and erode margins.

Because tips go to validators (not to the agent’s counterparty), there is no equivalent to Ethereum’s sandwich attack — the attacker can’t insert themselves before and after a victim’s transaction in the same bundle. But front-running remains possible through competing bundles, and the sandwich tax analogue on Solana is a tip war between competing agents arriving before the next slot close.

What agents can’t do on Solana

The account-declaration requirement closes off a class of dynamic execution that EVM agents take for granted.

On Ethereum, a smart contract can call token.balanceOf(address) where address was just returned by another call in the same transaction. The storage slot at address doesn’t need to be declared anywhere — the EVM discovers and reads it on the fly.

On Solana, this pattern is impossible. If an agent’s program needs to read account X, account X must appear in the transaction’s account list. If account X’s address is only knowable at runtime (returned by some compute step), it cannot be included in the account list that was submitted before computation began. The transaction fails.

This means AI agents on Solana must resolve all account addresses before transaction submission. A strategy that involves: (1) ask Jupiter for the best route, (2) route through whatever pools it returns, (3) settle — cannot be a single Solana transaction unless the agent pre-fetches the route off-chain, resolves all pool account addresses, and constructs the full account list before submission. The agent’s decision-making about which path to take happens entirely off-chain; only the execution is on-chain.

In practice this means agents run a planning phase off-chain — fetching state, resolving routes, simulating outcomes — and then submit a fully-specified transaction. The on-chain program just executes the declared plan. The agent’s intelligence lives entirely in the pre-declaration phase.

Engineering the Solana agent architecture

Translating these constraints into a working AI agent:

Static account analysis: At agent startup (not at transaction time), build a registry of every account your agent might ever touch. Pre-fetch and cache their public keys. For vault positions, pool addresses, oracle feeds — compile this into a lookup table the agent queries locally in microseconds.

Declare read-only aggressively: Anything the agent reads but does not write should be in the readonly account list. Jupiter route accounts for price discovery, Chainlink-style oracle accounts, pool tick arrays the agent only reads — all readonly. This maximizes Sealevel’s parallelism and avoids unnecessary write-lock contention.

Avoid hot accounts when possible: Profile which accounts have the highest write-lock contention. Instruments with lower activity often have lower tip requirements and shorter serialization queues. A 0.5% worse rate on a less-contested pool may net more actual profit than fighting for the best rate through a bottlenecked account.

Jito tip modeling: Build a tip estimator that tracks recent landed tip levels for the target account’s slot competition. Under-tipping wastes opportunity; over-tipping erodes alpha. A rolling exponential average of recent winning tips is a reasonable starting point.

Inference on the critical path: The agent’s inference step must complete within the critical window — roughly 200ms. Fine-tune a local policy model for the most time-sensitive decisions; use an external frontier model for slow-path strategic reasoning that runs on a separate, non-time-critical thread.

The operating layer work documented how LLM agents on Base maintained 99.9% settlement reliability through careful system design rather than model quality. The same principle applies on Solana — but the timing requirements are stricter and the account model adds a planning constraint that has no EVM equivalent.

The parallel architecture dividend

The account-declaration cost comes with a genuine upside. An AI agent running 100 independent arbitrage checks per slot — each touching different pool accounts — can submit all 100 simultaneously. If none share a writable account, Sealevel executes all 100 in parallel in the same slot. A single EVM block physically cannot process 100 independent agent transactions with equal priority.

This is the Solana tradeoff in full: pay the planning cost upfront (declare all accounts, resolve all addresses before submission), and the execution layer becomes a genuinely parallel compute environment. Agents that restructure their work to exploit this — fan-out reads, independent position checks, parallel market scans — extract throughput that is structurally unavailable on EVM chains.

The constraint and the dividend are the same mechanism. Sealevel can parallelize because the account list tells it exactly which transactions conflict. An agent that treats the account declaration as an overhead to minimize is an agent leaving most of Solana’s execution capacity on the floor.

Takeaways

• Solana’s Sealevel runtime executes non-overlapping transactions in parallel threads. Non-overlapping is defined by the transaction’s declared account list.
• Every transaction must declare all accounts it will access before execution begins. There are no dynamic state discoveries mid-transaction.
• Writable accounts serialize; read-only accounts parallelize. Agents that write to popular venues queue behind everyone else touching those same accounts.
• The 400ms slot target leaves 200–250ms for agent inference. Fast-path decisions must use local, low-latency models; slow-path reasoning runs off the critical path.
• Jito’s tip market replaces gas auctions. Tips are per-bundle, atomic, and priced at expected profit minus competition.
• Agents that pre-resolve all account addresses, declare read-only aggressively, and fan out across non-competing venues extract the full parallelism Sealevel offers.