Why Onchain AI Agents Need a Read Layer and an Execute Layer
Co-authored by KeeperHub and Blockscout
There is a design decision every team building onchain AI agents eventually has to make: do you try to build one system that reads the chain and acts on it, or do you split those responsibilities and let each component do one thing well?
The answer matters more than it looks. Read and execute are not two features of the same problem. They are two distinct disciplines with different failure modes and fundamentally different engineering requirements. Conflating them is how you end up with agents that know exactly what to do and have no reliable way to do it.
Blockscout and KeeperHub made the same architectural call from opposite ends of the stack. Blockscout built a dedicated read layer: decoded onchain data across nearly 100 EVM chains and delivered through a clean MCP tool surface. KeeperHub built a dedicated execute layer: SLA-backed transaction submission with simulation, retry, MEV protection, and a full audit trail, by design focused entirely on getting actions to land.
The read layer problem
If you have ever tried to give an AI agent live onchain context, you know what raw RPC looks like from the model's side. eth_getTransactionByHash returns hex. Decoding a token transfer means knowing the ERC-20 ABI, parsing a log topic, looking up symbol and decimals from somewhere else. Multiply that across multiple chains, and the agent spends most of its context window on data archaeology instead of reasoning.
Block explorers already solved the hard parts of this: verified contracts, decoded events, token metadata. The Blockscout MCP Server wraps all of this in a format any MCP-aware agent can call. The agent asks what tokens an address holds on a specific chain; the server returns a structured, labelled response. It asks for the current block, the decoded trace of a reverted transaction, or the verified ABI of a proxy contract; it gets clean JSON back, no hex, no chain-specific plumbing. The same tool calls work across 100 EVM chains because the server handles the indexing and the normalization.
This is what a purpose-built read layer looks like. It is fast to query, accurate at scale, and deliberately scoped for data access. Blockscout describes the MCP surface as read-mostly and recommends pairing it with a wallet-side MCP for any onchain action.
The execute layer problem
Execution reliability is a different engineering discipline entirely. The failure modes are not about data freshness or API availability. They are about what happens when a transaction sits in the mempool during a gas spike, when a node goes offline mid-submission, when an MEV bot frontruns a visible position change, when a smart contract reverts for a reason that could have been caught before the gas was burned.
Handling those failure modes requires infrastructure that was built for them from the ground up: intelligent gas estimation that adapts to network conditions rather than anchoring to a stale price, exponential backoff on failed or stuck transactions, pre-submission simulation to validate the transaction will succeed before it costs anything, private routing to protect against MEV extraction on visible amounts, and a complete audit trail logging every step from trigger through confirmation.
KeeperHub has been running this infrastructure in production for the likes of Sky Protocol (formerly MakerDAO), the issuer of USDS and DAI and the largest onchain stablecoin operation by TVL. Every execution logged: trigger, simulation result, submitted transaction, gas used, confirmed outcome, timestamp, a full audit trail logged for every single transaction.
Why specialisation is the right architecture
The instinct to combine read and execute into one system is understandable. Fewer components, simpler mental model, one team to call when something breaks. But combining them means owning both failure modes, which require fundamentally different engineering. Teams that have tried to build both in-house typically end up with a read layer that works and an execution layer held together with custom scripts that fail precisely when the stakes are highest: during liquidation cascades, gas spikes, and the moments when a failed transaction has the most downside.
Keeping the responsibilities separate means each component can be engineered to be genuinely excellent at one thing. Blockscout indexes 100 EVM chains because indexing and data access is the entire product surface. KeeperHub has a zero-downtime production record protecting $9.5B in assets because execution reliability is all it does. The integration does not ask either team to build something outside their core competency. It asks each to do what they already do, and lets the agent benefit from both.
Two servers, one agent
In practice, the architecture is simple. An agent loads both MCP servers. When it needs to know something about the chain, it calls Blockscout: read contract state, pull address balances, decode a transaction. When it needs to act, it calls KeeperHub: submit the transaction with pre-submission simulation, route it privately to avoid MEV, retry it with intelligent backoff if the first attempt does not confirm, and write the full execution record to the audit trail.
The agent orchestrates. Each server does what it was built for. Neither needs to know what the other is doing.
A vault health monitor using this stack watches a collateral ratio via Blockscout MCP, detects when it crosses a liquidation threshold, and fires a top-up transaction via KeeperHub MCP with simulation confirming it will succeed before the gas is committed. A governance executor tracks proposal state across chains via Blockscout, submits the execution transaction at the right moment with retry logic to handle network congestion, and produces a verifiable action record for DAO reporting. A treasury rebalancer reads cross-chain positions via Blockscout, routes rebalancing transactions privately to avoid MEV, and delivers consistent gas savings at scale through Smart Gas Estimation.
Getting started
Both MCP servers are available today.
The Blockscout MCP Server is live at mcp.blockscout.com and covers ~100 EVM chains. A free Pro API key gives you higher rate limits for production workloads. The full setup guide, including config snippets for Claude Desktop, Cursor, and custom agent loops, is at the Blockscout MCP Hub.
KeeperHub's MCP server connects your agent to SLA-backed onchain execution with built-in simulation, retry, private routing, and a full audit trail. Documentation and integration guides are at docs.keeperhub.com.
Load both servers. Blockscout handles the read. KeeperHub handles the execution. Two components, one job each.
KeeperHub is the execution and reliability layer for AI agents operating onchain. Blockscout is the leading open-source multichain block explorer, powering onchain data access for EVM chains.
